Conversation
…OC values still suspect
…se for SRCC validation file from SoCo
…ed in SAM Tests not yet updated - going through some test issues but working in SAM per documentation
|
Validated with SRCC SoCo file and tests not updated yet. |
mjprilliman
left a comment
There was a problem hiding this comment.
Looks good, waiting for @brtietz to give final review
There was a problem hiding this comment.
Nice work getting the code running each timestep. I think there's still a little work to be done to the algorithm's SOC and the actual SOC to synchronize. See the drift here:
hopefully it should be an easy change. If SOC() doesn't work as a function (I spotted one case where I suspect that'd be the wrong units), energy_available(SOC()) should work instead.
| ssc_number_t battery_power_terminal = 0; | ||
| ssc_number_t forecast_power = 0; | ||
| ssc_number_t previous_power = m_batt_dispatch_pvs_outpower; | ||
| ssc_number_t battery_soc = m_batt_dispatch_pvs_battsoc; |
There was a problem hiding this comment.
Why is this not _Battery->SOC()?
There was a problem hiding this comment.
@brtietz , with battery_soc = _Battery->SOC(), the results are way off:
with battery_soc = _Battery->SOC() /100.0, closer but much worse agreement than using m_batt_dispatch_pvs_battsoc:
This is why I pursued the implementation in the SAM_744_rte branch of ssc
There was a problem hiding this comment.
We might want to rename some variables! This was a units issue. The algorithm expects batt_soc to have units of scaled energy (hours, I think) instead of percent. So if battery_energy was 0.2, batt_soc at 50% should be 0.1, not 0.5. I corrected this in cefbcf0
This changes the number of violations in the tests. I believe the new code is more accurate. Here is an example of the old code in the Phoenix_Validation_alloptions test file:
In reality, this is a violation, since the SOC goes to zero and the battery does not provide the desired power. However since the PV smoothing algorithm as pre-run, it didn't catch this. The new code does:
In fact, its two violations!
I'll get the tests cleaned up shortly, but it looks like we'll be able to get this in the patch!
There was a problem hiding this comment.
Tested and I went back to the Python code - now the scaling is looking good. Great work!
| double batt_dispatch_pvs_outpower() { return m_batt_dispatch_pvs_nameplate_ac * m_batt_dispatch_pvs_outpower; }; | ||
| double batt_dispatch_pvs_battpower() { return m_batt_dispatch_pvs_nameplate_ac * m_batt_dispatch_pvs_battpower; }; | ||
| double batt_dispatch_pvs_battsoc() { return m_batt_dispatch_pvs_nameplate_ac * m_batt_dispatch_pvs_battsoc ; }; | ||
| double batt_dispatch_pvs_battsoc() { return m_batt_dispatch_pvs_nameplate_ac * m_batt_dispatch_pvs_battsoc ; }; |
There was a problem hiding this comment.
I think some of our output woes are coming from this line. It doesn't make sense that an output with units of % would get multiplied by a value in kW. Apologies for not catching this before.
There was a problem hiding this comment.
Scaling updated but now the woes are coming from the resting SOC input for the pv smoothing not affecting the algorithm.
Good agreement within the ramp interval with the SOC values:
Issues with the low resting SOC ( about 7% instead of the entered 50% for case shown ) causing the battery not to be able to discharge at critical ramp times and causing anti smoothing effects:
There seems to be an issue with the SOC value used in the pv smoothing dispatch calculated in the charge controller which uses the dispatch model as input...maybe we can average the SOC input over the ramp interval instead of taking the instantaneous value - which does not correspond exactly in the data tables, e.g.
The tests have not been updated because the resting soc issue has not been resolved.
There was a problem hiding this comment.
The issue here was pv smoothing SOC was reporting smoothing + the next timestep's worth of power. With the changes in cefbcf0 - the SOC values should line up at the step when the smoothing dispatch was calculated, and then the battery SOC should increase or decrease until the next dispatch step. The second chart in #758 (comment) shows this behavior.
There was a problem hiding this comment.
Some places where the smoothed power is a little suspect:
Overall, very good agreement and much better - all tests passing on windows.
Reinstating all tests in last commit and the will merge after Github actions pass...
…p interval. The reseting pv smoothing SOC value is currently not reached.
…in. Still need to update tests, and maybe initial soc
…y from the battery
No description provided.