Three nested refined grids - Ngrids vs. Ncontact

[stef]

Hi,

I was able to do a refinement using 2 grids, using a self-written python script to generate the contact file. It's a 2d application and although I hit a bug with the wet masks using wetting/drying, I was able to patch it and proceed.

However, now I want to use 3 refined nests (i.e. one telescoping grid), but ROMS wants 'coincident', 'composite' etc. fields with dimensions of Ncontact instead of Ngrids (the latter is used in https://www.myroms.org/wiki/Nested_Grids)

Background:

I don't have Matlab and Octave does not work for all scripts (and is a pain to adapt), and I'd like to stick with Python if possible.

I wrote the Python script using the information in https://www.myroms.org/wiki/Nested_Grids (very helpful) and I also read quite a bit of Matlab code, in particular 'contact.m'.

But now using 3 grids, ROMS errors and I found the dimensions in set_contact.F:

Code: Select all

      logical, dimension((Ngrids-1)*2) :: Lcoincident
      logical, dimension((Ngrids-1)*2) :: Lcomposite
      logical, dimension((Ngrids-1)*2) :: Lmosaic
      logical, dimension((Ngrids-1)*2) :: Lrefinement

are (Ngrids-1)*2, in other words Ncontact, and not Ngrids which I have. Using 2 grids the numbers are identical, but not using 3. I found this post describing a similar issue:

https://www.myroms.org/forum/viewtopic ... ct#p18723

and apparently the Matlab scripts have been adapted to account for this.

Is there some updated documentation that accounts for this?

Thanks for your help!

[arango]

The nesting configuration is tricky since we support various types of grid connectivity. We only provide a Matlab interface to generate the nesting connectivity NetCDF file needed by ROMS. Unfortunately, we don't officially have any other software to create such a connectivity NetCDF file nor have the technical documentation in the WikiROMS for others to translate and adapt the Matlab script contact.m to Octave or Python. We provide enough information in WikiROMS about the nesting strategy but not the technical details to generate such connectivity NetCDF file from scratch. If the user doesn't have access or is allergic to Matlab, he/she need to study contact.m and adapt to the desired software interface. This Matlab script is exceptionally well documented and provides technical information for others to write such capability in another language. He/she need to find identical functionality for the inpolygon Matlab algorithm. The inpolygon function is the brain of the nesting connectivity algorithm. I assume that the other native Matlab functions are available or can be reproduced in Octave or Python. Anyway, ROMS expects every variable defined in such a connectivity NetCDF file. Regardless of the type nesting, there it is always (Ngrids-1)*2 contact regions

I think that we, as ROMS developers, have freely provided a very sophisticated modeling framework to the ocean community without asking anything in return. Perhaps, users can contribute such processing capabilities in different languages. I never have the need to use Python for processing, but I know that there are excellent Python-derived tools out there for processing ROMS. Maybe the Phyton Gods may look contact.m and other associated scripts, and provide similar capability. I am very busy as it is for me to learn Phyton and provide alternatives to Matlab.

[stef]

I think that we, as ROMS developers, have freely provided a very sophisticated modeling framework to the ocean community without asking anything in return.

I highly appreciate your effort and that of your team, and the appreciation and admiration grows every day I work with the software you provide! I'm sure this holds for most, if not all users of your code.

Regarding your use of Matlab, I have no problem with it, it's easy to read compared to other languages! For my own good it may be better if you keep focusing on Matlab instead of diverting efforts to other languages.... PLEASE keep on writing great Matlab scripts!

I guess the main point of my post should have been that I think the documentation in https://www.myroms.org/wiki/Nested_Grids is inconsistent with the Fortran code, and hence presumably also with the Matlab pre-processing scripts, although I have not been able to verify the latter. Specifically, on the version of the wiki page last modified 15:13, 17 July 2019, it says in section https://www.myroms.org/wiki/Nested_Grid ... s_Metadata

Code: Select all

       int coincident(Ngrids) ;
               coincident:long_name = "coincident donor and receiver grids logical switch" ;
               coincident:flag_values = 0, 1 ;
               coincident:flag_meanings = "false true" ;	
       int composite(Ngrids) ;
               composite:long_name = "composite grid type logical switch" ;
               composite:flag_values = 0, 1 ;
               composite:flag_meanings = "false true" ;
       int mosaic(Ngrids) ;
               mosaic:long_name = "mosaic grid type logical switch" ;
               mosaic:flag_values = 0, 1 ;
               mosaic:flag_meanings = "false true" ;
       int refinement(Ngrids) ;
               refinement:long_name = "refinement grid type logical switch" ;
               refinement:flag_values = 0, 1 ;
               refinement:flag_meanings = "false true" ;

that the 'coincident' etc. fields are of dimension Ngrids. Do I assume correctly that they should instead be of dimension Ncontact?

The ncdump of the NetCDF header in the Wiki is very useful for people who cannot generate a contact file with Matlab. It conveys the correct structure of the contact file without me having to trace the generation of that file in the Matlab code. When I started out writing the script, I basically copy/pasted this information. Hence it maybe worthwhile to fix it.

The bug resulting from this is a bit nasty, because it is latent using 2 grids Ngrids == Ncontact. So even with the incorrect NetCDF structure, everything works. Only when going to three grids there is a *_get_var() start/stride error due to the inconsistent lengh of the allocated array and the lengh of the field in the nc file. I checked the integrity of the NetCDF file 20 times because I thought it was corrupted, after all the NetCDF structure had worked using 2 grids.

Regards, Stefan