Talk:Spec:NEVDataFormat

--Jcfuller 23:19, 1 April 2014 (UTC) - In the example, what is the note about "wye spec"? I also can't find a reference for "voltage_wye". Bit confused with the clarifying example.
 * This should be on the NEVNode specification page and will be added if it is not. Added some clarifying text too.
 * Ftuffner 01:32, 18 April 2014 (UTC) Hopefully much clearer now. Adjusted voltage specification method to remove "delta" and "wye" fields.

--Jcfuller 23:19, 1 April 2014 (UTC) - It's unclear from this document whether this method will work with FBS or not. While I think after reading through, it should be obvious...it would be good to call it out specifically.
 * Ftuffner 21:44, 3 April 2014 (UTC) Well, not to be overly facetious, but it does mention Newton-Raphson at the beginning of every section. Added an explicit note to the top indicating this is NR-only.

--Jcfuller 23:19, 1 April 2014 (UTC) - Typo in Link/branch structure, 'from' variable description should be "from" not "to".
 * Ftuffner 21:44, 3 April 2014 (UTC) Copy-paste-itis strikes again. Fixed.

--Jcfuller 23:19, 1 April 2014 (UTC) - Is "link_type" only used for reliability, or is there a parent class of "link" that pulls in other classes?
 * Ftuffner 21:44, 3 April 2014 (UTC) link_type is only used for reliability, even in the current implementation. Special_lnk inside link objects serves a similar purpose for handling posting the admittance/impedance values and interpreting them (e.g., transformers).  This portion of the functionality will no longer be necessary since link objects will be handling their admittance postings/updates directly.  No "higher parent" class for link objects is expected beyond link, aside from the relevant powerflow_object class, which will need some minor changes for phase handling (but effectively does nothing).

= Emailed comments =

-- Under GLM inputs, how do you specify a WYE connected load? “1 2 3” gives you delta, would “1 2 3 4” give you WYE grounded? Would “1 4” be a single phase to ground load?
 * Ftuffner 21:44, 3 April 2014 (UTC) - Clarified this is just an example, but will make sure examples of both are on the relevant node page.

-- Will there be a volages_delta? We need to make sure that we can properly represent line-to-line, line-to-neutral, and single phase.
 * Ftuffner 21:44, 3 April 2014 (UTC) - Similar to the above comment, will insure this is addressed on the node specification page.
 * Ftuffner 01:32, 18 April 2014 (UTC) voltages have been redefined to a syntax similar to all other terminal-based connections. voltages_wye and voltages_delta are now just voltage</tt>

-- Node/bus Structure “voltage” is this still the line to neutral? We may need to adjust this since we are now allowing new combinations.
 * Ftuffner 21:44, 3 April 2014 (UTC) - Another item for the node specification page. The current plan is to support "L-G" and "L-L" voltage inputs.  L-N will need to be discussed since it requires mapping a neutral and treating it differently than just another terminal.

-- Node/bus Structure “terminal” does every terminal have a unique number? Similar to how nodes have a unique name? So instead of node 32 w have terminal “45 46 47 48”?
 * Ftuffner 21:44, 3 April 2014 (UTC) - Better for the node specification page. It's semi-implied here (and is now fixed on the overall specification page) - terminals are bit masks.  The numbers 1 - 64 will represent 64 unique phases that the user needs to keep track of.  Phase 1 could be "A", as could Phase 2, 3, and 5.  Or they could be "ABC".  A 5000-node GLM may only need to use the numbers 1, 2, and 3 (for A, B, and C), or the user may elect to assign unique numbers to different "versions" of A, B, and C.  The numbers just represent a unique "reference potential".  Specific assignments are left to the user to keep track of.

-- Link/brank structure “terminals_from” is this an object or a single terminal within an object?
 * Ftuffner 21:44, 3 April 2014 (UTC) This is a single terminal designation within an object. This is used in conjunction with the from</tt> field to determine connection points on the corresponding node</tt> object.

-- Do you need to properly specific the from and to values for node and terminal? Is there a way to combine these in a single designation?
 * Ftuffner 21:44, 3 April 2014 (UTC) We are open to suggestions. They are kept separate for ease of implementation and flexibility.  This effectively becomes the same as the phases</tt> property in the existing implementation, there are just phases</tt> for both sides now (since terminal 1 of the "from" side may not be what terminal 1 of the "to" side represents).  This is also an internal programming structure.  The link</tt>-object-level implementation should be discussed on the link specification page.