Model Blow Up After 5137 Time Step Run

[hyy]

Hello, would you please give me any advice to solve my ROMS blow up
trouble as follows?

I am trying to drive the old ROMS (Version: 3.5 (Last Changed
Revision: 561)) to simulate the ocean condition in the Seto Inland
Sea, Japan.

Input forcing parameters as follows;
*) tidal forcing (effect of the fluctuation of SSH only)
*) wind (U,V) forcing
*) surface air temperature
*) surface air humidity
*) sea level pressure
*) cloud fraction
*) solar shortwave radiation
*) precipitation

Attached files:
Execution log file: "seto_2010_001.log"
Input parameter file: "ocean_seto_2010_017.in"
Cpp preprosessor header file:"seto_001.h"

Attached figure file:
SST at the latest model state: "sst_Latest.png"

After driving in 5137 time step run (14 hours 16 minutes 10 second),
the model blow up. Checking all 2d-vars (ubar, vbar, zeta) and all
layers of 3d-vars (temp., sal., u, v, rho) at the latest model state,
obviously missing values are found in diamond shape (e.g., see
"sst_Latest.png" in case of SST).

Using Ncview (http://meteora.ucsd.edu/~pierce/ncview_home_page.html),
these missing values are 9.96921e+36, while the value at land-masked
points are 1e+37.

Would you please give me any advice to fix this 'blow up' trouble?
Thank you very much in advance.

[kate]

Those 1.e36 values are NaN. I'm sure you'd find that the first one happened in the middle of that diamond and they are spreading from there quite rapidly. If you ask ROMS for NINFO=1, it will check for NaN or other weird values every timestep and stop before you have that many NaN values. Still, it is now up to you to find out what caused it - do you have shallow water there? Do you have wetting and drying? Did you try again with a shorter timestep?

Is there some reason you're using such an old code?

[hyy]

Dear Kate,

Thank you very much for your advice! Now I am trying to check the
points that you have suggested. So would you please give me a time
for a while to complete all check? I will send (post) the answers
soon.

Again, thanks so much for your useful advice.

Best regards,

Hiroshi

[hyy]

Dear Kate,

I am sorry to have kept you waiting for the answers. Here are them;

> If you ask ROMS for NINFO=1, it will check for NaN or other weird
> values every timestep and stop before you have that many NaN values.

Yes, I set NINFO=1 in the input file:"ocean_seto_2010_017.in" (see
attached file in the first post).

> do you have shallow water there?

The depth of the middle point of that diamond is 7.40237m, where
belongs to coast line: the neighboring (right side) point is defined
as land (that is, the variable: 'mask_rho' at this point is defined as
zero). Note that a positive thickness: "hc", and "h_min" is both 5m.
The following varialbes defined in the input
file:"ocean_seto_2010_017.in" are:
THETA_S == 5.0d0 THETA_B == 0.0d0 TCLINE == 1.0d1

> Do you have wetting and drying?

No, I don't have wetting and drying, in other words, I don't define
Cpp option: WET_DRY in the Cpp header file: "seto_001.h" (see attached
file in the first post).

> Did you try again with a shorter timestep?

I did with a shorter timestep: from DT == 10.0d0 to DT == 5.0d0. But
the model blew up with NaN (9.96921e+36) at different points from
previous run, where also belongs to coast line: the neighboring point
is defined as land.

> Is there some reason you're using such an old code?

Yes, we succeeded to execute this old codes in a different region
about 7 years before. Then I have decided to apply the same
configuration (e.g., the parameters written in input file, Cpp header
file, etc.) to this present Seto Inland Sea Model, which is thought to
work well. What do you think about my idea described above?

I will appreciate your next reply to me. Thank you in advance.

Best regards,

Hiroshi

[kate]

Dear Kate,

I am sorry to have kept you waiting for the answers.

No rush.

Yes, I set NINFO=1 in the input file:"ocean_seto_2010_017.in" (see
attached file in the first post).

Yes, I know the answer was in this file, but was hoping to get you to be solving your problems.

> do you have shallow water there?

The depth of the middle point of that diamond is 7.40237m,

And what about zeta at that time and place? You need to know total water depth - is it trying to go negative?

Note that a positive thickness: "hc", and "h_min" is both 5m.
The following varialbes defined in the input
file:"ocean_seto_2010_017.in" are:
THETA_S == 5.0d0 THETA_B == 0.0d0 TCLINE == 1.0d1

This is with Vtransform and Vstretching = 1. The new code supports newer stretching options which we generally now prefer.

> Do you have wetting and drying?

No, I don't have wetting and drying, in other words, I don't define
Cpp option: WET_DRY in the Cpp header file: "seto_001.h" (see attached
file in the first post).

The new code might have improved the stability of turning on the WET_DRY cpp option.

> Did you try again with a shorter timestep?

I did with a shorter timestep: from DT == 10.0d0 to DT == 5.0d0. But
the model blew up with NaN (9.96921e+36) at different points from
previous run, where also belongs to coast line: the neighboring point
is defined as land.

Again, how shallow are these points and are they trying to go dry? If not, what else is going on? Do you have river inflows?

> Is there some reason you're using such an old code?

Yes, we succeeded to execute this old codes in a different region
about 7 years before. Then I have decided to apply the same
configuration (e.g., the parameters written in input file, Cpp header
file, etc.) to this present Seto Inland Sea Model, which is thought to
work well. What do you think about my idea described above?

Did your prior domain have such a shallow hmin? Just because I can get away with hmin=5 doesn't mean you can.

[hyy]

Dear Kate,

Thank you very much for answering my questions and I am sorry for my
late reply.

Please let me give a time to do 'try and error' with referring to
your advice for a while.

Again, thanks so much for your advice.

Best regards,

Hiroshi