From GridLAB-D Wiki
Jump to: navigation, search

Issues identified

http://sourceforge.net/p/gridlab-d/tickets/471 consolidates questions regarding whether loadshapes satisfy the current requirements as we understand them, and whether it is implemented properly for those requirements. The following issues have been identified:

Loadshapes based on normalized schedules don't behave as expected
* 1-2 * * * 1.0
does not produce the same loadshape as
* 1 * * * 1.0
* 2 * * * 1.0
In particular, the normalization is not clearly defined, nor does it has a default interval (e.g., a 24 hour period over which the integral of loadshape 1).
Pulsed loadshapes do not provide the right "count"
Count needs to be defined - recommend it is defined over a 24 hour period (e.g. on a normalized schedule, a count of 4 will give 4 pulses in 24 hours - this will change if the schedule is not normalize).
Pulsed loadshapes do not provide the correct energy
By normalizing over a 24 hour period, this defines the energy to be used during that time.
Modulated loadshapes do not provide the correct energy
See above.
Unit conversion for loadshape components don't work
(originally http://sourceforge.net/p/gridlab-d/tickets/582)
Units for energy, power, time, etc. are not supported. Presumably this would be fixed by the completion of the structure data task (see http://sourceforge.net/p/gridlab-d/tickets/643), but until then either this needs to be addressed in loadshape itself, or documentation needs to be fixed to match reality.
Residential implicit enduses are not aggregating demand correctly
(originally http://sourceforge.net/p/gridlab-d/tickets/571)
It seems that the schedule fraction is set to zero regardless of whether the loadshape is energy or power based.
Queued loadshapes don't initialize correctly
(originally http://sourceforge.net/p/gridlab-d/tickets/488)
Although queued loadshapes seem to work relatively well, there are known instances when they are initialized to zero from the scheudle and cause other downstream calculations to fail.

Recommended Approach

  1. Reverse engineer the loadshape implementation
  2. Write the requirements for loadshapes based on the existing functionality
  3. Write the specifications for loadshapes based on the existing functionality
  4. Write the technical support document for loadshapes based on the existing functionality
  5. Write the implementation of loadshapes based on the existing functionality
  6. Review and critique the above to address the issues identified

Although the review should be done with a minimum of change to the Loadshape documentation and usage, the release of Hassayampa (Version 3.0) presents an opportunity to fix major issues such as those identified above. Don't be shy.

Proposed changes for Hassayampa (Version 3.0)

Req:loadshape#R1.1
The energy constaint is current for each block of the schedule. Recommend allowing the user to specify the time interval over which the energy constraint is given, with a default of 24 hours. A special interval option can be used to make the interval match the schedule block.
Req:loadshape#R1.4
Req:loadshape#R2.6
Req:loadshape#R3.5
Req:loadshape#R4.8
A triangle distribution is not very good. The randomization of the power amplitude output should be based on a truncated (-3,+3) normal distribution that is scaled such that it represents a unity probability (i.e., divided by ~0.99).
Tech:loadshape#Analog loadshapes
The use of automatic renormalization for the fixed energy shapes is inconsistent with the power shape. For one thing, schedule may already be normalized. Furthermore, there may be good reason why the user may want to allow scaling based on the schedule without renormalization. Perhaps it would be best to do away with renormalization and use the simpler formula
<math>y_t = \frac{E x_t}{T}</math>.
General use of the min<mean~stdev<max syntax
The syntax was introduced with scheduled loadshape and merits being extended to all loadshape parameters, e.g., power, energy, duration.