replace CAM-SE VR control volume grids with newer/better grids

[adamrher]

[Note I originally opened this issue in CAM: https://github.com/ESCOMP/CAM/issues/665]

Replace ESMF mesh files for ARCTIC, ARCTICGRIS and CONUS grids in ccs_config, using an improved algorithm. By improved, I mean the control volumes are more regular, with less frequent occurrences of non-convex polygons (which tends to reduce the accuracy of the mapping ... although I'm told ESMF can handle these fine). This is achieved by only allowing up to 6 sided polygons, as opposed to the current algorithm that permits 14 sided polygons. I'm referring to this new algorithm as "chevrons" since it does tend to produce some non-convex 6-sided chevrons (however, this preferable to our egregiously non-convex 12 sided "stars" that results from the current algorithm).

Changing the mesh files will change answers for anything that uses mapping weights. But it's not clear whether the F-compsets will have answer changes because nothing is mapped -- everything is on the same grid (maybe the SST/ICE dataset is mapped using the mesh files?).

I've verified that the new grids aren't of a lower quality by checking their conservation properties (mapping them to themselves using ESMF and then checking those maps) compared to the current ones. The global area has smaller errors, and the relative/maximum/least-squares errors are all reduced using these new mesh files.

/glade/work/aherring/grids/var-res/ne0np4.ARCTIC.ne30x4/grids/ne0ARCTICne30x4_esmf_chevrons_c220827.nc
/glade/work/aherring/grids/var-res/ne0np4.ARCTICGRIS.ne30x8/grids/ne0ARCTICGRISne30x8_esmf_chevrons_c220928.nc
/glade/work/aherring/grids/var-res/ne0np4.CONUS.ne30x8/grids/ne0CONUSne30x8_esmf_chevrons_c220928.nc

These will need to be added to the inputdata and paths updated in ccs_config/component_grids_nuopc.xml. I don't think we should bother updating the MCT mapping files, as MCT will be deprecated soon/eventually.

Question. In the inputdata repo, the meshes belong in inputdata/share/meshes/ ... do they need to be consistent with the equivalent SCRIP grid files in inputdata/share/scripgrids/? If so, then I will need to add these new SCRIP files to the inputdata too.

@PeterHjortLauritzen
@patcal
@jedwards4b
@fischer-ncar
@cacraigucar

[adamrher]

@jedwards4b says:

I don't believe we need the scripgrids in inputdata.

Would this be a problem if the mesh files was created from the scrip file? You will never be able to reproduce that mesh file again if you get rid of the scrip file. Is that a problem? I can't think of any glaring reasons why you wold need to recreate the mesh files though ...

[mvertens]

If the atm mesh changes you will change answers if the land mask and or fraction on the atm grid becomes different. These quantities are obtained by mapping the ocean mask from the input mask file setting to the atm grid.

On Thu, Sep 29, 2022 at 11:04 AM Adam Herrington ***@***.***> wrote: @jedwards4b <https://github.com/jedwards4b> says: I don't believe we need the scripgrids in inputdata. Would this be a problem if the mesh files was created from the scrip file? You will never be able to reproduce that mesh file again if you get rid of the scrip file. Is that a problem? I can't think of any glaring reasons why it would be a problem ... — Reply to this email directly, view it on GitHub <#62 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4XCEZD5BSA6HCIER3MXALWAXD3PANCNFSM6AAAAAAQY64QNQ> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Dr. Mariana Vertenstein CESM Software Engineering Group Head National Center for Atmospheric Research Boulder, Colorado Office 303-497-1349 Email: ***@***.***

[adamrher]

Thanks Mariana. We should expect answer changes then.

I'm testing the new grids right now, and am getting an error in the atm nuopc cap:

398:ERROR: CAM n, lonmesh(n), lon(n), diff_lon =    100      0.0000000000000       180.0000000000000             0.18000D+03

I looked into the error message, and it's actually written backwards. The first longitude value is "lon(n)" and the second value is the "lonmesh(n)". I don't really understand this error --- I checked that in the new mesh file, longitudes are bounded by [0,360]. But zero is the prime meridian, and not equal to +180 degrees. So note sure what's going on -- I'm going to plot the mesh files to see if maybe the coordinates are offset by 180 degrees ...

[mvertens]

Hi Adam, Steve had surgery today and will be in the hospital overnight. So I’m staying as well. I’ll try to look at this tomorrow when I get back home. I think it’s ok if the coordinates are shifted by 180. We should check with bob. I think the error check is not general. Mariana

On Thu, Sep 29, 2022 at 4:11 PM Adam Herrington ***@***.***> wrote: Thanks Mariana. We should expect answer changes then. I'm testing the new grids right now, and am getting an error in the atm nuopc cap: 398:ERROR: CAM n, lonmesh(n), lon(n), diff_lon = 100 0.0000000000000 180.0000000000000 0.18000D+03 I looked into the error message, and it's actually written backwards. The first longitude value is "lon(n)" and the second value is the "lonmesh(n)". I don't really understand this error --- I checked that in the new mesh file, longitudes are bounded by [0,360]. But zero is the prime meridian, and not equal to +180 degrees. So note sure what's going on -- I'm going to plot the mesh files to see if maybe the coordinates are offset by 180 degrees ... — Reply to this email directly, view it on GitHub <#62 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB4XCEZB2GJVLPPAXSLSJTDWAYH2LANCNFSM6AAAAAAQY64QNQ> . You are receiving this because you commented.Message ID: ***@***.***>

-- Dr. Mariana Vertenstein CESM Software Engineering Group Head National Center for Atmospheric Research Boulder, Colorado Office 303-497-1349 Email: ***@***.***