Atmosphere forcing & coordinate convertion

Discussion of how to use ROMS on different regional and basin scale applications.

Moderators: arango, robertson

Post Reply
Message
Author
bibi951
Posts: 45
Joined: Tue Mar 17, 2009 4:06 pm
Location: cpeo,ocean university of china

Atmosphere forcing & coordinate convertion

#1 Unread post by bibi951 »

Hi everyone
I am preparing ROMS Atmosphere foring. And I quite confused about this:
1)Suppose I have interpolate data to the computing grid coordinate(xi,eta),and I have done the rotaion. But how about the scale factor during the coordinate transformation, I just see the rotation, lengh scale doesn't change ? DO I need to undef the CPP option CURVILINEAR to tell Roms what I have done during forcing preparation? If yes, how about the coordinate tranformation terms in the eq( xi ,eta)?
2) I don't do interpolation myself.I want to give the data and associated lon-lat, and let Roms do the work, so I need to give the data lon-lat information, what should lon-lat information look like in a CDL file?
Would someone please help me . Thanks

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

Re: Atmosphere forcing & coordinate convertion

#2 Unread post by kate »

I can answer question 2:

Code: Select all

netcdf uwind_4 {
dimensions:
        wind_time = UNLIMITED ; // (17540 currently)
        lat = 94 ;
        lon = 192 ;
variables:
        float Uwind(wind_time, lat, lon) ;
                Uwind:missing_value = -1.e+34f ;
                Uwind:_FillValue = -1.e+34f ;
                Uwind:long_name = "10m Uwind component" ;
                Uwind:units = "m/s" ;
                Uwind:coordinates = "lon lat" ;
        double lat(lat) ;
                lat:units = "degrees_north" ;
                lat:point_spacing = "uneven" ;
                lat:axis = "Y" ;
        double lon(lon) ;
                lon:units = "degrees_east" ;
                lon:modulo = 360. ;
                lon:point_spacing = "even" ;
                lon:axis = "X" ;
        double wind_time(wind_time) ;
                wind_time:units = "days since 1900-01-01 00:00:00" ;
                wind_time:axis = "T" ;
                wind_time:bounds = "TIME_bnds" ;
                wind_time:time_origin = "1-JAN-1958" ;
                wind_time:calendar = "LEAP" ;

// global attributes:
Actually, that time_origin is scary, but ROMS seems to be ignoring it.

bibi951
Posts: 45
Joined: Tue Mar 17, 2009 4:06 pm
Location: cpeo,ocean university of china

Re: Atmosphere forcing & coordinate convertion

#3 Unread post by bibi951 »

Hi,Kate
Thank you for your help.It is really kind of you.
I use it and I guess Roms does this work,and I don't have to worry about the Missing_Value problem?
The second question is about setting the initial condition.I think ROMS will take it as in the xi_eta_s coordinates.(ROMS will not do this work for me again, right?) So I have to do the 3D interpolation and rotation myself.I know that you take advantage of manu_toolbox.But it is really difficult for a new user.I notice that rnt_fill* will solve the filling_vallue problem,and rnt_oa* will do the interpolation(both using *mex.dll), I think they are the core codes for data preparation am I right? Is this what you exactly use? And what will Roms do if I have Fillvalue(1e37)?
Would you give me some guide to use this wonderful toolbox, just a clue would be appreciated?
Any advice would be appreciated!
Best regards!

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

Re: Atmosphere forcing & coordinate convertion

#4 Unread post by kate »

bibi951 wrote:I use it and I guess Roms does this work,and I don't have to worry about the Missing_Value problem?
Do you have Missing_Values in your forcing fields? Mine are global.
The second question is about setting the initial condition.I think ROMS will take it as in the xi_eta_s coordinates.(ROMS will not do this work for me again, right?) So I have to do the 3D interpolation and rotation myself.I know that you take advantage of manu_toolbox.But it is really difficult for a new user.I notice that rnt_fill* will solve the filling_vallue problem,and rnt_oa* will do the interpolation(both using *mex.dll), I think they are the core codes for data preparation am I right? Is this what you exactly use? And what will Roms do if I have Fillvalue(1e37)?
Would you give me some guide to use this wonderful toolbox, just a clue would be appreciated?
Any advice would be appreciated!
Best regards!
We do use Manu's toolbox to create initial and boundary conditions. I have run those scripts, but not written them. Matlab has never been my favorite tool and I left Rutgers to avoid it (well, partly 8) ). So my advice is to find someone who has used the same format of source file for your initial conditions and to bug them.

Manu has promised an updated toolbox but has been distracted by things like applying for tenure and having a second child. We are also hoping to come up with this functionality in Python.

bibi951
Posts: 45
Joined: Tue Mar 17, 2009 4:06 pm
Location: cpeo,ocean university of china

Re: Atmosphere forcing & coordinate convertion

#5 Unread post by bibi951 »

Hi,everyone
I took data from Ncep (2.5*2.5) and oaflux(1*1),And I wrote cdl file as Kate adviced.However I encounter this error
NLM: GET_STATE - Read state initial conditions, t = 0 00:00:00
(File: initial_lJ.nc, Rec=0001, Index=1)
..........................
GET_2DFLD - surface u-wind component, t = 0 00:00:00
(Rec=0001, Index=1, File: frc_1.nc)
(Tmin= 0.0000 Tmax= 729.0000)
(Min = 1.00000000E+35 Max = -1.00000000E+35)
GET_2DFLD - surface v-wind component, t = 0 00:00:00
(Rec=0001, Index=1, File: frc_1.nc)
(Tmin= 0.0000 Tmax= 729.0000)
(Min = 1.00000000E+35 Max = -1.00000000E+35)
GET_2DFLD - solar shortwave radiation flux, t = 0 00:00:00
(Rec=0001, Index=1, File: frc_1.nc)
(Tmin= 0.0000 Tmax= 729.0000)
(Min = 1.00000000E+35 Max = -1.00000000E+35)
GET_2DFLD - net longwave radiation flux, t = 0 00:00:00
(Rec=0001, Index=1, File: frc_1.nc)
(Tmin= 0.0000 Tmax= 729.0000)
(Min = 1.00000000E+35 Max = -1.00000000E+35)
GET_2DFLD - surface air pressure, t = 0 00:00:00
(Rec=0001, Index=1, File: frc_1.nc)
(Tmin= 0.0000 Tmax= 729.0000)
(Min = 1.00000000E+35 Max = -1.00000000E+35)
GET_2DFLD - surface air temperature, t = 0 00:00:00
(Rec=0001, Index=1, File: frc_2.nc)
(Tmin= 0.0000 Tmax= 729.0000)
(Min = -5.33855130E+00 Max = 2.86994297E+01)
GET_2DFLD - surface air specific humidity, t = 0 00:00:00
(Rec=0001, Index=1, File: frc_2.nc)
(Tmin= 0.0000 Tmax= 729.0000)
(Min = 0.00000000E+00 Max = 2.06493227E+01)
GET_2DFLD - rain fall rate, t = 0 00:00:00
(Rec=0001, Index=1, File: frc_1.nc)
(Tmin= 0.0000 Tmax= 729.0000)
(Min = 1.00000000E+35 Max = -1.00000000E+35)

I have checked my netcdf file , they all have reasonable values? But why I get this here? (Min = 1.00000000E+35 Max = -1.00000000E+35)
See something wrong?
Besides,I use mpirun,how to set to idb?

I would very aprrecitate your suggestions.
Thanks .

User avatar
wilkin
Posts: 922
Joined: Mon Apr 28, 2003 5:44 pm
Location: Rutgers University
Contact:

Re: Atmosphere forcing & coordinate convertion

#6 Unread post by wilkin »

I have checked my netcdf file , they all have reasonable values? But why I get this here? (Min = 1.00000000E+35 Max = -1.00000000E+35)
See something wrong?
This is odd. At first glance I would have thought this indicated that you have some "missing" values (maybe over land?) in your netcdf file and on input to ROMS they have been assigned the value 1+35 because this is the netcdf file "_FillValue" or "missing_value" attribute.

However, notice that the MIN is 1+35 while the MAX is -1+35, i.e. MIN is > MAX. This suggests ROMS has not read any data to reset the default min/max values it starts with in the range check. I don't know whether this means all the data are missing values or that there is something else amiss.

It is likely that whatever tool you used to check your netcdf file automatically makes conversion from the fillvalue to a NaN and hence you think the values are all reasonable but they are not. You can usually disable this so you can see precisely the values stored.

You might want to check more carefully that your forcing files are indeed OK. For some variables you get sensible ranges, but for others you do not, so you have some inconsistency in what you're doing. Beware of scale_factor and add_offset attributes, and type inconsistencies (int,float,double) in the netcdf file.
John Wilkin: DMCS Rutgers University
71 Dudley Rd, New Brunswick, NJ 08901-8521, USA. ph: 609-630-0559 jwilkin@rutgers.edu

bibi951
Posts: 45
Joined: Tue Mar 17, 2009 4:06 pm
Location: cpeo,ocean university of china

Re: Atmosphere forcing & coordinate convertion

#7 Unread post by bibi951 »

Thank you for your kind reply, wilkin.
I checked my netcdf,finally I found that my latitude orientation is wrong.
Now Roms reads the right data.
Thanks

subbareddy
Posts: 6
Joined: Mon May 11, 2009 3:52 pm
Location: IIT Kharagpur

Re: Atmosphere forcing & coordinate convertion

#8 Unread post by subbareddy »

hi sir,
can you tell, how to prepare initial condition and forcing file for the roms.
can you explain elobaratively ?
please help me
thank you

stone

Re: Atmosphere forcing & coordinate convertion

#9 Unread post by stone »

Hi, all
I wonder whether I can just provide the atm forcing in a small domain(not global and not my grid), which just covers my grid domain, using this "lon:modulo = 360. ;" property just like a global forcing?
I did so (feeding with qnet,uvstess,eminusp), and ran ROMS, but find that the surface tempreture goes crazy warming. I use OAflux to provide qnet and checked the data,it looks good (like the origional data)
I doubt i have misused the "lon:modulo = 360. ;" property ,have I?
Thanks

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

Re: Atmosphere forcing & coordinate convertion

#10 Unread post by kate »

The lon:modulo = 360 is for global domains. What happens if you don't use the modulo attribute? You can take it away with NCO.

stone

Re: Atmosphere forcing & coordinate convertion

#11 Unread post by stone »

Thanks for your advice, Kate
I remove the "modulo",tempreture is the same as it was.
I output the "shflux" (-150 ~ 150 W*m-2) and "ssflux"(-6e-6 ~ 2e-6) or swflux is -3 ~ 1 cm/day. It seems OK.
Then, I increase the horizontal(TNU2 1e2) and vertical background(AKT_BAK 1e-5) trace diffusion,not much change of the result.
Maybe this is now not in this topic ,Sorry for that.

tasha
Posts: 15
Joined: Wed Nov 18, 2009 7:27 pm
Location: New York University

Re: Atmosphere forcing & coordinate convertion

#12 Unread post by tasha »

(Min = 1.00000000E+35 Max = -1.00000000E+35)
I had the same problem with one of my netcdf forcing files from NCEP and (thanks to your post) I similarly fixed it by flipping my latitude values - and my data to match.

tony1230
Posts: 87
Joined: Wed Mar 31, 2010 3:29 pm
Location: SKLEC,ECNU,Shanghai,China

Re: Atmosphere forcing & coordinate convertion

#13 Unread post by tony1230 »

hi kate
It's the first time i have seen 'modulo'. i have absolutely no
idea about the 'lon:modulo = 360'.would you explain to me what's
the equation mean or how to operate it!
Best regards!

tony

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

Re: Atmosphere forcing & coordinate convertion

#14 Unread post by kate »

Modulo would be useful for domains that span the globe, though I don't think ROMS now looks for it. For instance, an Arctic grid will have all longitudes from 0 to 360. Say your winds are every two degrees, starting at 1, going to 359. How do you interpolate those points at 359.8? You need to wrap that value from 1 degree over to seem like it's at 361.

Post Reply