Hi all,
I have a simple question: Why does ROMS store the last time step of the restart file one hour after the model time domain instead of the very last time step so I can use it as a restart initial?
My model time step is 600s and I am simulating 52560 time steps (one year). NRST is set to 144 in order to write out restart fields every day. I have LcycleRST flag set to true. In the end I get the two last time steps of which the very last consists of NaNs because it is outside the model time domain.
Maybe I misunderstood the way restart works....
ROMS restart time steps
-
- Posts: 110
- Joined: Thu Mar 08, 2018 2:47 am
- Location: German Research Centre for Geosciences
Re: ROMS restart time steps
That's weird, that's not what I get. Is there something about your forcing that ends before the end of the year? Do you see the NaNs in the ROMS output for the last few steps?
-
- Posts: 110
- Joined: Thu Mar 08, 2018 2:47 am
- Location: German Research Centre for Geosciences
Re: ROMS restart time steps
Hi Kate,
all of my forcing and boundary files range from Jan-01 00:00:00 this to Jan-01 00:00:00 of the next year. So this should be fine.
I realized that all sediment related variables do have values in the additional rst fields. Now that I switched Lcycle back to false I get 367 rst fields of which the last two are both Jan-01 01:00:00 of the next year. For non-sediment related variables these are NaNs but, as I wrote before, all sediment related variables have values. I have already encountered some strange things regarding sediments and restart in combination with PERFECT_RESTART (viewtopic.php?f=20&t=4764). I suspect something got confused in the output routines with the additional sediment variables. I could try a snippet of the simulation without the SEDIMENT option and see what happens...
all of my forcing and boundary files range from Jan-01 00:00:00 this to Jan-01 00:00:00 of the next year. So this should be fine.
I realized that all sediment related variables do have values in the additional rst fields. Now that I switched Lcycle back to false I get 367 rst fields of which the last two are both Jan-01 01:00:00 of the next year. For non-sediment related variables these are NaNs but, as I wrote before, all sediment related variables have values. I have already encountered some strange things regarding sediments and restart in combination with PERFECT_RESTART (viewtopic.php?f=20&t=4764). I suspect something got confused in the output routines with the additional sediment variables. I could try a snippet of the simulation without the SEDIMENT option and see what happens...
-
- Posts: 110
- Joined: Thu Mar 08, 2018 2:47 am
- Location: German Research Centre for Geosciences
Re: ROMS restart time steps
Ok, I got one step further but still didn't succeed. I figured the problem with the additional restart time step was nonsense. The additional time step was simply the one written after blow up.
However, the blowing up still remains and without the sediment option restart works fine. I now try one run without SED_DENS even though I couldn't find anything strange in the routines for the EOS with suspended sediments involved.
I just stumbled across one thing: I use analytical sediment initial conditions. In the analytical there is the code where the initial tracer variable value for suspended load is set to Csed which in my case is 0. However, from the previous run this should be the field from the restart file. I couldn't find any exception in case of restart mode for this assignment. Indeed, my suspended load is zero everywhere in the blow up restart time step.
Thank you for any help with this! I am still trying to fix this myself, too, of course.
However, the blowing up still remains and without the sediment option restart works fine. I now try one run without SED_DENS even though I couldn't find anything strange in the routines for the EOS with suspended sediments involved.
I just stumbled across one thing: I use analytical sediment initial conditions. In the analytical there is the code where the initial tracer variable value for suspended load is set to Csed which in my case is 0. However, from the previous run this should be the field from the restart file. I couldn't find any exception in case of restart mode for this assignment. Indeed, my suspended load is zero everywhere in the blow up restart time step.
Thank you for any help with this! I am still trying to fix this myself, too, of course.
-
- Posts: 110
- Joined: Thu Mar 08, 2018 2:47 am
- Location: German Research Centre for Geosciences
Re: ROMS restart time steps
I got another step further: Only undefining SED_MORPH makes the restart blow up disappear. But since I want a time-evolving bathymetry I will investigate this further and report. SED_MORPH is meant to work with restart, right?