From GridLAB-D Wiki
Jump to: navigation, search

Overview

Dchassin 00:29, 13 March 2012 (UTC)

  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.

Bharat - Changed from numbers to words

  1. The equations need to be reformatted so they fit nicely on a printed page as well as in a normal browser layout.

Bharat - Reformatted all the equations.

  1. Figures are referenced without numbers.

Bharat - Added references to all the figures

  1. The queueing model needs to be explained very carefully so that programmers will know how to implement.

Bharat - Added the explanation in a separate section (modeling approach). Also, provided a reference document.

  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.

Bharat - Published all the time intervals.

  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.

Bharat - It was a typo. I deleted 11.1. Also, discussed all the details about the demand in "modeling approach" section

  1. Power factors are not between -1 and 1 because a power factor of 0 is not valid (is it leading or lagging 90°?). Please provide the correct constraints on PF so that they can be properly verifying during init().

Bharat - Corrected all the constraints.

  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 - Made some changes to the existing equations. Now, only one power factor is existing in the modified equations.

  1. Coils are by definition resistive elements. Why are power factors even needed?

Bharat - Corrected

  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.

Bharat - Modified the section

  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.

Bharat - Added a new section (usage of the dishwasher)for the explanation.

General Description

Ftuffner 01:04, 13 March 2012 (UTC)

  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.

Bharat - Deleted pump(s)

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)

  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.

Bharat - Corrected

  1. The third bullet has some grammar/phrasing issues that need to be fixed.

Bharat - Edited

  1. The fourth bullet is a little unclear what it means right here. Hopefully it is clarified further in the specification.

Bharat - Deleted the fourth bullet.

Ftuffner 15:58, 11 April 2012 (UTC)

  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.

BHarat- Check with Frank

  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.

Bharat - Edited

Dishwasher

Interfacing Overview

Ftuffner 01:04, 13 March 2012 (UTC)

  1. There are some general grammar/phrasing issues in this section that could use a bit of touch up.

Bharat - Edited

  1. You have two Figure 1 figures (one is Figure 1, I suspect the other is supposed to be Figure 3).

Bharat - Corrected all the figure numbers.

  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).

Bharat - Refered all the figures by numbers

  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 - In this state, dishwasher takes power only to drive control panel equpment.

  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".

Bharat - Figure 1 name changed to "Diswasher representative cycle"

  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?

Bharat - Not really, we could change it.

  1. Table 1 has the title from a different module (Microgrid Specifications from the looks of it) - be sure to change this.

Bharat - Corrected

  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.

Bharat - Replaced all the numbers with names.

  1. Consider typesetting variables inside Table 1 so they are differentiated from the description text. Consider using the <tt> or <code> formats to distinguish it.

Bharat - Typeset all the variables inside Table 1.

  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.

Bharat - Please suggest some names.

  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"?

Bharat - Corrected

  1. What constitutes a "load" for the accumulator? You say number of loads, but is this really a "% full" or similar item?

Bharat - Discussed in "modeling approach" section

  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.

Bharat - Yes, it happens twice.

  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").

Bharat - Yes

  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?

Bharat - All the state times and base energy value are fixed. However, user can change those values.

Ftuffner 15:58, 11 April 2012 (UTC)

  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.

Bharat - Please suggest some names.

  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.

Bharat - Values are estimated based on the energy consumption profile of the dishwasher [1]

  1. Fourth "paragraph" seems to want a table reference that is missing ("Table X below" - otherwise rephrase to "In the table below" or similar)

Bharat - Edited

  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"

Bharat - Check with Frank

  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?

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.

Equations

Ftuffner 01:04, 13 March 2012 (UTC)

  1. What are the [-] symbols in your equations? It looks like a typeset/render error, but I'm not sure.

Bharat - Deleted [-] symbols.

  1. You may want to explain what <math>P_{pf\_motor}</math> and the like are. It looks like they are suppozed to be power factor, but I'm not quite sure of that.

Bharat - Modified all the equations (<math>P_{pf\_motor}</math> is no longer used)

  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?

Bharat - Corrected all the equations. (Load current = load admittance = 0 for the motor only case)

  1. You mention things are modeled as ZIP factions, to which the Z is impedance. Why is everything labeled as "Load Admittance" then?

Bharat - Corrected

  1. The \mathrm usage looks a little odd - you may just want to make them variables and have a table.

Bharat - Check with Frank

  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?

Bharat - No

  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?

Bharat - Corrected as per your suggestion.

Ftuffner 15:58, 11 April 2012 (UTC)

  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.

Bharat - Check with Frank

  1. Since you are explicitly calling out "control power" later in the specification, does that need to be defined in here as well?

Bharat - Power required to drive control panel equpment.

User Options

Ftuffner 01:04, 13 March 2012 (UTC)

  1. The first paragraph has a few grammar/phrasing issues that could be fixed.

Bharat - Edited

  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.

Bharat - Actually fan rating is included in controls power. It is not necessary to include fan rating separately.

Dishwasher published inputs

Ftuffner 01:04, 13 March 2012 (UTC)

  1. Table 2 is still labeled as Table 1, but the title is right.

Bharat - Corrected

  1. You have motor_power listed twice in Table 2.

Bharat - Deleted

  1. Your daily_dishwasher_demand 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.

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.

  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)?

Bharat - Assumed inductive

Ftuffner 15:58, 11 April 2012 (UTC)

  1. daily_dishwasher_demand 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).

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.

  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")

Bharat - Addede the assumption

  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.

Bharat - Included the explanation in ‘modeling approach’ section

Dishwasher published outputs

Ftuffner 01:04, 13 March 2012 (UTC)

  1. The property energy_needed is specified in Watts. It needs a time component to be energy.

Bharat - Corrected

Ftuffner 15:58, 11 April 2012 (UTC)

  1. This table is labeled as Table 2, but so is the one above it.

Bharat - Corrected

Dishwasher timing

Ftuffner 01:04, 13 March 2012 (UTC)

  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, sync, or postsync) these exist.

Bharat- Discussed in “Dishwasher timing” section

Testing and Validation

Ftuffner 15:58, 11 April 2012 (UTC)

  1. This still needs to be filled out with the test cases and/or specifics.

Bharat - Included a typical dishwasher model

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:
    1. 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.
    2. The word dishwasher should never appear in the name of a variable in the dishwasher class.
    3. Names should never had capitals or abbreviations.
    4. All words in names should be separated by underscore.
    5. Units should not be included in the name unless it happens that by some happy coincidence the unit also describes the property in question.
  3. 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.