timestep musings

[kate]

Enrique, Wei and I have all experienced the ROMS crash after months/years of smoothing running. I have tried to sneak up on it, saving a restart file just before the crash and trying to observe the crash in the debugger, only to have it not crash at all. It's like something in the (imperfect) restart procedure is increasing the stability of the run. which makes me wonder some things:

* Has anyone else seen this?

* Are the people in the PERFECT_RESTART club having stability problems?

* Is it only a feature of the Rutgers Repository ROMS?

* Is the UCLA ROMS more stable? See https://www.myroms.org/wiki/index.php/N ... g_Overview for the timestepping differences.

[hetland]

For what it's worth, I have seen this exact sort of behavior. Sometimes, I need to decrease the timestep, but sometimes, I just need to restart the run, and it sails through the previous crash without any problems. I usually don't even see any problems in the history file that suggests that a problem was affecting the solution...

[edeng]

I have experienced this as well, using a ROMS AGRIF version (from around 2005) with tides enabled:
My run terminated due to blowup, and so I restarted just before the blowup, outputting every time step, and found a few points with wacky temperature profiles (i.e. the middle of the temperature profile looks like an accordion, way too negative and way too positive) but for only a few time steps. Then the temperature profiles, at least at that point, go back to normal, but only in the restarted run, and I think, only when I output every time step.

My solution was to decrease the time step from 120s to 90s.

There are probably more issues with that run than just the timestep/restart/stability issue, but perhaps it gives more evidence to figure it out?

Best regards,
Eileen

[crowley]

This sounds familiar, but I think I was seeing it from the other side. Things would blow up after a restart, but then i would try restarting from a different time--sometimes an hour before or after, sometimes only a few timesteps away--and all would be well. I knew I was running really close to the edge of stability and just figured that the restart was kicking things at the wrong time.

[linzhenhua]

I have a related quation about this topic.
Since this issue may be related to the time step.I know the famous CFL critera, delta_t<delta_x/velocity for simple case.

I want to know,when using ROMS,for 3D simulations,generally how you calculate the time step?

Or a similiar question,when the model blow up after some time,instead of using restart,or continue the model with a smaller time step,have you tried from the start with a smaller time step?

[m.hadfield]

I find that to avoid mysterious crashes in ROMS 3D simulations it is a good idea to:

• Set the short time step so that the maximum barotropic Courant number is 0.9 or so. You can go higher without triggering a crash in the barotropic part of the model, but pushing the limits here seems to reduce the stability of the baroclinic part.
• Calculate a Courant number for the grid based on a baroclinic velocity of 7 m/s and set the time step so this Courant number has a maximum value of is 1. The baroclinic velocity will depend on the situation, obviously, but 7 m/s has worked pretty well for me.

If you're getting crashes, find out where they occur. If they're near the boundary pay attention to grid smoothness in this area and to the numerical formulation of the boundary conditions. Otherwise the first thing to try is reduce the long time step.

[leonhardherrmann]

Hi,

maybe a rather uneducated question...

how does the model actually "blow up"?

is there some code that checks for realistic numbers or for practical computing issues?

i had an irritating issue with blow ups (in roms_agrif to be accurate) while trying to add a river to my domain. reduced timesteps and increased ramp-up time only delayed the problem proportionally.

after managing to make every possible and impossible error setting up a river inflow i finally managed to get a smooth and well-enough behaved inflow just to end up with blow ups after a few hundreds of timesteps.
This wouldnt have worried me that much but i previously had "salinity rivers" running with negative and highly positive salinitys that ran better...


on another note:
could getting different behavior after a restart have something to do with ramp-up options?
i remember a tidal cycle that i restarted at a much higher temporal resolution that for the first few tidal cycles looked very interesting indeed...

[leon]

I want to known that whether the CFL condition for ROMS is dt<sqrt(((min(min(dx))^2)+(min(min(dy))^2)) / (9.8 * (min(min(h))^2))) or not.
leon

[jcwarner]

look in ROMS/Nonlinear/metrics.F