Talk:Spec:Dishwasher

= Overview =

Dchassin 00:29, 13 March 2012 (UTC)
Bharat - Changed from numbers to words Bharat - Reformatted all the equations. Bharat - Added references to all the figures Bharat - Added the explanation in a separate section (modeling approach). Also, provided a reference document. Bharat - Published all the time intervals. Bharat - It was a typo. I deleted 11.1. Also, discussed all the details about the demand in "modeling approach" section Bharat - Corrected all the constraints. Bharat - Made some changes to the existing equations. Now, only one power factor is existing in the modified equations.
 * 1) The page needs an editorial review.
 * 2) Think of this page as instructing the programmer how to write the dishwasher class. I think a programmer would be unable to implement the class using what's here.  It is missing a lot of very important information still. If it helps, describe what the prototype code does.
 * 3) The states should use primarily words and not numbers so it's easier to understand state flow, e.g., instead of writing "1->2", write "OFF->CONTROL".  Those words/numbers will become the basis of the state enumeration.
 * 1) The equations need to be reformatted so they fit nicely on a printed page as well as in a normal browser layout.
 * 1) Figures are referenced without numbers.
 * 1) The queueing model needs to be explained very carefully so that programmers will know how to implement.
 * 1) Some time intervals are not described or published.  If not, why not?  Even if they are calculated internally, users may want to observe them.  Remember anything that isn't specified isn't going to be implemented.  If the interval is in the diagram, then it almost certainly should be in the table too.
 * 1) The daily_dishwasher_demand description does not help the user determine what a good value is or how to come up with one.  The default of 11.1 is not intuitive for a probability, which begs the question "what is it?".  The lack of clarity on what the property does is almost certain to lead to confusion when it is implemented and when it is validated too.
 * 1) Power factors are not between -1 and 1 because a power factor of 0 is not valid (is it leading or lagging 90&deg;?).  Please provide the correct constraints on PF so that they can be properly verifying during init.
 * 1) The properties for ZIP/PF components do not conform to the general usage in GridLAB-D.  Please use predefined structures (e.g., enduse) for input/output properties. If none exists for the purpose/need then considering specifying one that would be general for appliances.
 * 2) There are two sets of power factors: 1 set for motor/coil and 1 set for ZIP components.  This doesn't make sense to me.  Please explain why this is needed, what the relationship is, and how they are used.

Bharat - Corrected Bharat - Modified the section Bharat - Added a new section (usage of the dishwasher)for the explanation.
 * 1) Coils are by definition resistive elements.  Why are power factors even needed?
 * 1) The section on Dishwasher Timing needs a lot more detail about the solution method and which parts are implemented in which sync/commit step.
 * 1) The data connection to house is not described at all, yet that is one of the most critical parts of the model.  This needs to be completely and carefully specified so there is no ambiguity or uncertainty about how appliance output become house inputs.

Ftuffner 01:04, 13 March 2012 (UTC)
Bharat - Deleted pump(s)
 * 1) Just an overall comment, but why are pump(s) mentioned?  You attributed everything a pump would do to a motor in the description (which isn't inaccurate since any pump I've ever seen in a dishwasher is a motor).  It questions why pump(s) are explicitly called out.

Ftuffner 15:58, 11 April 2012 (UTC)

 * 1) The description seems a little too descriptive.  From a modeling perspective, do I really need to know about detergent dispensers opening?  It may be okay as is, but this strikes me as a section that could be generalized a little more.  I believe it should be a functional description of the dishwasher model, not a functional description of an actual dishwasher.

= Modeling Assumptions =

Ftuffner 01:04, 13 March 2012 (UTC)
Bharat - Corrected Bharat - Edited Bharat - Deleted the fourth bullet.
 * 1) I'm a little curious why the power factor is just assumed constant.  If you only have two basic load devices (motors and resistance heaters), can't you simply alter the ZIP fractions and let the power factor handle itself?  If you mean the underlying power factors (base ZIP model of motor and resistance heater), you can make assumptions on them and then just aggregate it up to whatever is "running" for the enduse load structure.  It looks like you are modeling it along these lines, but the assumption statement implies otherwise.
 * 1) The third bullet has some grammar/phrasing issues that need to be fixed.
 * 1) The fourth bullet is a little unclear what it means right here.  Hopefully it is clarified further in the specification.

Ftuffner 15:58, 11 April 2012 (UTC)
BHarat- Check with Frank Bharat - Edited
 * 1) I still argue the "constant power factor" statement is misleading.  You are letting individual component power factors remain constant (e.g., the motor and coil), but the overall power factor is a function of what is running.  You state this, but then basically contradict yourself at the end of the line.
 * 1) I'm a little confused how reference [2] is relevant to your dishwasher statement.  It makes it sound like [2] includes information on energy consumption for different states of dishwashers.  [2] doesn't state anything like that.  You may want to rephrase this to be more of "the approach from [2]" or similar.

= Dishwasher =

Ftuffner 01:04, 13 March 2012 (UTC)
Bharat - Edited Bharat - Corrected all the figure numbers. Bharat - Refered all the figures by numbers Bharat - In this state, dishwasher takes power only to drive control panel equpment.
 * 1) There are some general grammar/phrasing issues in this section that could use a bit of touch up.
 * 1) You have two Figure 1 figures (one is Figure 1, I suspect the other is supposed to be Figure 3).
 * 1) For figures, be aware that they don't necessarily drop the thumbnails right where you place them.  If you look at the actual web page, figures all show up as thumbnails to the right.  It is best to refer to them by number (or link them somehow).
 * 1) It might be useful to do a table of the different states and exactly what they mean, in terms of functionality and energy.  This is mainly for state 2, "Control only", since I am not sure from the description what this state really does.

Bharat - Figure 1 name changed to "Diswasher representative cycle" Bharat - Not really, we could change it. Bharat - Corrected Bharat - Replaced all the numbers with names. Bharat - Typeset all the variables inside Table 1. Bharat - Please suggest some names. Bharat - Corrected Bharat - Discussed in "modeling approach" section Bharat - Yes, it happens twice. Bharat - Yes Bharat - All the state times and base energy value are fixed. However, user can change those values.
 * 1) For Figure 1, is this an absolute progression, or just an example of how a normal cycle would go?  The diagram of Figure 2 seems to imply more flexibility, but I don't see Figure 1 labeled as just a "representative cycle" or "absolute progression".
 * 1) Would there be any merit in redoing the state machine for the "cycles" of the dishwasher, rather than the devices on?  For example, have OFF, WASH_HEAT, WASH_NOHEAT, and DRY as the states, then have the actual "devices" active done as Mealy outputs?
 * 1) Table 1 has the title from a different module (Microgrid Specifications from the looks of it) - be sure to change this.
 * 1) Table 1 would be a little easier to read if the states were referred to by name.  Consider showing the table only by state name, or augmenting the number with the name.
 * 1) Consider typesetting variables inside Table 1 so they are differentiated from the description text.  Consider using the  or formats to distinguish it.
 * 1) Could the "time_interval_x" values have better names?  From a user perspective (since they are defined as inputs below), it'd be nice if they had mappable names rather than having to consult the timing diagram each time.
 * 1) In Table 1, the first row confuses me.  If the number of accumulated loads is greater than 1 to run, how can the probability be greater than 1 to run?  Wouldn't that no longer be a proper probability then, unless it is in percent?  How can something be "over 100% able to run"?
 * 1) What constitutes a "load" for the accumulator?  You say number of loads, but is this really a "% full" or similar item?
 * 1) In Table 1, for the transition from state 2 to 5, will that really happen twice?  It seems odd that a dishwasher would progress to heated dry after a wash cycle.
 * 1) In Table 1, the converse action, state 5 to 2, happens twice as well?  Furthermore, your description says one occurs during heated dry and one after the heated dry.  State 5 is the heated dry, so how does one of these occur (if in heated dry and it transitions, it is no longer in there to do it "afterwards").
 * 1) For the statements below Table 1, I'm a little confused.  If the state times are fixed, but the user can change them, are they really fixed?  Are the user inputs ignored?  Furthermore, what determines the base energy value?  Is that fixed as well, or is it scaled by some other parameters?

Ftuffner 15:58, 11 April 2012 (UTC)
Bharat - Please suggest some names. Bharat - Values are estimated based on the energy consumption profile of the dishwasher [1] Bharat - Edited Bharat - Check with Frank Bharat - Model stops whenever total energy consumption exceeds the baseline energy and this can be any state of the dishwasher. Once model stops, it will not transit into any other states.
 * 1) The third "paragraph" (Figure 3 shows...) has some grammar issues that need to be fixed.
 * 2) I still contend the time intervals need meaningful names (or at least double-referenced) to make more sense.
 * 1) Reference [1] is woefully ambiguous.  There are many articles in the Power and Energy magazine for that issue.  I'm also not sure which one is relevant to what you are referencing here.
 * 1) Fourth "paragraph" seems to want a table reference that is missing ("Table X below" - otherwise rephrase to "In the table below" or similar)
 * 1) My comment about the state machine from earlier still holds - this model seems much better suited to an "object condition state" than an "individual device state"
 * 1) The statement after the table about how the "model stops whenever total energy consumption exceeds the baseline energy" needs some clarification.  Does this occur in any state?  If it is somehow in the wash state still and this energy is exceeded, does it just stop, or still attempt to transition into the appropriate progression of states?

= Equations =

Ftuffner 01:04, 13 March 2012 (UTC)
Bharat - Deleted [-] symbols. Bharat - Modified all the equations ($$P_{pf\_motor}$$ is no longer used) Bharat - Corrected all the equations. (Load current = load admittance = 0 for the motor only case) Bharat - Corrected Bharat - Check with Frank Bharat - No Bharat - Corrected as per your suggestion.
 * 1) What are the [-] symbols in your equations?  It looks like a typeset/render error, but I'm not sure.
 * 1) You may want to explain what $$P_{pf\_motor}$$ and the like are.  It looks like they are suppozed to be power factor, but I'm not quite sure of that.
 * 1) You indicated the motor is 100% constant power and the heating coil is 100% constant impedance.  What are the other terms (e.g., Load current and load admittance under motor) used for?
 * 1) You mention things are modeled as ZIP factions, to which the Z is impedance.  Why is everything labeled as "Load Admittance" then?
 * 1) The \mathrm usage looks a little odd - you may just want to make them variables and have a table.
 * 1) All of your equations show how to calculate the real portion of the power.  Since you are explicitly providing power factors for the devices and each of their ZIP factions, shouldn't the reactive be included somewhere?
 * 1) Your energy calculation is confusing.  At first glance, it appears (as labeled by the text) as just a power equation (as labeled by the equation).  Energy is an integral/summation over time.  You may want to make it a little clearer on the substitutions.  Furthermore, why multiply by 1000 to get power in Watts, but then divide it 1 step later for the kWh calculation?  Why not just leave it in kW?

Ftuffner 15:58, 11 April 2012 (UTC)
Bharat - Check with Frank Bharat - Power required to drive control panel equpment.
 * 1) Though not needed for your energy calculations, I still contend you need to address the reactive components somewhere in your equations.  Even if it is as simple as "GridLAB-D automatically handles the reactive component based on the real power and power factor".  As written, it basically looks like you ignore any reactive contributions.
 * 1) Since you are explicitly calling out "control power" later in the specification, does that need to be defined in here as well?

= User Options =

Ftuffner 01:04, 13 March 2012 (UTC)
Bharat - Edited Bharat - Actually fan rating is included in controls power. It is not necessary to include fan rating separately.
 * 1) The first paragraph has a few grammar/phrasing issues that could be fixed.
 * 1) You mention changes can be made to the dishwasher, including a fan rating.  What is this fan rating?  I don't see it mentioned anywhere else.

Ftuffner 01:04, 13 March 2012 (UTC)
Bharat - Corrected Bharat - Deleted Bharat -  daily_dishwasher_demand  is not a probability. Actually, the probability that a given dishwasher is turned on depends on its daily demand D, and the value of the normalized appliance load shape. The higher these quantities are, the higher is the probability of the given appliance turning on.# You have three different coils listed in the inputs, but only one collection of ZIP quantities. Are all coils assume to be the same ZIP fraction? If so, you should probably indicate this. Bharat - Indicated in the equations section. Bharat - Assumed inductive
 * 1) Table 2 is still labeled as Table 1, but the title is right.
 * 1) You have motor_power listed twice in Table 2.
 * 1) Your daily_dishwasher_demand</tt> is again stated as a probability.  Probabilities are less than or equal to 1, by definition.  Is this really a percent?  If so, I'd argue you need an upper limit, as well.
 * 1) Since you are giving full access to ZIP factions for things, why are the individual component values fixed to be between 0 and 1?  The overall ones earlier in the table were allowed to vary from -1 to 1, why can't these?  How do you make sure the individual power factors go towards the larger power factor (since no mention of reactive components is mentioned above)?

Ftuffner 15:58, 11 April 2012 (UTC)
Bharat -  daily_dishwasher_demand </tt> is not a probability. Actually, the probability that a given dishwasher is turned on depends on its daily demand D, and the value of the normalized appliance load shape. The higher these quantities are, the higher is the probability of the given appliance turning on. Bharat - Addede the assumption Bharat - Included the explanation in ‘modeling approach’ section
 * 1) daily_dishwasher_demand</tt> still seems to be defined as a probability.  However, it defaults to 1 (start running no matter what?) and the upper value is not constrained to 1.  I'd also argue it should be inclusive of 0, since there may be times where there is absolutely not possibility the dishwasher wants to run (e.g., right after it finished).
 * 1) You mention ranges for the power factors.  Should you indicate somewhere the signing convention for the power factor value, or if something is assumed one way (e.g., "motor power factor - assumed inductive")
 * 1) What are the various queueing variables?  I see no other mention of any type of queue in the document and how these influence the operation.

Ftuffner 01:04, 13 March 2012 (UTC)
Bharat - Corrected
 * 1) The property energy_needed</tt> is specified in Watts.  It needs a time component to be energy.

Ftuffner 15:58, 11 April 2012 (UTC)
Bharat - Corrected = Dishwasher timing =
 * 1) This table is labeled as Table 2, but so is the one above it.

Ftuffner 01:04, 13 March 2012 (UTC)
Bharat- Discussed in “Dishwasher timing” section = Testing and Validation =
 * 1) I think you should mention the order a little more explicitly in here.  i.e., mention when state transitions occur, "device states" (on/off) are determined, and energy calculations.  It may also be worthwhile to include where in the GridLAB-D time progression (presync</tt>, sync</tt>, or postsync</tt>) these exist.

Ftuffner 15:58, 11 April 2012 (UTC)
Bharat - Included a typical dishwasher model
 * 1) This still needs to be filled out with the test cases and/or specifics.

= Final review =

Dchassin 16:04, 27 April 2012 (UTC)

 * 1) I've split this into various sections as identified in :Xref:Dishwasher.  Adjust the content as appropriate to reflect the expectations for each section. Any one piece of information should be provided only in one place according to who needs to know it.  Make sure the logical sequence of content for requirements, specifications, technical manuals, validation, and user manuals is respected, e.g.,
 * 2) Rename all variables to conform the GridLAB-D naming conventions and general good modeling practices:
 * 3) The variable names need to make sense to a novice user by describing the thing the variable represents is simple language. In particular, ordinal/cardinal names should only be used when the numbers actually are directly relevant to the model, e.g., line_1, line_2, line_N.
 * 4) The word dishwasher should never appear in the name of a variable in the dishwasher class.
 * 5) Names should never had capitals or abbreviations.
 * 6) All words in names should be separated by underscore.
 * 7) Units should not be included in the name unless it happens that by some happy coincidence the unit also describes the property in question.
 * 8) Make sure the specs describe the units of all properties and please make sure those units are correct. Be careful about things like probabilities, which in gridlabd are more often probability per unit time than absolute probabilities.