search

MPAS-Dev / MPAS

Repository for private MPAS development prior to the MPAS v6.0 release.
Other
4 stars 0 forks source link

Landice: config_start_time='file' sometimes fails if restarts are written at weird times #1510

Open matthewhoffman opened 6 years ago

matthewhoffman commented 6 years ago

To make the model work correctly, it becomes necessary to manually set config_start_time to the required restart time - using the restart_timestamp does not seem to work.

Need to get a minimally working example to test.

One idea: the problem might go away if you set config_adaptive_timestep_force_interval to the same value as the output_interval set for the restart stream. (in the run that is creating the restarts - it won't help to make the change when you are trying to start a restart from a run that did not have this set.)

xylar commented 6 years ago

@matthewhoffman, I recall having seen something like this when I tried to change the restart interval e.g. from every 5 days to every month and my restart file is now not an even number of months since the simulation start time. Is that issue related to what you're experiencing?

matthewhoffman commented 6 years ago

@xylar , yes I think so. @stephenprice is the one who has encountered this. It appears when the adaptive timestepper leads to a restart timestamp that is arbitrary but soon after the nominal restart time. We have an option for the adaptive timestepper that forces it to hit the nominal time, but when we forget to use that option this problem crops up. I'm just flagging it to try to get to the bottom of eventually.

xylar commented 6 years ago

It seems like the desired behavior in both the case I describe above and the one you're running into would be that the model restarts from the restart file and time as given (rather than trying to find a nearby time that exactly conforms to the requested restart interval and simulation start time) and to run the simulation from that point until the next requested restart interval.

I suppose problems could potentially arise if the adaptive time stepping produces a restart file that is just short of the requested restart time (rather than just past it), leading to another restart being produced just after the restart time is passed. Without knowing more about how your adaptive time steps works with restarts, that's only blind speculation...