Talk:Spec:Transmission

--Jcfuller 06:15, 19 June 2012 (UTC)


 * Module Overview
 * Added a rough figure showing how the various objects break down and interact, just to make sure we're all thinking about the same thing. Ftuffner 15:09, 25 June 2012 (UTC)
 * Not sure we want this to be the "powerworld" module. Suggest something along the lines of "transmission" or "network" module, then reserve the powerflow for the object level.
 * The first cut of the module is going to be 'direct', using SIMAuto and hooking straight into PowerWorld, without wiggle to adapt to something else. This is the limitation of the COM interface.  A gobo will allow some abstraction in GridLAB-D. Mhauer 19:10, 21 June 2012 (UTC)
 * Agreed. I'm okay with the actual implementation.  It's more of a naming convention that allows for later expansion. --Jcfuller 23:32, 22 June 2012 (UTC)
 * I believe the concensus has been to put this under the network module. Ftuffner 15:09, 25 June 2012 (UTC)


 * What is meant by "model file"? Is this the GLD distribution model file, the standard PW model file, a GLD connections file, or something else?
 * In the overview, the PW model file. The powerworld model object pw_model contains information about the powerworld model object. Mhauer 19:10, 21 June 2012 (UTC)


 * "power values": are we only posting power values, or are there other ZIP values we can post?
 * We can implement ZIP values. They were avoided since they are specified in nominal-voltage power values (so power was the easiest to directly implement), but we can expose the functionality. Ftuffner 21:54, 21 June 2012 (UTC)


 * You've described pw_model and pw_recorder, but not pw_load...and how do they all go together?
 * Added a sentence or two about pw_load. Mhauer 19:10, 21 June 2012 (UTC)


 * I/O
 * GridLAB-D
 * in update_flag, what is the pw_node object? Hasn't been discussed before.
 * Typo. pw_node has been renamed to pw_load. Mhauer 19:10, 21 June 2012 (UTC)
 * in pw_load, can we change variable name "model" to "load_model" or "model_object" or "load_object" or ??, otherwise too generic
 * It'd be easy to change to 'model_object', but it'll need to be present for every pw_load object defined in the GLM file, and may be obnoxious to type out. For those of us not using scripts to generate model files, at least. Mhauer 19:10, 21 June 2012 (UTC)
 * I'd argue those not using scripts aren't going to type it out 200x anyways. I think "pw_model_object" or similar should be fine.  It's a lot of typing, but that's the purpose of copying and pasting. Ftuffner 21:54, 21 June 2012 (UTC)
 * "powerworld_load_id": where is the association for this id, PW id or GLD id?
 * PowerWorld ID. It's a PW key field, and is required to uniquely identify the object in PW. Mhauer 19:10, 21 June 2012 (UTC)
 * "power_threshold": I believe we want this to be MVA, not MW, yes?
 * Yes, along with an aggregation of all of the implemented ZIP postings. Do we want separate thresholds for each? Ftuffner 21:54, 21 June 2012 (UTC)
 * I'll change it to MVA for power threshold. Logically we'll want separate thresholds for each, and proper units for each. Mhauer 22:06, 21 June 2012 (UTC)
 * Yes. Definitely thresholds on each. However, I'd recommend determining each of those thresholds in terms of MVA (even for current and impedance) and only allow a single variable to define all thresholds (or something along those lines) --Jcfuller 23:32, 22 June 2012 (UTC)
 * "load_voltage": Do we also need to know which phase this is associated with, or will we always assume phase A?
 * PowerWorld appears to use positive sequence voltage, so phase is moot. Mhauer 19:10, 21 June 2012 (UTC)
 * To a degree, but not necessarily so. If we wanted to connect a feeder as a particular "start" sequence, it should be pretty straight forward.  I suspect this is always assumed to be phase A, but I may be missing something. Ftuffner 21:54, 21 June 2012 (UTC)
 * in pw_recorder, variable name "model" is okay to be generic here...points back to changing it to another name in other places
 * why is the log output file automatically generated? This is not consistent w/ GLD, and could be a performance hit with larger models. Is there at least an option to turn off completely?
 * It's like a recorder. If you don't want the log output, don't include the recorder? Mhauer 19:10, 21 June 2012 (UTC)
 * But you don't have the ability to select data points? i.e., it's like the auction log rather than a recorder --Jcfuller 23:32, 22 June 2012 (UTC)
 * last paragraph: pertaining to updates, how do we guarantee the order of operations...i.e., how do we KNOW that voltages will be applied before powerflow during sync cycle? (parent/child relationships have not been described).
 * Parent/child relationships have been briefly mentioned in a glancing fashion. The pw_load object must be a parent to the powerflow substation for things to work properly.  Pull voltage at presync, pass down through children, accumulate currents during sync, clear accumulators during postsync. Mhauer 19:10, 21 June 2012 (UTC)
 * Pull which voltage at presync? PowerWorld?  Do we do this every cycle, or do we trigger this off of the "NR_cycle" variable? Ftuffner 21:54, 21 June 2012 (UTC)
 * Pull PW voltage at presync and feed it through it a top-down fashion. We could trigger it off the NR_cycle variable, so as to only change the value when we're going to be recalculating the system with those values. Mhauer 22:06, 21 June 2012 (UTC)
 * The spec actually just says that they will be attached to each other, but doesn't explicitly describe the parent-child requirements --Jcfuller 23:32, 22 June 2012 (UTC)


 * General
 * I see a way for the load to signal PW to re-calculate, but what about the reverse? Couple case where this might be need:
 * if there are multiple instances of GLD attached to PW and one updates (which causes PW voltages to update), do all GLDs need to update or only ones w/ x% voltage change?
 * This will only work with one pw_model object in the system. Odds are that all the pw_load objects, and the pw_model object, will be found in the master GLM, should there be multiple instances, and the powerflow will split off and do its thing in a partitioned fashion.  There is not yet a recognized way to send a signal from PW to GLD, partly because we are not modifying the PW code, only interfacing with the (untimestamped) simulation. Mhauer 19:10, 21 June 2012 (UTC)
 * A script (say N-1 contingency) is run in PW, how does PW signal GLDs to recalculate and update their voltages?
 * GLD triggers the script and sttarts the update/sync/signal process when the script has finished running. Hypothetically. Mhauer 19:10, 21 June 2012 (UTC)

--Dchassin 14:35, 19 June 2012 (UTC)


 * We need to consider the name of the module with some care. TDIntegration doesn't seem appropriate--that's the name of project. I agree that "powerworld" is tool-specific, unless we intend for this module to be really be only for "powerworld".  That is ok with me if that makes sense--I really don't see the utility or need to making a truly generic module if much of the interaction is controlled by the module.  On the other hand, if the interaction really is controlled only by the "pw_*" objects, then I would make the module name very generic, e.g., "transmission".  From the requirements it's hard to tell whether that really is the intent.
 * The decision appears to be to name this "network" and put "pw_"-prefixed obejcts in at this time (and change the prefix for later solvers). This was left intentionally ambiguous in the requirements document mainly as a "just make it work, I don't care where it goes" implementation.  It was unclear at the beginning if this would be a separate module, or folded into powerflow somehow.  Ftuffner 23:06, 21 June 2012 (UTC)
 * The published outputs of the pw_model object should include a solution status or flag from powerworld.
 * The return from the COM call includes an error status (if any) and the error message, these can be published for the XML output prior to the system coming to a halt. Mhauer 19:10, 21 June 2012 (UTC)
 * We may be able to extrapolate a "solution status" out of this. Basically, if it didn't error, it probably solves successfully. Ftuffner 21:54, 21 June 2012 (UTC)
 * Coincidentally, no message -> no error. Mhauer 22:06, 21 June 2012 (UTC)
 * Shouldn't the load be described with some detail, e.g., like "cmpldw", so that it includes not just ZIP components, but also PE, PV and motor data? We are talking about being able to change those values in GridLAB-D and have Powerworld respond accordingly.
 * The PW load objects, specifically, only include ZIP values. We haven't discussed attaching to more complicated PW objects. Mhauer 19:10, 21 June 2012 (UTC)
 * It was speculated this type of functionality is coming in the next version of PowerWorld. Regardless, I'd suspect it is probably part of their transient stability toolbox. Ftuffner 21:54, 21 June 2012 (UTC)

--Jcfuller 23:32, 22 June 2012 (UTC)
 * Substation property hooks
 * I've never tried it before, can the SWING node have a parent object in NR method, albeit a non-powerflow object?
 * This is a good question. Generally node parents are assumed to be powerflow objects.  We may have to adjust the logic so it doesn't outright fail. We should probably indicate this in the specs. Ftuffner 15:09, 25 June 2012 (UTC)
 * "if present": what if the pw_load is not attached? Does this just act like a normal node?
 * I think this should be a reasonable implementation. If it doesn't have a parent, it becomes a plain old powerflow node, SWING or just the top of an FBS branch (depending on the solver). Ftuffner 15:09, 25 June 2012 (UTC)
 * Appliances work without houses, houses work without meters, and meters work without a series of nodes, links, and tubes connected to them. This makes perfect sense to have the Substation operate as a normal swing node if no pw_load or similar parent exists above it, and using the internal or player-set voltage values instead. Mhauer 17:34, 25 June 2012 (UTC)
 * "calculate the average power": there is no 'average' for a complex number. Let's be clear about what this means (i.e., is this average P and average Q, or average S and average pf?).
 * the "reference phase for the GridLAB-D powerflow solution" sentence is a bit unclear about what that means. Expand and explain better.
 * Should we also explicitly describe the variable mapping here? As in, "positive_sequence_voltage" will be mapped to "load_voltage" in pw_load object.  Similarly for power measurements.
 * "average_phase_load" is on odd term, I'm not even sure what it means. Maybe something like "average_load_power" or "average_measured_power"?

--Ftuffner 01:24, 27 June 2012 (UTC)
 * Module Overview
 * I'm still not too clear exactly how the data exchange is occurring. Does pw_load request/post data THROUGH pw_model, or does it send it to pw_model and pw_model posts/retrieves it from PowerWorld?  Can we get a brief example of the data exchange between everything to make it clear?
 * pw_load
 * We need to add the ZIP functionality to the pw_load model. A value and a threshold are needed for current and impedance loads.  Do we want to keep this with the "no calculations" aspect of the pw_load object and have them be raw values in (MW,MVAr), or post as complex values that pw_load will adjust to PowerWorld inputs?
 * Another output field of "load_nominal_voltage" or similar may be needed, depending on the response to the previous comment.
 * Substation property hooks
 * Depending on the functionality required, we may need to expand substation to be more meter/load oriented. This may include properties for constant_power_X, constant_impedance_X, constant_current_X, and the like.  The question I have is whether these explicit quantities are needed here or not.  I'm also not sure if we want to fold these directly into pw_load and let PowerWorld handle them, or aggregate them into the "average_phase_load" value and let the GLD powerflow handle them.
 * We may need a "transmission_nominal_voltage" or similar field if the above PowerWorld load functionality is incorporated.
 * "transmission_nominal_voltage" may also be handy if the transmission solver fails, simply in order to get the powerflow solver to do its thing if the transmission side is getting pushed to its limits, or if it has a bad run that can get shaken out with the next pass. Mhauer 00:18, 3 July 2012 (UTC)

-- Ftuffner 15:12, 5 July 2012 (UTC) --
 * Added a description of what happens in which sync pass. Mhauer 00:18, 3 July 2012 (UTC)
 * Discussions with Frank concluded that the Substation will be where any phase handling goes on, while the pw_ objects will stay with 'native' PowerWorld voltage and power formats. Mhauer 00:18, 3 July 2012 (UTC)
 * Added in fields detailing the additional ZIP components for the pw_load and substation interaction.
 * We need to add how the three-phase power/impedance/current gets translated to the positive-sequence "power" equivalents.