hlngo
commented
6 years ago This is the reply from @DavidRosewater
It was because of the integration test with the peak shaving service. At the end of each forecasted daily schedule the algorithm has to determine what power setpoint it would take to get the fleet back to its initial soc, to do this it needs to know what its final soc is at the end of the forecast - but the "forecast" method does not make changes to the soc state variable for the Fleet object - so I needed to add the soc variable to the fleet response so I could retrieve it from forecasts. If I was running forecasts for my research I would want to know what the soc state trajectory was anyway so I thought that it would get added at some point regardless of the specific need.
Regulation service uses property ".soc", which isn't there in FleetResponse. Need to double check with @jingjingliu2018.