Resiliency metrics

[dguittet]

• Added SSC_ARRMAT, SSC_DATMAT to sscapi
	○ Added functions for set, get, size, clear, etc
	○ Added documentation
• Moved var_table conversion functions from compute_module
• Added move constructor to matrix_t
• Added copy ctors to dispatch models
• Battwatt configuration bug fixed (Qexp, Qnom), T_room
• Vanadium flow voltage equation fixed
	○ Negative sign
• Voltage_t equations
	○ Max discharge & charge power in next timestep
		§ Determined by model limits rather than SOC constraints
	○ Current for power
		§ Does not check model limits or SOC
• Lib_resilience
• Resilience_outputs in common.cpp
• Tests: lib_resilience_test
	○ Subhourly
	○ Lifetime
	○ AC & DC-connected where applicable
• Changed battery::run() to use new current controller
• `batt_custom_dispatch` units from kWDC to same as batt connection, so changes for AC-connected battery. Otherwise, need to know what the inverter efficiency at every time step will be in order to give dispatch in kWDC 
	a. Dispatch_automatic_front_of_meter_t::update_dispatch, behind_the_meter::update_dispatch
• Completed battstor copy constructor
• SharedInverter constructor inits all attributes and calculates nameplate for OND inverter
• SharedInverter::calculateACPower can use SharedInverter::None type which has fixed efficiency
• Cmod_pvsamv1
	○ Add crit_load
	○ Add if guard to batt object in case en_batt is false
• Cmod_battwatts
	○ Add crit_load
	○ Fix dt_hr bug which was determined as 8760/#ac instead of as 8760 * nyears / #ac
	○ Allow lifetime simulations using lib_time
• Cmod_battery
	○ Add crit_load
	○ Use shared_ptr for battstor

[sjanzou]

Please see comments at end of pull requests about test building and running issues and questions throughout about CentOS7 building and code generation and changes to sscapi and core.

[dguittet]

Please fix the Travis-CI tests, for example:

[ RUN ] CMBattery_cmod_battery.CommercialLifetimePeakShaving
/Users/travis/build/NREL/ssc/test/ssc_test/cmod_battery_test.cpp:26: Failure
The difference between roundtripEfficiency and 94.129 is 75.742375223090107, which exceeds 2, where
roundtripEfficiency evaluates to 18.38662477690989,
94.129 evaluates to 94.129000000000005, and
2 evaluates to 2.
[ FAILED ] CMBattery_cmod_battery.CommercialLifetimePeakShaving (1919 ms)
[ RUN ] CMBattery_cmod_battery.ResilienceMetricsFullLoad

This test is broken due to the current controller changing so that it follows the target time series more closely. The target time series is not balanced, resulting in the total power charged and discharged to become imbalanced-- hence the roundtrip efficiency which is discharged/charged gets changed.

So the question is should the test inputs be changed to use a better dispatch strategy, or should we replace the answer with the really low efficiency of 18%?

[dguittet]

[==========] Running 21 tests from 3 test suites.
[----------] Global test environment set-up.
[----------] 2 tests from CMBattery_cmod_battery
[ RUN ] CMBattery_cmod_battery.ResilienceMetricsFullLoad
[ OK ] CMBattery_cmod_battery.ResilienceMetricsFullLoad (1540 ms)
[ RUN ] CMBattery_cmod_battery.ResilienceMetricsFullLoadLifetime
[ OK ] CMBattery_cmod_battery.ResilienceMetricsFullLoadLifetime (4706 ms)
[----------] 2 tests from CMBattery_cmod_battery (6247 ms total)

[----------] 1 test from CMBattwatts_cmod_battwatts
[ RUN ] CMBattwatts_cmod_battwatts.ResilienceMetricsHalfLoad
[ OK ] CMBattwatts_cmod_battwatts.ResilienceMetricsHalfLoad (11352 ms)
[----------] 1 test from CMBattwatts_cmod_battwatts (11353 ms total)

[----------] 18 tests from ResilienceTest_lib_resilience
[ RUN ] ResilienceTest_lib_resilience.VoltageCutoffParameterSetup
[ OK ] ResilienceTest_lib_resilience.VoltageCutoffParameterSetup (212 ms)
[ RUN ] ResilienceTest_lib_resilience.DischargeBatteryModelHourly
[ OK ] ResilienceTest_lib_resilience.DischargeBatteryModelHourly (12 ms)
[ RUN ] ResilienceTest_lib_resilience.DischargeBatteryModelSubHourly
[ OK ] ResilienceTest_lib_resilience.DischargeBatteryModelSubHourly (16 ms)
[ RUN ] ResilienceTest_lib_resilience.ChargeBatteryModelHourly
[ OK ] ResilienceTest_lib_resilience.ChargeBatteryModelHourly (2 ms)
[ RUN ] ResilienceTest_lib_resilience.ChargeBatteryModelSubhourly
[ OK ] ResilienceTest_lib_resilience.ChargeBatteryModelSubhourly (3 ms)
[ RUN ] ResilienceTest_lib_resilience.PVWattsSetUp
[ OK ] ResilienceTest_lib_resilience.PVWattsSetUp (4 ms)
[ RUN ] ResilienceTest_lib_resilience.VoltageTable
[ OK ] ResilienceTest_lib_resilience.VoltageTable (0 ms)
[ RUN ] ResilienceTest_lib_resilience.DischargeVoltageTable
[ OK ] ResilienceTest_lib_resilience.DischargeVoltageTable (0 ms)
[ RUN ] ResilienceTest_lib_resilience.ChargeVoltageTable
[ OK ] ResilienceTest_lib_resilience.ChargeVoltageTable (0 ms)
[ RUN ] ResilienceTest_lib_resilience.VoltageVanadium
[ OK ] ResilienceTest_lib_resilience.VoltageVanadium (0 ms)
[ RUN ] ResilienceTest_lib_resilience.RoundtripEffModel
[ OK ] ResilienceTest_lib_resilience.RoundtripEffModel (2 ms)
[ RUN ] ResilienceTest_lib_resilience.RoundtripEffTable
[ OK ] ResilienceTest_lib_resilience.RoundtripEffTable (3 ms)
[ RUN ] ResilienceTest_lib_resilience.HourlyVsSubHourly
[ OK ] ResilienceTest_lib_resilience.HourlyVsSubHourly (2 ms)
[ RUN ] ResilienceTest_lib_resilience.PVWattsACHourly_Discharge
[ OK ] ResilienceTest_lib_resilience.PVWattsACHourly_Discharge (12 ms)
[ RUN ] ResilienceTest_lib_resilience.PVWattsACHalfHourly_Discharge
[ OK ] ResilienceTest_lib_resilience.PVWattsACHalfHourly_Discharge (33 ms)
[ RUN ] ResilienceTest_lib_resilience.PVWattsDCHourly_Discharge
[ OK ] ResilienceTest_lib_resilience.PVWattsDCHourly_Discharge (12 ms)
[ RUN ] ResilienceTest_lib_resilience.PVWattsDCHalfHourly_Discharge
[ OK ] ResilienceTest_lib_resilience.PVWattsDCHalfHourly_Discharge (33 ms)
[ RUN ] ResilienceTest_lib_resilience.PVWattsACHourly_Charge
[ OK ] ResilienceTest_lib_resilience.PVWattsACHourly_Charge (111 ms)
[----------] 18 tests from ResilienceTest_lib_resilience (460 ms total)

Resilience tests passing on Centos7.

Problem with travis is memory usage for lifetime simulations of resilience is really high (worse case scenario resilience_runner stores a battery model per timestep) so we'll need to increase the memory somehow...

[dguittet]

Nearly all battery tests passing:

ssc/test/Testd --gtest_filter=att
[----------] Global test environment tear-down
[==========] 40 tests from 12 test suites ran. (223910 ms total)
[ PASSED ] 38 tests.
[ FAILED ] 2 tests, listed below:
[ FAILED ] CMBattery_cmod_battery.CommercialLifetimePeakShaving
[ FAILED ] BatteryPowerFlowTest.TestACConnected_lib_battery_powerflow

fixed BatteryPowerFlowTest in ef3b3d8

The grid charging enforcement was moved to batteryPowerFlow until we can make check_constraint enforce it properly as explained in comment responding to @janinefreeman for test results change in lib_battery_dispatch_test.cpp

CommercialLifetimePeakShaving requires either changing the inputs or keeping an answer with low roundtrip efficiency as explained in comment responding to @janinefreeman for cmod_battery_test.cpp

[dguittet]

Thanks so much for the review so far!

remaining questions:

1. SSC_INOUT group name from Time Series to Load, does that affect display in SAM? @cpaulgilman

2. CommercialLifetimePeakShaving test results @janinefreeman

3. SAM doesn't use new SSC_DATARR and SSC_DATMAT types but should its functions be ready to do so at this moment? @sjanzou

4. high memory usage in resilience simulations breaking travis and potentially resulting in hard crash on users' computers if the memory usage exceeds capability @sjanzou

5. cmod_merchantplant_eqns documentation @janinefreeman @sjanzou

Please let me know if i forgot anything!

[janinefreeman]

Sounds like the 18% round trip efficiency in the CommercialLifetimePeakShaving test is a real result, so I say we update it to match the new answer.

Sorry, which merchant plant documentation do we need? Should we add it after merging in this branch?

[dguittet]

Sounds good, thanks for your input!

I don't mind adding the docs. I'll create a new PR for develop