Blowing up at the last timestep

General scientific issues regarding ROMS

Moderators: arango, robertson

Post Reply
Message
Author
evridiki
Posts: 19
Joined: Mon Nov 05, 2012 2:39 pm
Location: National and Kapodistrian University of Athens

Blowing up at the last timestep

#1 Unread post by evridiki »

Hello everybody,
I'm trying to set up my own application by using as a template the "Fjord tidal case" (just for checking the grid and initial files that I produced for my area).
So first I made the grid.nc file using the bathymetry of my region whereas for the ini.nc file I used constant values for all the fields. Both files were created with easygrid.m and ROMS ran without problems.
Afterwards, I changed only the ini.nc file using realistic T,S data (produced by POM) but ROMS blew up at the last timestep giving NaN values.
I think that something's wrong with my new ini.nc file, since the first ran test was fine, but I don't know what's the problem or what to check. I'm relatively new in modeling so I appreciate any suggestions. I attached my log file.
Thanks in advance!
Attachments
out.log
(136.79 KiB) Downloaded 296 times

ymamoutos
Posts: 71
Joined: Fri Nov 19, 2010 2:33 pm
Location: University of Aegean

Re: Blowing up at the last timestep

#2 Unread post by ymamoutos »

Greetings,

When I try to open your log file my editor tells me that
there was a problem opening the file... At boundary conditions
section I see weird characters for salt and I don't see any
choice for TKE. I think a good choice for your log file is
to set on your *.in file NINFO == 1 to see at each time steep
what is going on. Check your restart file and try to see in which
sigma layer the blow up happened and if it is close to your open boundary.
Your rx1 value is to small (~1.96). The range for this variable is
3 < rx1 < 7. Try to smooth your bathymetry to bring the B&H stiffness
(rx0) up to ~0.3 - 0.35. I think that all your Courant numbers are relatively
small. I am also running North Aegean with a similar grid resolution and the
values for Curant numbers are:

Code: Select all

Minimum barotropic Courant Number =  3.34898947E-02
Maximum barotropic Courant Number =  6.98977566E-01
Maximum Coriolis   Courant Number =  2.86995742E-02
Giannis

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

Re: Blowing up at the last timestep

#3 Unread post by kate »

I too like to set NINFO to 1. Not only does it print more often, but it checks for strange values more often, writing to the restart file, hopefully before it gets all the way to NaN. Then you can view the restart file (with ncview) to see where the trouble occurs.

You say you created the initial conditions with POM. How did you perform the vertical interpolation from the POM grid out the ROMS grid? (Did you?) Last I checked, POM didn't support the vertical stretching that you are using (not that I've checked since we started using that stretching).

evridiki
Posts: 19
Joined: Mon Nov 05, 2012 2:39 pm
Location: National and Kapodistrian University of Athens

Re: Blowing up at the last timestep

#4 Unread post by evridiki »

Thanks Gianni for your kindly reply,
Yes, the weird characters were my mistake, I'm fixing that now. I haven't realize that the limits for rx0 and rx1 were so strict. I saw somewhere that they are supposed to be rx0<0.3 and rx1<6.
What I can't understand is why ROMS ran the first time since all the values were exactly the same as now, including rx0,rx1 and Courant Number.
The only thing I changed for this case was the initial.nc file and I kept everything else the same in order to check my ini file.
I will definitely try again with your suggestions but should I also try to make my ini.nc file with another way? Maybe with c_initial.m or d_initial.m? Can my values for T,S be the reason for blowing?
(I attached again my previous log file)
Attachments
logfile.doc
(193.5 KiB) Downloaded 269 times

ymamoutos
Posts: 71
Joined: Fri Nov 19, 2010 2:33 pm
Location: University of Aegean

Re: Blowing up at the last timestep

#5 Unread post by ymamoutos »

Evridiki,

if your POM outputs are in netcdf form and in mercator
projection you can use the d_mercator2roms.m script
to create your initial conditions file. Also I have
the same question with Kate about the vertical interpolation.

Giannis

evridiki
Posts: 19
Joined: Mon Nov 05, 2012 2:39 pm
Location: National and Kapodistrian University of Athens

Re: Blowing up at the last timestep

#6 Unread post by evridiki »

Dear Kate,
Yes you are right I didn't do any interpolation. :roll: :roll: I'm new in ROMS and modeling and there a lot of things I don't understand yet completely. I read several posts about how to make the ini.nc but obviously I'm missing something.
If I take the data -say from MEDATLAS or POM in a netcdf or other format how can I create the appropriate file for ROMS?

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

Re: Blowing up at the last timestep

#7 Unread post by kate »

For the bathymetry steepness, you are fine. Your values are nicely small, much smaller than I usually have. That's good.

Most people interpolate using Matlab. I don't know those tools at all. I use Python, for which we have some interpolation scripts, but not one for POM files. Does anyone else have POM interpolation scripts?

evridiki
Posts: 19
Joined: Mon Nov 05, 2012 2:39 pm
Location: National and Kapodistrian University of Athens

Re: Blowing up at the last timestep

#8 Unread post by evridiki »

Dear Gianni and Kate,
The outputs from POM are not in a netcdf format but maybe I can fix that.
So in order to use them first I have to do some kind of interpolation, then making them netcdf and finally pass the .nc file that I will have created to d_mercator2roms.m script to get my ini.nc file for ROMS?????
And if I can't fix them in the right format is there another way?
Sorry for westing your time and thanks a lot for your answers!

Post Reply