Ocean Modeling Discussion

ROMS/TOMS

Search for:
It is currently Sun Nov 18, 2018 4:48 pm




Post new topic Reply to topic  [ 15 posts ] 

All times are UTC

Author Message
PostPosted: Wed Jun 20, 2018 3:51 pm 
Offline

Joined: Thu Mar 08, 2018 2:47 am
Posts: 30
Location: German Research Centre for Geosciences
Hello everyone,

while trying to run ROMS in parallel mode with analytical initial conditions I receive the following error output from debugging mode (excerpt from the whole error file):
Code:
forrtl: severe (151): allocatable array is already allocated
Image              PC                Routine            Line        Source
oceanG             000000000220D767  Unknown               Unknown  Unknown
oceanG             000000000217A2AB  mod_param_mp_init         626  mod_param.f90
oceanG             0000000000508C55  read_phypar_              215  read_phypar.f90
oceanG             00000000004675EE  inp_par_                   93  inp_par.f90
oceanG             0000000000420113  ocean_control_mod          86  ocean_control.f90
oceanG             000000000041FBCA  MAIN__                     95  master.f90
oceanG             000000000041F9DE  Unknown               Unknown  Unknown
libc-2.12.so       00002AC42B4BCD1D  __libc_start_main     Unknown  Unknown
oceanG             000000000041F8E9  Unknown               Unknown  Unknown


I investigated the respective lines in the source files and found out that the issue is about the IOBOUNDS type which sets the variables for the netcdf grid file. In the mod_param the variable is initialized and then passed on to the other routines in the following files. So the problmes seems to be in mod_param. However, this routine only uses mod_kinds and I can't find any other resources that could cause the error. In mod_param the IOBOUNDS is correctly defined and later allocated in the subroutine initialize_param.
I can't seem to find the reason for the error...


Top
 Profile  
Reply with quote  
PostPosted: Fri Aug 17, 2018 3:03 pm 
Offline

Joined: Thu Mar 08, 2018 2:47 am
Posts: 30
Location: German Research Centre for Geosciences
After setting up my model once again, I re-encounter this problem. :roll:
No suggestions on how to solve this?


Top
 Profile  
Reply with quote  
PostPosted: Fri Aug 17, 2018 4:29 pm 
Offline
User avatar

Joined: Wed Jul 02, 2003 5:29 pm
Posts: 3516
Location: IMS/UAF, USA
initialize_param is called after NtileJ is read in the input file. You don't happen to have more than one line with NtileJ set do you?


Top
 Profile  
Reply with quote  
PostPosted: Sat Aug 18, 2018 7:41 am 
Offline

Joined: Thu Mar 08, 2018 2:47 am
Posts: 30
Location: German Research Centre for Geosciences
Thanks for your reply, Kate.
No, there is no double entry for NtileJ.
What I did now is to wrap the allocation of IO_BOUNDS inside an IF-condition, too. I guess, this is a nasty workaround and there sure is an issue in my model setup somewhere but it solved the problem for now. Let's see how the simulation performs...


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 22, 2018 9:33 am 
Offline

Joined: Thu Mar 08, 2018 2:47 am
Posts: 30
Location: German Research Centre for Geosciences
Considering the recent repository update underlines even more that the IF-condition wrap is a workaround but shouldn't be necessary. In fact, I did not encounter the problem when using another ocean.in. I tried hard to figure which setting causes the obsolete allocation but was not successful. Which settings could be responsible? Is is related to the Lcycle switch? Or Nrrec?
Thanks for any hints! :wink:


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 22, 2018 12:06 pm 
Offline

Joined: Wed Dec 31, 2003 6:16 pm
Posts: 722
Location: USGS, USA
can you post your ocean.in that causes the trouble?
is there a way I can download it. dont just copy it to this widget.
-j


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 22, 2018 2:07 pm 
Offline
Site Admin
User avatar

Joined: Wed Feb 26, 2003 4:41 pm
Posts: 1047
Location: IMCS, Rutgers University
It is a weird error if you didn't repeat the NtileJ parameter in ocean.in, which triggers the allocation of several modules. In yesterday update, I put safeguards for this to never happen. I don't know what to make of your case. I don't think that a corrupted ocean.in should trigger to process the same assignment twice. Sometimes unseen characters are incorporated when editing a file. Did you edit the file in a non-UNIX computer? What kind of text editor do you use?


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 22, 2018 2:09 pm 
Offline

Joined: Wed Dec 31, 2003 6:16 pm
Posts: 722
Location: USGS, USA
yeah that is what i was going to look for. TABS = bad.
sometimes an errant character can get stuck in the file and cause an issue.


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 22, 2018 3:38 pm 
Offline

Joined: Thu Mar 08, 2018 2:47 am
Posts: 30
Location: German Research Centre for Geosciences
Oh yes, tabs! I encountered them already in the .in file. :D I use Vi on a UNIX. And .e.g tabs before the forcing file links are a bad idea! :twisted:
However, so far I couldn't find them to be the reason of double-allocation. At the moment I am still busy setting up the forcing fields to the desired structure (still receiving get_fld errors but they are solvable) so I can't look into how the model setup actually performs. When I am there, I will probably know if something is odd when running with the IF-wrapper as as workaround and maybe even what caused it. I'll report! :idea:


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 26, 2018 10:09 am 
Offline

Joined: Thu Mar 08, 2018 2:47 am
Posts: 30
Location: German Research Centre for Geosciences
Hey all,
after your hints about double-entries in the .in file I finally looked really really close once again and, alas, I found an entire block of entries at the very end of my file (after the Glossary and coupling section). My guess how it ended up there: an accidental mousewheel click while scrolling (Linux). This probably pasted in the block I must have copied before. The double-allocation error is solved. :)

However, I am struggling with another problem since quite some time now. It's this error from the regrid routine:
Code:
 REGRID - input gridded data does not contain model grid:

          Gridded:  LonMin = -179.2500 LonMax =  180.0000
                    LatMin =  -90.0000 LatMax =   90.0000
          Model:    LonMin = -179.9848 LonMax =  179.9680
                    LatMin =   45.0081 LatMax =   89.9205
 Found Error: 04   Line: 254      Source: ROMS/Utility/get_2dfld.F

 GET_2DFLD   - error while reading variable: sustr   at TIME index =       1
 Found Error: 04   Line: 139      Source: ROMS/Nonlinear/get_data.F
 Found Error: 04   Line: 772      Source: ROMS/Nonlinear/initial.F
 Found Error: 04   Line: 188      Source: ROMS/Drivers/nl_ocean.h

This problem was discussed frequently here in the forum. Still, no solution worked for me so far. Some facts about my files:
I am using the respective Matlab package to generate forcing files, so they come with the "spherical" integer variable and it is set to the value=1. The grid file I am using, however, is not created by me but comes from a set up I am partially recycling for my project. Checking the spherical variable gives this for the grid file:
Code:
    char spherical ;
      spherical:long_name = "Grid type logical switch" ;
      spherical:option_F = "Cartesian" ;
      spherical:option_T = "spherical" ;

  data:
    spherical = "T" ;

Also, in the header there is a grid mapping variable:
Code:
   int grid_mapping ;
      grid_mapping:long_name = "grid mapping" ;
      grid_mapping:grid_mapping_name = "polar_stereographic" ;
      grid_mapping:ellipsoid = "sphere" ;
      grid_mapping:earth_radius = 6371000. ;
      grid_mapping:latitude_of_projection_origin = 90. ;
      grid_mapping:straight_vertical_longitude_from_pole = 58. ;
      grid_mapping:standard_parallel = 60. ;
      grid_mapping:false_easting = 4180000. ;
      grid_mapping:false_northing = 2570000. ;
      grid_mapping:dx = "20000" ;
      grid_mapping:proj4 = "+proj=stere +R=6371000.0 +lat_0=90 +lat_ts=60.0 +x_0=4180000.0 +y_0=2570000.0 +lon_0=58.0" ;

I have the suspicion that my grid file and forcing files are not compatible and that is why the spherical attribute is not recognized by ROMS. I tried to manipulate the matlab script in order to make the spherical variable a char of values T and F and set it to T but this did not solve the problem. Trying to set the grid file to spherical=1 didn't help either (adding the attribute flag_meanings and flag_values neither). Finally, I even attempted to directly set the value of "spherical" in the mod_scalar to true but no positive result again.
I have full understanding that ROMS cannot accept the forcing files not completely overlapping the model domain. Still, I don't know how to help it. I am very grateful for any hints! :idea:


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 26, 2018 3:44 pm 
Offline
Site Admin
User avatar

Joined: Wed Feb 26, 2003 4:41 pm
Posts: 1047
Location: IMCS, Rutgers University
Okay, that will do it. I put safeguards to the code when processing standard input file ocean.in. I made a couple of updates recently for it.

It looks that your grid is not for a regional application, but it is a global grid. Is that correct?

If that's the case, you have a problem with the design of your grid or understanding. In a regional grid, we usually use a longitude range between -180 to 180 where negative values are west longitudes, and positive values are east longitudes (degree_east units attribute). In a global grid, we usually use a longitude range between 0 to 360 degrees or any modulus of 360, mod(x,360). In cases like this, it is wiser to add 360 to the values in the range -180:180. The error is in routine regrid because it is not smart enough to figure out if you have enough data to interpolate to your grid. It is made on purpose to make the user aware of global applications when providing external data to ROMS. The regrid option is automatically triggered when you input data if it is not of the same size of ROMS grid variable, so we need to interpolate the data horizontally.

As you can see, your problem is not related to the simple spherical flag.

If it is your first application in ROMS, I suggest that you gain experience with a smaller regional grid, so you can transfer all that knowledge when building and setting up your global application.


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 26, 2018 4:08 pm 
Offline
User avatar

Joined: Wed Jul 02, 2003 5:29 pm
Posts: 3516
Location: IMS/UAF, USA
The user has an Arctic domain. I added a GLOBAL_PERIODIC flag to ROMS to handle just this case, interpolating across the dateline. I've attached the patch file.


Attachments:
File comment: Patch file - apply with "patch -p1 < peri_diff.txt"
peri_diff.txt [9.06 KiB]
Downloaded 15 times
Top
 Profile  
Reply with quote  
PostPosted: Tue Aug 28, 2018 4:37 pm 
Offline

Joined: Thu Mar 08, 2018 2:47 am
Posts: 30
Location: German Research Centre for Geosciences
Dear Kate,

million thanks for the patch! I needed to adjust my Matlab processing a bit so that my lon/lat variables are 1d. In the Matlab package one needs to change the metadata (in roms_metadata.m) to just one variable dimension entry and in the main program comment out the repmat procedure. Otherwise the get_varcoord-routine slips into the else-condition of n_dims.eq.1 which causes an error in netcdf_get_fvar.
I also liked your added NUL-termination safeguard for the coordinates attribute value. :)


Top
 Profile  
Reply with quote  
PostPosted: Tue Aug 28, 2018 4:43 pm 
Offline

Joined: Thu Mar 08, 2018 2:47 am
Posts: 30
Location: German Research Centre for Geosciences
Quote:
If it is your first application in ROMS, I suggest that you gain experience with a smaller regional grid, so you can transfer all that knowledge when building and setting up your global application.

Dear Hernan,
your are right, I am a bloody beginner. :oops:
But thanks to the comprehensive documentation and last but not least this forum, I already went a long way from scratch. 8) I am still enjoying ROMS very much! :D


Top
 Profile  
Reply with quote  
PostPosted: Thu Sep 13, 2018 8:19 pm 
Offline

Joined: Thu Mar 08, 2018 2:47 am
Posts: 30
Location: German Research Centre for Geosciences
I realized lately that global_periodic gives a seam at lon 180/-180 if the coordinates are not in the order of -180 to 180 instead of 0 to -0 (which would be the outcome of the d_ecmwf2roms.m). Therefore, I added two lines to the script:
In the section where lat and lon are read, right after the modification of the lon range, I added
Code:
[ROMS_lon,ind_lon] = sort(ROMS_lon);

and further down in the loop where the fields are read and written
Code:
fieldfinal = fieldfinal(ind_lon,:);

This will result in a globally continuous field when using global_periodic. :)


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 15 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group