search

GMLC-1-4-2 / battery_interface

Implemenation of Device Models and their Battery Equivalent Interface
MIT License
5 stars 0 forks source link

Fleet-dependent time-steps as input arguments to services etc. #87

Open Hayden-Reeve opened 5 years ago

Hayden-Reeve commented 5 years ago

(@ORNLJD , @hlngo , @emayhorn , @yliu250 )

Some devices can currently not run at time steps short enough for the default conditions of some services (like Artificial Inertia). In addition, some fleets would like to have the time-step available during fleet initiation (in fleet_factory).

To address this sim_step will be provided as an input argument (in kargs) in a similar manner to how start_time is provided today. This thread will track the progress and issues on doing this. @Hayden-Reeve will work on the integration issues and updating some services to work with this approach.

Hayden-Reeve commented 5 years ago

@ORNLJD (cc @hlngo )

I have submitted #88 that puts sim_step in kargs and ensures it is set based on the service and device capabilities. I will update it in the future but wanted to post it so you can use it inside the fleet factory (that will need to be updated slightly too).

Hayden-Reeve commented 5 years ago

I have updated Reserve and Regulation services to accept the sim_step input. However, these services take in the drive cycle at a fixed time step. Therefore running at anything other than the default values (1 minute and 2 seconds) will results in bogus results. To prevent this I have included an exception to ensure that the default value is provided.

hlngo commented 5 years ago

@Hayden-Reeve Please mark me if they are ready to be merge.

Hayden-Reeve commented 5 years ago

@hlngo , will let you know. I need to check the readiness and integration for PeakManagementService first.

Hayden-Reeve commented 5 years ago

@afernandezcanosa , @can7huang

I have updated PR #88 with the proposed changes to the energy market service. They are minor and seem to work when testing them:

https://github.com/GMLC-1-4-2/battery_interface/blob/9926853c499e38be02053cb73f725e960bc0d05f/src/services/energy_market_service/energy_market_service.py#L299-L312

The only question I have is if the variable sim_step should also be feed into the initialization: https://github.com/GMLC-1-4-2/battery_interface/blob/abd4de5eebdf4643d76371fe1442b3fab13332f0/src/services/energy_market_service/energy_market_service.py#L23-L41

This is currently set at 1 hour steps - I assume this is appropriate. Also, any plans to update the code to save the plots etc? Can talk more tomorrow.

afernandezcanosa commented 5 years ago

@Hayden-Reeve @can7huang Thanks for doing so. For the initialization, we will probably have to do something similar to the process that @emayhorn did for the Peak Management Service to run the forecast method (Run a nested loop inside the main loop with smaller time step). I can do so if it is required.

However, I am worried about the API variables. According to the unit_test integration file that you shared with us, at this time, only PVs and EVs are able to provide P_service_min, P_service_max, Eff_discharge, Eff_charge with values different than None. These variables are required for this service to work properly. I opened an issue to address it (Item https://github.com/GMLC-1-4-2/battery_interface/issues/90).

Regarding the plotting, metrics, etc, I agree that we should incorporate these functionalities to the service code. I can do it without any problem if it is required, but we should first try to address the API variables that device owners must return. What are your thoughts? We can talk about this tomorrow at the meeting.

Thanks!