nesting issues

[jcwarner]

I am running some tests on the nesting. To create the child grid, I am using these steps:
F=coarse2fine('inlet_test_gridr.nc','inlet_test_grid_ref5r.nc',5,24,54,40,56);
Gnames={'inlet_test_gridr.nc','inlet_test_grid_ref5r.nc'}
[S,G]=contact(Gnames,'inlet_test_contact.nc');

If I set spherical=T in the parent grid, then the m files run smoothly. However, the inlet_test is really spherical=F, and with that setting i get this error when running the m files:

Interpolating from coarse to fine ...
Reference to non-existent field 'lon_rho'.

Error in coarse2fine (line 286)
RSr = TriScatteredInterp(C.x_rho(:),C.y_rho(:),C.lon_rho(:),method);

In coarse2fine, line 286, the structure C does not have the lon_rho lat_rho spherical variables because at the top of coarse2fine there is a call to get_roms_grid that has
varhor = {'x_rho', 'y_rho', 'x_psi', 'y_psi', ...
'x_u', 'y_u', 'x_v', 'y_v'};
if (~spherical),
varhor = [varhor, ...
else
varhor = [varhor, 'lon_rho', 'lat_rho', 'lon_psi', 'lat_psi', ...

so that call to get_roms_grid does not load the lon_ lat_ stuff into the C array.

Then the coarse2fine continues and uses a different method to get the same information:

" Check available grid variables. Get input file information
% structure, I.

I = nc_inq(Ginp);
vnames = {I.Variables.Name};

got_list = {'lon_rho' , 'lat_rho' , 'lon_psi' , 'lat_psi' , ...
'lon_u' , 'lat_u' , 'lon_v' , 'lat_v' , ...

for value = got_list,
field = char(value);
got.(field) = any(strcmp(vnames, field));
end "

At this point, the nc_inq finds lon_rho in the parent grid, but the get_roms_grid did not load the lon_rho into the C array. So the error occurs because coarse2fine thinks it has the data but it was not loaded.

If I force get_roms_grid to load all the grid data in C, then it works fine. But this is not the correct fix. cant we just use
I = nc_inq(Ginp);
vnames = {I.Variables.Name};
in get_roms_grid????

[jcwarner]

why are the time steps of the child grid limited to the integer value of the refinement ratio? this is a little odd, and limiting. The time step of the child certainly needs to divide evenly into the parent time step, but does not need to be limited to be equal to the refinement ratio:

ntimestep.f90:
ELSE IF (RefinedGrid(ng).and.(RefineScale(ng).gt.0)) THEN
IF (step_counter(ng).le.(WindowSteps(ig)+1)) THEN
my_Nsteps(ig)=RefineScale(ng)
step_counter(ng)=step_counter(ng)+RefineScale(ng)
ELSE
my_Nsteps(ig)=0
END IF
IF this time step is limited, then dt in the input file is not needed for the child.

[wilkin]

John,

All valid remarks...

Yes, I've heavily modified my coarse2fine to correct the logic handling the logical state of spherical. I've turned away from using TriScatteredInterp (which will soon be deprecated anyway) in geospatial coordinates (x/y, or lon/lat) and instead I'm working in fractional grid index coordinates. This is while I grapple with conservation issues which need to be solved. In the long run - for more generic composite grids - a return to geospatial coordinates for generating the contacts file might be necessary, but for simple refinement it is not.

Keep in mind these codes are very fresh and have been tested by only a few of us, in a limited set of situations. For example, a hierarchy of 3 nests does not work yet. Two nests at the same level do. We're getting there. We had to make a decision between not releasing anything, or putting some stuff out there that is not even in beta for others to work with.

The issue of matching DT refinement to spatial refinement came up at the ROMS Meeting in Croatia. We need to have DT for all grids in the ocean.in file for the logic of the start-up to work. But I agree that computing the integer ratio of DT values to determine the number of refined grid steps to take should work.

If you make that change and test it out and report back that would be helpful. I don't have a test case where I could get away with a longer nested DT (though I suppose I could test a shorter nested DT). I'd want to check what it does to the counting of the output filenames, and any impact on averages. But I expect that is unaffected. Just too many things to work on at once.

John.

[jcwarner]

John-

I am having some trouble understanding what you are trying to say. "Just too many things to work on at once" doesn't fly with anyone anymore. Do you want other people to use these codes and help fix them or not? As someone who did all this already, I fully understand what it takes to develop a method of grid refinement into ROMS, SWAN, and get the codes to run concurrently on various levels of grid refinement. I am at a point where i am updating to the latest/greatest version on the Rutgers site. Well, actually trying to decide if i should. IF you want the community to help, then i can bring ~ 150 or more people to use this code in the next few months, all of whom will have questions, need help, want to do different things, etc. Or maybe i should wait and keep using the formulation i already have in COAWST? This is a good point in time to ask Rutgers what they want to do. Do you want more time or do you want people to use your approach?

On a similar topic - the approach that you are taking is to create a separate 'grid connectivity' file that contains the perimeter halo region points of the child grid. I personally think these points should be part of the child grid, as people are going to want to see what is happening on these points in his and rst files. But i dont think your approach will allow this. Similarly, the advection scheme like mpdata has a large footprint and needs values of omega in these child perimeter points. These values are best computed by timestepping in the child halo perimeter region, not by interpolating the omega values from the parent. So i dont think an approach of interpolating from the parent will suffice, but perhaps i am not correct. This has potential to create issues with restarts.

I am just at a critical point here trying to decide if i should distribute your approach or keep mine. Your call.

-john

[m.hadfield]

My voice may not count for much, but I intend shortly to get into serious use of the nested ROMS (having been forced to abandon such an attempt about a year ago because of a looming project deadlines and the threat to my mental health--I am not entirely joking). I would very much like to see John and his cohorts (of which I am one, actually) working on Rutgers ROMS.

[kate]

One feature new in CICE 5 (compared to CICE 4):

Read/write variables on the extended grid, including ghost (halo) cells

[jcwarner]

thanks Mark and Kate -
working on this now. Was hoping to have the new coupled version out by now, but having some unforseen issues (as if I would not have forseen them). But I am using this latest/greatest version from Rutgers. Will make future improvements in here and pass them to Rutgers for inclusion as they see fit, as usual. We can start with your CLM and BRY file formats, etc.

-john