Talk:Req:SubsecondInverter

--Melizondo 20:53, 20 May 2013 (UTC)

In R1.3 the term “voltage gain with saturation” is mentioned. Could you define “voltage gain”? It sounds to me that there will be a constant value multiplied by a voltage measurement or something like that. Did you mean controllable voltage source? If possible, you may want to describe this in terms of the physical system as in the other points within R1.


 * --Beau Van Kirk 21:40, 20 May 2013 (UTC)


 * This term, 'saturated voltage gain', was taken from the state space modeling paper I've often discussed (cited in the specifications page). When reading the paper, I was also initially confused as I also think of a constant multiplier when I think of gain. The essential idea is that you set the quadrature voltage components equal to the reference components as long as the limits are not violated, in which case you set them equal to the limits. Could we call this a controllable voltage source with saturation limits?

--Melizondo 20:53, 20 May 2013 (UTC)

It seems to me that R2.3.1 is repeating R1.3. R2.3.1 will be clearer after clarifying R1.3. E.g., if you call it controllable voltage source (if it makes sense), then you can say in R2.3.1 that you provide parameters of the controllable voltage source through the control algorithms.


 * --Beau Van Kirk 21:40, 20 May 2013 (UTC)


 * I disagree that these sections are redundant. The headings under R1 discuss modeling approaches, whereas the headings under R2 discuss different control modes. The way of modeling the inverter itself will be consistent throughout the various control modes.

--Melizondo 20:53, 20 May 2013 (UTC)

Are there any ideas on how to handle/model voltage/current unbalance? Will the inverter do anything special (or not) for unbalanced situation? There should be a requirement for this, I think.


 * --Beau Van Kirk 21:40, 20 May 2013 (UTC)
 * We haven't discussed this much yet. I have seen papers that discuss it, but I was assuming that this would be a feature to be handled later. In this case, perhaps we should list as a requirement that the model is assuming balanced conditions?


 * --Ftuffner 14:48, 21 May 2013 (UTC)
 * I'd look over the diagram we are modeling this off. See if that has any limitations on "assumed balanced" or not.  Based on what I can see, I'm guessing it will work in unbalanced conditions, but it is clearly controlling to maintain a balanced set.  If this is correct, it is worth mentioning somewhere in the requirements.  It's almost specification-ish, but since our over-arching requirement is to "match the hardware", it makes sense to put in here.


 * --Beau Van Kirk 21:40, 20 May 2013 (UTC)
 * The controllers are based on RMS voltage measurement input signals and the output phase signals are always equal magnitude and 120-degree phase separation, so there is no special handling for unbalanced. I added a requirement describing this, let me know what you think.

--Jcfuller 23:19, 20 May 2013 (UTC)

It's unclear -- is this intended as a new object, or as extended behavior to the current inverter class?


 * --Beau Van Kirk 23:30, 20 May 2013 (UTC)
 * I believe I had something in here about this at some point. I'm not completely clear but as I understood it this would eventually become the delta-mode model of the standard inverter class. Frank?


 * --Ftuffner 14:48, 21 May 2013 (UTC)
 * This should be under the existing inverter, under deltamode (but also in "normal" mode as well). We should put that in here somewhere, either as a specific requirement, or up in the general requirements section.

--Jcfuller 23:19, 20 May 2013 (UTC)

Are we only focusing on 3-phase, or shall single-phase (more common on residential) also be addressed?


 * --Beau Van Kirk 23:30, 20 May 2013 (UTC)


 * For starters, we're looking at 3-phase because this is the type of inverter included in ORNL's field test data. I'm still a bit unclear on how much future/speculated functionality not currently under development should appear in the Req pages.


 * --Ftuffner 14:48, 21 May 2013 (UTC)
 * The initial modeling effort will be focused on three-phase, since the aim is to validate against field data from a three-phase device. However, I'd recommend looking over the underlying model we hope to implement and see if it is explicitly three-phase or not.  I'd contend we could kludge a single-phase equivalent out of it, but we'll want to make sure it is capable of doing so.  At the very least, I think we should indicate the three-phase is the desired implementation, but will be written in such a way that future extensions to split-phase could be implemented.


 * --Beau Van Kirk 23:30, 20 May 2013 (UTC)
 * I agree that the controllers we're initially looking at could be easily adapted for a single-phase inverter. Since all of the input measurement signals are RMS, I think it would just be a matter of adjusting all of the tuning parameters (KPs, KIs, possibly droop curves) and using the 'phase a' output for the single phase output. Also we'd need a single-phase PLL. For now I've put in that we will eventually support single phase.

--Jcfuller 23:19, 20 May 2013 (UTC)

R1.1 & R1.2 are not compatible requirements. R1.1 isn't very specific (i.e., it sounds like "my model should be good"). Suggest R1.1 be re-written to be more explanatory. You may even consider combining R1.1 & R1.2.


 * --Beau Van Kirk 23:30, 20 May 2013 (UTC)
 * Jason, my original phrasing was something like you describe (with these two combined), but Frank split it out this way, affirming that each requirement should be as concise and discrete as possible. I'm hoping to see you two duke it out on here regarding the proper phrasing. I put my suggested rephrasing in the updated list at the bottom of the page.


 * --Ftuffner 14:48, 21 May 2013 (UTC)
 * As stated, they can be confused. More detail would make them clearer.  I don't particularly like the new R1.1, namely the parenthesis part.  I'd argue we aren't modeling dynamics related to voltage and angle stability -- we're not looking at stability, we're modeling the device -- plus are voltage characteristics all we're looking at?.  The switching dynamics could be brought back in as "switching transient dynamics above a 1-ms time frame (1 kHz) will be neglected" to help constrain it.  Basically, I want to somehow constrain this to not looking at EM-level impacts, if it can be helped.


 * --Beau Van Kirk 23:30, 20 May 2013 (UTC)
 * This should be more clear now. Please let me know if there are still parts that could be revised.

--Jcfuller 23:19, 20 May 2013 (UTC)

R1 is too much like a specification, not a requirement. It's too specific on the solution methodology.


 * --Ftuffner 14:48, 21 May 2013 (UTC)
 * I'm indifferent on this one. I agree it may be a bit too specific.  I'm not sure how to recast it though.


 * --Beau Van Kirk 23:30, 20 May 2013 (UTC)
 * Updated this requirement. Does this work better?

--Ftuffner 23:55, 28 May 2013 (UTC)

R2.2.2 is phrased a little odd. I'd recommend something more constraining like "framework will be implemented for future single-phase implementation support" or similar.

R2.2.4.6 needs a little rewording as well, to be more in line with the "requirements" nature of the document.