From GridLAB-D Wiki
Jump to: navigation, search

Definition of Microgrids

By DOE definition, a microgrid can island and re-attach itself to a larger system, seamlessly. However, since we are not currently planning to model the microgrid in this way, we should probably mention it as part of the requirements...almost a negative requirement.

Dchassin 15:48, 24 November 2011 (UTC)

Recommend adding it to the use-case and/or application concept discussion.

Ftuffner 16:06, 2 December 2011 (UTC)

Updated application concept and use-case to reflect this expectation.

Req:Microgrids#R1.2.4 - Framework for future subtransient model

Dchassin 15:48, 24 November 2011 (UTC)

Be more definitive about what is required in generator models. As stated the requirement may be open-ended. Recommend restating it something like "Generator models shall support implementations of subtransient component models of PSS units, exciters and governors."

Ftuffner 16:06, 2 December 2011 (UTC)

Updated the description to match your recommendation. I don't particularly see the difference in how it is phrased. In my eyes, this was something the specifications would iron out more by defining the explicit interfaces.

Req:Microgrids#R1.3 - Non-rotating Generators

Dchassin 15:48, 24 November 2011 (UTC)

This requirement is a negative requirement. It is preferable to place such things in the use-case or application concept because negative requirement are always dead-ends: nothing shows up in the specs, dev, or test plans as a result. They just clutter things up.

Ftuffner 16:06, 2 December 2011 (UTC)

This "requirement" was moved up to the application concept section.

Req:Microgrids#R1.4 - Provisions for CHP equipment

Dchassin 15:48, 24 November 2011 (UTC)

This is stated as a negative requirement, which suggests no action. However, there is a positive requirement. It needs to be restated so that is specifically actionable, e.g., "templates of co-gen and CHP equipment shall be provided without behaviorial model support in the dynamic_solver."

Ftuffner 16:06, 2 December 2011 (UTC)

Rephrased to match your suggestion. Skeletal objects will be created, but the behavioral code will be added as part of a different task.

Req:Microgrids#R2 - Dynamic Solver

Dchassin 15:48, 24 November 2011 (UTC)

It is not at all clear to me the we should be requiring that the dynamic_solver be implemented as an object or even a class (which is actually what I think is the current intent). This sounds very much like the standard powerflow solver, i.e., something which is embedded in the module implementation and does not require the modeler to call out explicitly in a model after including the module directive to load the microgrids module. The decision on how to implement this is certainly something that should be made in consultation with developers.

Ftuffner 16:06, 2 December 2011 (UTC)

Addressing below, though "consultation with the developers" is pretty easy to do.

Req:Microgrids#R3 - Dynamic Solver

Ditto comments on R2. One simple way to solve the problem is to make no mention of the dynamic_solver in the requirement, but to simply state what the module must be capable of doing. Focus on what is needed, not how it is done.

Ftuffner 16:06, 2 December 2011 (UTC)

Adjusting the text to indicate dynamic solving capability. It is still unclear if this will be a module, an object, or a class, but that can be determined in the specifications.