nikhilgupta10
commented
8 years ago nikhilgupta10 imported these comments from Sourceforge: The user dchassin does not exist anymore. Therefore assigning this to afisher1.
- attachment _test_regulator_outputvolt_single_phaseNR.glm added , This issue has surfaced again in a current class using GridLAB-D, including FBS implementations. The lack of phase checks on the tap checking and tap manipulation code is indeed the problem. Wrapping appropriate sections in \HAVE_PHASE\ or similar phase checks will likely fix it.
, Similar issue in ully tapped and no time delay\ regulators causing convergence failures (iteration limit reached). I contend this is bad model files and/or user error, but how regulators iterate a ailed\ positions may need to be re-evaluated.
Side note: Kevin Schneider has a bunch of files that fail these regulator scenarios in a variety of methods.
,
- version changed from trunk to 3.1
,
- Description has changed:
Diff:
- status: new --> assigned
- assigned_to: Jason Fuller --> Siddharth Sridhar
- Resolution: --> none
- Component: Powerflow --> powerflow ,
- Milestone: Version 3.1 RC1 --> Version 3.2 RC1 ,
- Owner: Siddharth Sridhar --> David P. Chassin
- Milestone: Version 3.2 RC1 --> Unscheduled ,
- Milestone: Unscheduled --> Version 4.0 RC1 ,
An issue was reported where the iteration limit was reached on a single-phase regulator performing output_voltage control. I confirmed this behavior was happening for NR only with control modes output_voltage, line drop compensation, and remote node. I will attach the file I used to confirm this behavior. Please not that this behavior is only happening in NR. Also, regardless of the solver used, maximum tap reached warnings show up for the phases not present on the regulator. Checking the code I saw that there are no phase checks for triggering tap changes for the previously mentioned control modes.
,