-
Notifications
You must be signed in to change notification settings - Fork 114
Connect outage vars to powerflow #618
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…a lifetime variable using that escalation factor. Allows for the lifetime critical load to be an array of zeros if crit load is not specified
…k for grid outage inputs.
…tage_vars_to_powerflow
…ed as [0] in the defaults. Lines that check for outage always check for size first
…tage_vars_to_powerflow
…e critical load met
…specifed for any step
I am branching off of your branch and Paul's SAM branch and including the monthly outputs for the Puerto Rico project |
sjanzou
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, I am running into a hanging case at 67.8% file attached to this pull request

SAM project file case "PV Com grid out hanging"
Test_Case.zip
| if (resilience) { | ||
| resilience->add_battery_at_outage_timestep(*batt->dispatch_model, lifetime_idx); | ||
| resilience->run_surviving_batteries(p_crit_load[lifetime_idx % n_rec_single_year], power_input_lifetime[lifetime_idx]); | ||
| resilience->run_surviving_batteries(p_crit_load_full[lifetime_idx], power_input_lifetime[lifetime_idx]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is p_crit_load_full the percentage (or timeseries) entered by the user?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
p_crit_load_full is a timeseries extended to lifetime by the compute module. p_crit_load is the year 1 timeseries. The GUI converts percentages into a kW timeseries in the "$MIMO$ elecload" equations on the Electric Load Crit page.
| } | ||
| } | ||
| if (!crit_load_specified && batt->analyze_outage) { | ||
| throw exec_error("battery", "If grid_outage is specified in any time step, crit_load must have length > 0 and values > 0"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding this!
| if (resilience) { | ||
| resilience->add_battery_at_outage_timestep(*batt->dispatch_model, idx); | ||
| resilience->run_surviving_batteries(p_crit_load_in[idx % nrec], sharedInverter->powerAC_kW, dcPower_kW, | ||
| resilience->run_surviving_batteries(p_crit_load_full[idx], sharedInverter->powerAC_kW, dcPower_kW, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All are full lifetime now, yeah!
The issue is with peak shaving dispatch and not the grid outage. With either case in the above SAM file, the peak dispatch option will hang in SAM at 67/8% and debugging in the SDKTool, after the fixes in the Fix_issues branches of ssc and SAM to generate the lk script and match the grid targets dispatch option results, the issue is a stack overflow in the BatteryPowerFlow::calculateACConnected: |
Failing for peak shaving dispatch per comment above
add tolerance to grid charging check to allow for floating point issues
|
#620 merge still fails for case 3 of attached file per comment |
|
Can we drop #618 and just use 620 and the fix you do in dispatch_for_grid_outage? |
sjanzou
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we drop #618 and just use 620 and the fix you do in dispatch_for_grid_outage? Or, merge both in and then start a new branch to fix the resilency runner issue?
| // Error checking trying to charge from grid when not allowed | ||
| if (!m_BatteryPower->canGridCharge && P_battery_ac < -tolerance) { | ||
| if ((fabs(P_grid_ac - P_grid_to_load_ac) > tolerance) && (-P_grid_ac > P_grid_to_load_ac)) { | ||
| if ((fabs(P_grid_ac - P_grid_to_load_ac) > tolerance) && (-P_grid_ac > P_grid_to_load_ac + tolerance)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this in 620, too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I merged 620 into this branch, so yes.
|
This SAM pull request should be ready to merge with this when ready: NREL/SAM#707 |
…tage_vars_to_powerflow
…/NREL/ssc into connect_outage_vars_to_powerflow
|
@sjanzou In the interest of getting this merged sooner, I brought over a few key lines from
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All Test_case.sam cases running now with this branch (dispatch_for_grid_outages still broken as noted), this looks good to merge along with corresponding SAM pull request from Paul. Thanks!






Adds crit_load_escalation to the relevant cmods. Brings the variables from the vartables into battery->advance such that the powerflow variables can use the outage code.
Needs to be paired with a SAM PR based on critical-load-ui branch, @cpaulgilman to create.
A future PR (ssc branch dispatch_for_grid_outage) will implement the outage behavior in dispatch, and clean up edge cases like the inverter night time loads.
Via email we had proposed making grid_outage and crit_load SSC outputs - should that happen on this PR or a different PR? If this one, which cmods are responsible for the output?