ROMS restart time steps

Report or discuss software problems and other woes

Moderators: arango, robertson

Post Reply
Message
Author
c.drinkorn
Posts: 83
Joined: Thu Mar 08, 2018 2:47 am
Location: German Research Centre for Geosciences

ROMS restart time steps

#1 Post by c.drinkorn » Mon May 27, 2019 11:17 pm

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....

User avatar
kate
Posts: 3718
Joined: Wed Jul 02, 2003 5:29 pm
Location: IMS/UAF, USA

Re: ROMS restart time steps

#2 Post by kate » Tue May 28, 2019 4:00 pm

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?

c.drinkorn
Posts: 83
Joined: Thu Mar 08, 2018 2:47 am
Location: German Research Centre for Geosciences

Re: ROMS restart time steps

#3 Post by c.drinkorn » Wed May 29, 2019 8:34 am

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...

c.drinkorn
Posts: 83
Joined: Thu Mar 08, 2018 2:47 am
Location: German Research Centre for Geosciences

Re: ROMS restart time steps

#4 Post by c.drinkorn » Thu Jun 06, 2019 2:31 pm

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. :roll:
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. :idea:

c.drinkorn
Posts: 83
Joined: Thu Mar 08, 2018 2:47 am
Location: German Research Centre for Geosciences

Re: ROMS restart time steps

#5 Post by c.drinkorn » Fri Jun 07, 2019 11:50 am

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?

Post Reply