One thing I notice is that it is likely that batteries will have extra energy stored at the end of each period, because the battery only has information from the current timestep. Therefore I am wondering if the battery controller should also be passed information about the length of the simulation period?
In real life at any point the battery may be likely to have energy stored if you looked inside as it would be running continuously. Obviously the competition is not representing reality running in ten day increments, but it seems much more useful for the best battery controllers to operate how they would operate under continuous operation. Therefore, providing the length of the simulation period as an input to the battery controller is the only way to ensure that the best controller is also the one which scores best under the competition metric for the 10 days.
In this way the battery controller would have an option that says “even though the best option from the forecast is to store energy, I know the simulation period is ending therefore do not store”.
I’ll reply with what I think I understood from the competition rules.
You’re right that it would be more realistic to optimize the controller for continuous operation, but due here to the constraints of the evaluation, there is this finite horizon of 10 days. Participants are thus expected to build the best strategy to maximize the score on these 10 days, even if there is a small difference compared to an optimal controller for continuous operation.
The following is written explicitly in the doc of the BatteryContoller class: “This class is instantiated by the simulation script, and it can be used to store any state that is needed for the call to propose_state_of_charge that happens in the simulation.”
Since the simulation length is constant, you are free to exploit this yourself in your battery controller implementation if you would like.
In terms of doing this practically I am a little confused because we can’t change the inputs to propose_state_of_charge - if we did it would give an error when run by the scripts they provide.
Therefore, the way I imagine to do this at the minute would be having the battery_controller.propose_state_of_charge save a file with with each simulation start time in the assets folder, then in each call of propose_state_of_charge check whether this file exists. If the file doesn’t exist, create it and save the timestamp (if it doesn’t exist it will be the first simulation period). If the file does exist compare the timestamp of the current propose_state_of_charge call and make sure the battery is aiming to be empty at the 959th call (at the last call delete the file).
This seems like an incredibly complicated way of doing this when the simulation end timestamp (the last timestamp in g_df) could just be passed to propose_state_of_charge as an input.
Am I missing something?
Thanks for all the help!
EDIT: OK I just found out about class variables - maybe this is the way to do this… working on it!
Furthermore, it seems as though the way it is currently set up, if the battery finishes one simulation with a current_charge>0, then it will keep this level of charge for the start of the next simulation, except when it moves on to a new battery?
So you can store energy between one 10 day run and the next?