Sam 181 interconnection limits

[brtietz]

Pull Request Template

Description

Adds functionality preventing battery from discharging more than the interconnection or curtailment limit in a given timestep. Adds new variable batt_dispatch_auto_can_curtailcharge to allow the battery to only charge from curtailed energy. Charging applies to the following dispatch options:

FOM: automatic and manual
BTM: manual and retail rates

Fixes #181

Pairs with SSC PR NREL/ssc#1224

Type of change

Please delete options that are not relevant.

• [X ] New feature (non-breaking change which adds functionality)

Checklist:

If you have added a new compute module in a SSC pull request related to this one, be sure to check the Process Requirements.

• [X ] My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• I have checked my code and corrected any misspellings

[cpaulgilman]

Help revisions:

Grid Limits

BTM and FOM Battery Dispatch (under "Charge Options")

[cpaulgilman]

Thanks for adding this capability.

I noticed that Electricity to/from grid AC often hovers just below the grid interconnection limit with zero loss due to interconnection limit. This is for time steps with battery charging. (I compared with interconnection disabled to confirm that these are grid-limited time steps.) I see this for FOM automatic and FOM manual.

For the "don't overdo discharging" case, the battery charges up to around 93.98%, compared to closer to 94.9% for the "auto_fom_charge_from_interconnection_limited" case. Maximum allowed state of charge is 95%. I'm not sure if this is the same issue as above, the sign of a different bug, or just is how the math works.

For BTM retail rates, I see time steps where there are grid limit losses, but the battery is not being charged. Should the battery charge in this case even if the retail rate forecast doesn't call for it? It seems like wasting electricity. (It would be helpful to have an output for the battery dispatch price signal for this kind of analysis/troubleshooting.) For example, see Hours 132-134:

Thanks,
Paul.

[dguittet]

Looking at the BTM retail rate example, I'm not understanding how the forecast change here is supposed to help with the curtailment:
https://github.com/NREL/ssc/blob/36641dc2eda59ecb6606f2dd87b1def2ac2be4c0/shared/lib_battery_dispatch_automatic_btm.cpp#L409

Any thoughts about applying the curtailment similar to the clipping here?
https://github.com/NREL/ssc/blob/36641dc2eda59ecb6606f2dd87b1def2ac2be4c0/shared/lib_battery_dispatch_automatic_btm.cpp#L688

[dguittet]

I'm been testing out the DC battery to compare the curtailment charging against the clipping charging. In the manual case, I'm surprised to find that there's no impact on clipping or curtailment charging on some timesteps.

Here's the run without charging from clipping or curtailment. You can see the battery SOC is stable:

Then, when I add clipping and curtailment charging, you can see one timestep it charges, but another it doesn't:

[brtietz]

I'm been testing out the DC battery to compare the curtailment charging against the clipping charging. In the manual case, I'm surprised to find that there's no impact on clipping or curtailment charging on some timesteps.

Here's the run without charging from clipping or curtailment. You can see the battery SOC is stable:

Then, when I add clipping and curtailment charging, you can see one timestep it charges, but another it doesn't:

If "can charge from system" and "can charge from grid limited energy" are both selected, there will be no change since the battery will charge from the system and isn't forced to wait for the grid limits. Do we need to make UI adjustments such that this is more clear to users?

[brtietz]

@cpaulgilman Thanks for a detailed review! Your first error is fixed on ssc with NREL/ssc@36641dc

I think the second one is "just how the math works" - I see the same SOC percentages when running without interconnection limits.

For the third one, @dguittet 's idea on moving the curtail charging closer to clip charging was the right move. That's handled in NREL/ssc@710fe31

@dguittet :

Looking at the BTM retail rate example, I'm not understanding how the forecast change here is supposed to help with the curtailment:
https://github.com/NREL/ssc/blob/36641dc2eda59ecb6606f2dd87b1def2ac2be4c0/shared/lib_battery_dispatch_automatic_btm.cpp#L409

This helps properly value sending PV to the grid. If we apply the full export power, the cost forecast will assume more energy is exported to the grid than actually is with the grid limits. This is especially important for net metering. If grid limits are off, the interconnection limit is 1e+38, so the actual power is always chosen in the min function.

[cpaulgilman]

@brtietz Thanks for the quick response -- these latest commits address my comments.

[dguittet]

@brtietz Gotcha, thanks for the explanation

[cpaulgilman]

I'm been testing out the DC battery to compare the curtailment charging against the clipping charging. In the manual case, I'm surprised to find that there's no impact on clipping or curtailment charging on some timesteps.
Here's the run without charging from clipping or curtailment. You can see the battery SOC is stable:
Then, when I add clipping and curtailment charging, you can see one timestep it charges, but another it doesn't:

If "can charge from system" and "can charge from grid limited energy" are both selected, there will be no change since the battery will charge from the system and isn't forced to wait for the grid limits. Do we need to make UI adjustments such that this is more clear to users

@brtietz, three items:

1. UI Labels

Are the following labels an improvement?

Battery can charge from system
Battery can charge only from grid-limited power

2. Help Revisions

Any comments on these revised descriptions for Help?

Battery can charge from system

Allow the photovoltaic array or other power system to charge the battery.

Battery can charge only from grid-limited system power

If the interconnection limit is enabled and/or curtailment is specified on the Grid Limits page, allow the battery to charge from power in excess of the interconnection limit or from curtailed power. Note that if Battery can charge from system is also checked, battery charging may avoid grid limiting that would happen if it is not checked,

3. Question

If Battery can charge from system is checked and Battery can charge only from grid-limited power is not checked, will the battery ever charge from grid-limited power?

[dguittet]

I think the current behavior has it (at least for retail rates) so that if the Battery can charge from system is checked and Battery can charge from grid-limited power is not checked, the battery doesn't charge up the grid limited power... which for me begs the question of what it means to only charge from system exactly?

I think the "charge only from curtailed energy" option is very useful, and perhaps the "charge from system" should presume charging curtailed power.

[dguittet]

Otherwise, I think the functionality of curtailed energy charging is working across all the cases-- great job Brian!

[brtietz]

I think the "charge only from curtailed energy" option is very useful, and perhaps the "charge from system" should presume charging curtailed power.

Are you suggesting a possible change to https://github.com/NREL/ssc/blob/8be7ef0a48b4fa8f77bcd9a2874b500878917567/shared/lib_battery_dispatch_automatic_btm.cpp#L714 to run the while loop if just charge from system is checked?

[dguittet]

I think the "charge only from curtailed energy" option is very useful, and perhaps the "charge from system" should presume charging curtailed power.

Are you suggesting a possible change to https://github.com/NREL/ssc/blob/8be7ef0a48b4fa8f77bcd9a2874b500878917567/shared/lib_battery_dispatch_automatic_btm.cpp#L714 to run the while loop if just charge from system is checked?

Yeah, I think the curtailment should always be reduced in any dispatch algorithm that tries to minimize cost. Unless there's a clear meaning of what it means to "charge from system without charging from curtailed power" in any BTM dispatch algorithm, since I can't see how a dispatch algorithm would decide it's preferential to curtail. If it was somehow not worth the cycling cost, then it would probably not discharge.

Anyways I also ran a parametric on cycling cost for the retail rates which is kinda interesting:

[brtietz]

Anyways I also ran a parametric on cycling cost for the retail rates which is kinda interesting:

That is interesting! I think this comes down to the fact that it's really hard to trigger a battery replacement with our LFP default parameters, so encouraging cycling by turning the penalty off is a good thing. Doing a gut-check on those parameters might another GitHub issue, I'll put an item on tomorrow's agenda.

[dguittet]

Thanks for the new feature!