Time-based events in experiments

[brosaplanella]

Summary
Allow the definition of experiments based on actions happening at a given time which would be useful to simulate real usage scenarios. For example:

"On 2021-01-01 at 08:00 discharge at 1C until 2.5 V",
"On 2021-01-01 at 17:00 charge at C/3 until 4.2 V",
"Hold at 4.2 V until C/20",
...

The idea is that the experiment would add the necessary resting periods before and after the first action (triggered by the "On ..." statement) but would run the third one immediately after the second one (no "On ..." statement).

What are your thoughts? Still not clear to me what would be the best way to pass dates and times (e.g do we want to work with absolute dates, or can we also set up "On day 1..."?

Motivation
This would allow the simulation of real usage scenarios for electric vehicles.

[brosaplanella]

I have been thinking a bit more on the implementation and I think this is the best syntax:

"On day 0 at 08:00:00 discharge at 1C until 2.5 V",
"On day 1 at 12:00:00 charge at C/3 until 4.2 V",
"Rest until day 4 at 18:00:00",

(the last one is to add some padding in case you want to repeat a cycle that lasts exactly 4 days). I guess the main questions are:

• What are your thoughts on the syntax?
• Is it OK to start at day 0 or should we start at day 1? If the former, what you get is basically the time since the beginning of the experiment.
• Should we allow an option that is only "At 08:00:00 ..."?

[brosaplanella]

Adding to this issue, which format is preferable for the time stamps?

1. [Day 0 08:00:00] Do stuff
2. Day 0 08:00:00 - Do stuff
3. At day 0 08:00:00 do stuff

Note that the actual date format can change or we can allow for multiple options. I vote for option 1 or 2. Thoughts?

[valentinsulzer]

First one is my favorite of those.

We should definitely make use of the datetime module, allowing steps of the form DatetimeStep(datetime, instruction), e.g.

Experiment([
     DatetimeStep(datetime.strptime("21/11/06 16:30", "%d/%m/%y %H:%M"), "Discharge at 1C for 1 hour"),
     DatetimeStep(datetime.strptime("21/11/06 20:30", "%d/%m/%y %H:%M"), "Charge at 1C for 1 hour"),
])

datetime comes with lots of functionality for processing dates and times, so we don't have to reinvent the wheel here. It's also used by pandas.

However, we could still allow [Day 0: 08:00:00] in case it isn't for a specific experiment but just general testing.

we can allow for multiple options

We should be pretty restrictive here, since we don't want to have to maintain code to read all kinds of different cases. I think the two options we should allow are 1. [Day 0: 08:00:00] and 2. a datetime object

I know @awadell1 had some thoughts on this subject (making steps object instead of strings)

[brosaplanella]

Nice, I like the DatetimeStep idea. I guess the only (very small) caveat is that for datetime you have to define an actual date (even if a dummy one), but it can be bypassed if using [Day 0: 08:00:00].

Where should the DatetimeStep class live?

[1836005678]

This function is so important that I can't wait for the formal confirmation of the syntax.
One detail to mention, as we me use the [()]*i syntax to repeat experiments:
pybamm.Experiment( [ ( ) ] * 100 )
we may need to default the time to go back to the initial time (Day 0 08:00:00 for example) after each []. Otherwise setting up experiments will become a troublesome thing.
By the way, how to use the DatetimeStep funciton now?

[brosaplanella]

This function is so important that I can't wait for the formal confirmation of the syntax. One detail to mention, as we me use the [()]*i syntax to repeat experiments: pybamm.Experiment( [ ( ) ] * 100 ) we may need to default the time to go back to the initial time (Day 0 08:00:00 for example) after each []. Otherwise setting up experiments will become a troublesome thing. By the way, how to use the DatetimeStep funciton now?

Hi, sorry I missed your comment! There is no functionality to allow that for the time being, I am currently implementing it but I don't know how long it will take.

[brosaplanella]

A couple of questions:

• How do we want to store the extra rest periods? As a new step within the current cycle?
• At the moment I was just checking the timestamp for the next step, but I realised there could be a timestamp further down the line that could kill the current step and the following ones. Should I treat those as unfeasible experiments?

Any thoughts on that?

[valentinsulzer]

How do we want to store the extra rest periods? As a new step within the current cycle?

I think it should be added to the end of the current step, so that the number of steps in the solution is the same as the number of steps in the experiment, so that sim.cycles[i].steps[j] behaves intuitively

At the moment I was just checking the timestamp for the next step, but I realised there could be a timestamp further down the line that could kill the current step and the following ones. Should I treat those as unfeasible experiments?

Can you check all timestamps in the Experiment class and make sure they are in increasing order? Or am I misunderstanding?

[brosaplanella]

For the latter I ended up using next_timestamp which is the timestamp of the next step and end_timestamp which is the next timestamp (which might not be on the next step but later on). The former is used to add the rest periods and the latter is used to kill a simulation early.