NaN occur in fisrt step
-
- Posts: 4
- Joined: Tue Oct 19, 2021 4:10 am
- Location: XiaMen University
NaN occur in fisrt step
When I run a data case processed by pyroms, a blow-up occurs during the run, please help me to explain what is going on. The running log is in the debug.log file
0 5748-07-01 00:00:00.00 1.557526E-02 2.163253E+04 2.163255E+04 2.055492E+17
(19,28,15) 8.023335E-07 3.045863E-05 0.000000E+00 7.731726E+00
DEF_RST_NF90 - creating restart file, Grid 01: roms_rst.nc
1 5748-07-01 00:00:01.00 NaN NaN NaN NaN
(00,00,00) 0.000000E+00 0.000000E+00 0.000000E+00 -1.000000E+20
Found Error: 01 Line: 314 Source: ROMS/Nonlinear/main3d.F
Found Error: 01 Line: 298 Source: ROMS/Drivers/nl_roms.h, ROMS_run
Blowing-up: Saving latest model state into RESTART file
REASON: KEchar = NaN, PEchar = NaN
0 5748-07-01 00:00:00.00 1.557526E-02 2.163253E+04 2.163255E+04 2.055492E+17
(19,28,15) 8.023335E-07 3.045863E-05 0.000000E+00 7.731726E+00
DEF_RST_NF90 - creating restart file, Grid 01: roms_rst.nc
1 5748-07-01 00:00:01.00 NaN NaN NaN NaN
(00,00,00) 0.000000E+00 0.000000E+00 0.000000E+00 -1.000000E+20
Found Error: 01 Line: 314 Source: ROMS/Nonlinear/main3d.F
Found Error: 01 Line: 298 Source: ROMS/Drivers/nl_roms.h, ROMS_run
Blowing-up: Saving latest model state into RESTART file
REASON: KEchar = NaN, PEchar = NaN
- Attachments
-
- debug.log
- (64 KiB) Downloaded 468 times
-
- Posts: 30
- Joined: Fri Dec 15, 2017 6:07 pm
Re: NaN occur in fisrt step
Checking your log file it has been found that there exist NaN values in your U wind and V wind component (1.0000E+35) and also in many other variables of your forcing file. So you have to mask those bad values before running the model by setting the NaN flag in your forcing file. The forcing file is the primary reason.
-
- Posts: 20
- Joined: Wed Jun 04, 2014 1:45 pm
- Location: Istanbul Technical University
Re: NaN occur in fisrt step
Hi,
According to your log, your atmospheric conditions have a problem. You can see that there are a lot of 10^35 values and your time of atmospheric values also doesn't look right.
You might have to check the forcing files all together.
According to your log, your atmospheric conditions have a problem. You can see that there are a lot of 10^35 values and your time of atmospheric values also doesn't look right.
You might have to check the forcing files all together.
Code: Select all
GET_2DFLD_NF90 - surface u-wind component, 5748-07-01 00:00:00.00
(Grid=01, Rec=1, Index=1, File: Uwind.nc)
(Tmin= 1405635.0000 Tmax= 1405965.0000) t = 1405635.0000
(Min = 1.00000000E+35 Max = -1.00000000E+35) regrid = T
GET_2DFLD_NF90 - surface v-wind component, 5748-07-01 00:00:00.00
(Grid=01, Rec=1, Index=1, File: Vwind.nc)
(Tmin= 1405635.0000 Tmax= 1405965.0000) t = 1405635.0000
(Min = 1.00000000E+35 Max = -1.00000000E+35) regrid = T
GET_2DFLD_NF90 - surface air pressure, 5748-07-01 00:00:00.00
(Grid=01, Rec=1, Index=1, File: Pair.nc)
(Tmin= 1405635.0000 Tmax= 1405965.0000) t = 1405635.0000
(Min = 1.00000000E+35 Max = -1.00000000E+35) regrid = T
-
- Posts: 4
- Joined: Tue Oct 19, 2021 4:10 am
- Location: XiaMen University
Re: NaN occur in fisrt step
Thanks! I'm sorry it took so long to answer, but this week I tried many things to try to find the problem of forced documents, but I found nothing. Here is my compulsion file, please help me see where the problem is?MIDHILAVARNAV wrote: ↑Thu Sep 22, 2022 8:32 am Checking your log file it has been found that there exist NaN values in your U wind and V wind component (1.0000E+35) and also in many other variables of your forcing file. So you have to mask those bad values before running the model by setting the NaN flag in your forcing file. The forcing file is the primary reason.
- Attachments
-
- MERRA_Pair_3hours_2020_01.nc
- (8.72 MiB) Downloaded 439 times
-
- Posts: 4
- Joined: Tue Oct 19, 2021 4:10 am
- Location: XiaMen University
Re: NaN occur in fisrt step
Thanks! But I think my time is no problem, it can be modify anyway. And I'm sorry it took so long to answer, but this week I tried many things to try to find the problem of forced documents, but I found nothing. Here is my compulsion file, please help me see where the problem is?bilge.tutak wrote: ↑Thu Sep 22, 2022 8:35 am Hi,
According to your log, your atmospheric conditions have a problem. You can see that there are a lot of 10^35 values and your time of atmospheric values also doesn't look right.
You might have to check the forcing files all together.
Code: Select all
GET_2DFLD_NF90 - surface u-wind component, 5748-07-01 00:00:00.00 (Grid=01, Rec=1, Index=1, File: Uwind.nc) (Tmin= 1405635.0000 Tmax= 1405965.0000) t = 1405635.0000 (Min = 1.00000000E+35 Max = -1.00000000E+35) regrid = T GET_2DFLD_NF90 - surface v-wind component, 5748-07-01 00:00:00.00 (Grid=01, Rec=1, Index=1, File: Vwind.nc) (Tmin= 1405635.0000 Tmax= 1405965.0000) t = 1405635.0000 (Min = 1.00000000E+35 Max = -1.00000000E+35) regrid = T GET_2DFLD_NF90 - surface air pressure, 5748-07-01 00:00:00.00 (Grid=01, Rec=1, Index=1, File: Pair.nc) (Tmin= 1405635.0000 Tmax= 1405965.0000) t = 1405635.0000 (Min = 1.00000000E+35 Max = -1.00000000E+35) regrid = T
- Attachments
-
- MERRA_Pair_3hours_2020_01.nc
- (8.72 MiB) Downloaded 422 times
Re: NaN occur in fisrt step
Hi Guojin,
I've check your log and nc file, I noticed that:
but in the nc file, your time is initilized with 2020.1.1, this is the time error, which makes your time stamp and interpolation in ROMS incorrect , so if you want your model run with 20200101, plz set the dstart = 43829.
I've check your log and nc file, I noticed that:
Code: Select all
0.000 dstart Time-stamp assigned to model initialization (days).
19000101.00 time_ref Reference time for units attribute (yyyymmdd.dd)
Re: NaN occur in fisrt step
Your air pressure data are in Pascals ranging from 98,040 to 102,590. By default, ROMS expects Pair in millibars unless you have modified varinfo.dat to do the conversion via a scale factor of 0.01. It is likely you have crazy air pressures in your run.
Quickly plotting your Pair data I find that every time record has the same values. The data never change. And from record 233 to the end all the data are NaN. So, something messed up in the process of generating those forcing files.
I notice in your CPP you have both MIX_S_TS and MIX_GEO_TS. Don't combine these. Just use MIX_GEO_TS
Quickly plotting your Pair data I find that every time record has the same values. The data never change. And from record 233 to the end all the data are NaN. So, something messed up in the process of generating those forcing files.
I notice in your CPP you have both MIX_S_TS and MIX_GEO_TS. Don't combine these. Just use MIX_GEO_TS
John Wilkin: DMCS Rutgers University
71 Dudley Rd, New Brunswick, NJ 08901-8521, USA. ph: 609-630-0559 jwilkin@rutgers.edu
71 Dudley Rd, New Brunswick, NJ 08901-8521, USA. ph: 609-630-0559 jwilkin@rutgers.edu
Re: NaN occur in fisrt step
I believe there are many possible causes for this issue, such as ‘NaN’ in the forcing files or timestamp problems, as noted by fellow contributors earlier in this thread. In fact, I myself recently encountered a same problem. Fortunately or unfortunately, my model did not blow-up, possibly because I only replaced one of the forcing files. However, the simulation results were extremely bad, and at that time I did not realize the importance of checking the information of the output info. When I replaced all the forcing files, I encountered the same error as the original poster - the model produced NaN from the very first step showed in out.log:
I checked for NaN, plotted the spatial field of the forcing files, and inspected the timestamps but found no issues. It was only when I was about to recreate the forcing files that I noticed a comment in 'forcing/d_ecmwf2roms.m' that said:
Emm, I had forgotten to fliplr the latitude direction ( latitude and varible field), which turned out to be a fatal mistake for my this simulation.
MENSION: (LonMin,LatMin) at southwest coner, so LatMin need to be arranged from min to max. match the grid position of variable field and lon lat.
Code: Select all
(Min = 1.00000000E+35 Max = -1.00000000E+35)
Code: Select all
% We want the longitude in the range from -180 to 180 instead of 0 to 360.
% Notice that the latitude is flip so the origin is at southwest corner
% of the extracted grid (LonMin,LatMin)
if (FlipLat),
ROMS_lat = flipud(lat);
else
ROMS_lat = lat;
end
MENSION: (LonMin,LatMin) at southwest coner, so LatMin need to be arranged from min to max. match the grid position of variable field and lon lat.