NaN after 10 days' run

[feroda]

3595 9 23:40:00 1.218936E-03 2.133789E+04 2.133789E+04 1.142055E+16
3596 9 23:44:00 1.219205E-03 2.133789E+04 2.133789E+04 1.142055E+16
3597 9 23:48:00 1.219472E-03 2.133789E+04 2.133789E+04 1.142055E+16
3598 9 23:52:00 1.219738E-03 2.133789E+04 2.133789E+04 1.142055E+16
3599 9 23:56:00 1.220007E-03 2.133789E+04 2.133789E+04 1.142055E+16
3600 10 00:00:00 1.220278E-03 2.133789E+04 2.133789E+04 1.142055E+16
WRT_HIS - wrote history fields (Index=1,1) into time record = 0000011
WRT_RST - wrote re-start fields (Index=1,1) into time record = 0000001
3601 10 00:04:00 NaN NaN NaN NaN

Blowing-up: Saving latest model state into RESTART file

That is from the output log. What's the possible reason for the value of NaN in this condition?

Thanks very much!

[kate]

Have you tried a shorter timestep?

Do you have the latest ROMS version which dies before getting all the way to NaN? Sometimes it is interesting to plot the fields in the restart file if ROMS detects large velocities and does a save/crash. It also checks for large densities.

[feroda]

Thanks very much, Kate
I haven't try a shorter time step.
The time step is well going for my last case.

The difference between the "well going" one and "with NaN" one are
1. I added surface wind forcing to the "with NaN". (namely, "well going" without wind forcing)

2. CPP options for horizontal mixing of momentum and tracers are change from MIX_S_UV and MIX_S_TS to
MIX_GEO_UV and MIX_GEO_TS,respectively.
(The reason for this change is
the bathymetry is pretty complicated in my model. So, the vertical coordinate has a large slope
between the shelf and basin.
I think MIX_GEO_* will be more reasonable. Is it true?)

Based on the above setup, I think the time step is not the reason for NaN. I will try your advice later and report will be come soon.


The ROMS version I am using is quite a new one
svn: $Id: Version 340 2009-03-26 01:57:53Z arango $

Moreover, I checked the velocity from ocean_rst.nc, the maximum value is less than 1.4 m/s, which seems not the right point of the issue.

Thanks for any kind suggestion.

[kate]

I strongly suggest you try a shorter timestep. If it doesn't make any difference to the time of the blowup, then you can discount it. Adding winds will add energy to the system and could well shorten the allowable timestep. Also, I have had ROMS run fine for an extended period of time (years!), then suddenly blow up with the energy diagnostics going from fine to bad in one timestep. We have gotten through these things by temporarily using a shorter timestep.

[feroda]

Thank you very much!
The test according to your kind suggestion is going on.

BTW, in case of strong vertical coordinate slope, MIX_GEO_* or MIX_S_* is more reasonable?
From my test, MIX_S_* seems much better, though I don't quite understand the reason for that.
Any idea on that?

Thanks

[kate]

Better how? The MIX_S_ will be cheaper and I usually use it for viscosity (UV). However, it will mix tracers across isopycnals in an unphysical way so I don't use it for tracers. In a model run with biology, the horizontal diffusion term can be the single largest use of computer time due to all the rotated mixing operations on all the tracers.