Talk:Spec:sync check

Jing Xie (talk) 20:31, 13 May 2020 (UTC) A couple of questions on the updated page:
 * 1) In this statement "In QSTS mode, the sync_check object will check current voltage and frequency metrics against the appropriate tolerance values, but multiplied by the deltamode_trigger_mult variable.", does the sync_check object check the voltage and frequency in QSTS when it is armed?
 * 2) It looks that the user should set 'deltamode_trigger_mult' as a value larger than 1, while we may not post a restriction it. Am I correct?

--Ftuffner (talk) 22:56, 10 April 2020 (UTC)

--Jing (response) 14 April 2020 (UTC)
 * [✔] Edited the Overview to indicate it is to parallel two separate power systems. We don't necessarily require it to be a microgrid.
 * [✔] Removed `name` and `parent` - these are base GridLAB-D object properties, so they don't need to be explicitly listed.
 * [✔] Changed `enabled` to `armed` - `enabled` is a little too nebulous, and may overlap with some existing properties.
 * [✔][Will not include this in future ones.] We really don't need the "mapped variable" name here - I left it in, but it's a level of detail that the specifications don't need.
 * [✔] Edited the sample usage, mostly because erroneous blank lines bug me.
 * [✔][Will be more concise in future ones.] The variable definitions are a bit much. You don't need to explicitly map everything out internally that you'll use. Having the published properties/GLM inputs, and then any equations, are typically sufficient.  This works, but this is a bit overkill for what is need.
 * [✔] Why are the frequency values complex? We'll dealing with numbers, not FFT outputs, not sure how you'd ever get a complex value.
 * [✔] `volt_norm` should probably be `nominal_voltage` pulled from one of the from/to objects
 * [✔] `freq_norm` should just be `nominal_frequency`, a powerflow global.
 * [✔] The Methodology section should include a mention of what it will do in QSTS. If that is just "trigger deltamode", so be it.
 * [✔][As deltamode step size does not change after entering the deltamode, I think the stepsize in nanosecond needs to be converted only once, then can be stored there.] `dt_dm` may not need to be explicitly defined, since it is already passed as part of deltamode (but just needs a conversion). Not sure why it would need to be defined here, which implies it is an object global.
 * [✔] In Methodology, maybe want to give com a different name or bigger name. It was quite confusing on the first read.
 * [✔] For Validation, why are no details included? These can be high-level, basically in what you've already provided.  I'm confused.
 * [✔] The Validation Results section isn't really needed here. Maybe in the Implementation page, but the theory is here your validation results should be "it passed".
 * [✔] If there are no references, that heading can be deleted.

Ftuffner (talk) 21:40, 15 April 2020 (UTC)

Jing (response) 15 April 2020 (UTC)
 * [✔] Changed `volt_diff` to reflect it is the magnitude, not the absolute value (since the inputs to the difference are phasors)
 * [✔] Removed `freq_norm` - it's a powerflow global, it doesn't need to be copied locally (that's just silly)
 * [✔][1) Updated the description of 'dev_volt' in the same way; 2) Changed 'dev_freq' to 'freq_diff_pu', 'dev_volt' to 'volt_diff_pu'] Changed `dev_freq` to reflect it being normalized frequency
 * [✔][1) 't_ud' is specified by the user for indicating how long do both metrics need to be satisfied before closing the switch; 2) 't_sat' is a member of the class for timing, i.e., it is a timer.] I don't understand what `t_ud` is, especially in the context of `t_sat`
 * [✔] Edited `dt_dm` entry
 * [✔][Edited based on our discussion.] For the QSTS behavior, I know that's what I said above, but some detail would be nice. Does it ALWAYS trigger deltamode, or on certain criterion?  i.e., when armed?

Ftuffner (talk) 14:20, 16 April 2020 (UTC)

Jing (response) 16 April 2020 (UTC)
 * [✔][Correct] Still confused on 't_ud' and 't_sat'. If I understand the above comment, 't_ud' is the actual user-specified value, while 't_sat' is just the internal tracking variable to "see how much of time of 't_ud' has passed".  Is that correct?
 * [✔] Modified QSTS description to be more detailed.