Some ESMF mesh files under share/meshes don't have area with units of radians^2

[ekluzek]

Some of the ESMF mesh files under share/messhes on cheyenne don't have area with units of radians^2. This is potentially a problem if a conservative remapping is used between grids that have different units. CESM also does a scaling based on area and if this scaling doesn't have consistent units and area from the mesh file is used the scaling would be wrong.

The following have units of m^2:

/glade/p/cesmdata/cseg/inputdata/share/meshes/C12_181018_ESMFmesh.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/C192_181018_ESMFmesh.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/C24_181018_ESMFmesh.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/C384_181018_ESMFmesh.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/C48_181018_ESMFmesh.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/C5_181018_ESMFmesh.nc

The following have area, but don't have units defined for it. If the units are radians^2 this would be fine, but it's unclear when the units are not defined on the files:

/glade/p/cesmdata/cseg/inputdata/share/meshes/0.125nldas2_ESMFmesh_cd5_241220.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/5x5pt-amazon_navy_ESMFmesh_cd5_c20210107.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/bias_correction_gpcp_cmap.Prec_ESMFmesh_cdf5_110121.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/bias_correction_gpcp_cruncep.Prec_ESMFmesh_cdf5_110121.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/bias_correction_gpcp_qian.Prec_ESMFmesh_cdf5_110121.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/C96_181018_ESMFmesh.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/fv0.47x0.63_141008_ESMFmesh.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/fv0.9x1.25_141008_polemod_ESMFmesh.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/fv1.9x2.5_141008_ESMFmesh.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/gland_20km_c150511_ESMFmesh.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/gland_5km_c150511_ESMFmesh_c20190929.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/greenland_4km_epsg3413_c170414_ESMFmesh_c20190729.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/gx1v6_090205_ESMFmesh.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/gx1v7_151008_ESMFmesh.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/gx3v7_120309_ESMFmesh.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/JRA025m.170209_ESMFmesh.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/ne16np4_scrip_171002_ESMFmesh.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/rx1_nomask_181022_ESMFmesh.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/TL319_151007_ESMFmesh.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/TL639_200618_ESMFmesh.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/tx0.1v2_ESMFmesh_cd5_c20210105.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/tx0.25v1_190204_ESMFmesh.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/tx0.66v1_180604_ESMFmesh.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/tx0.66v1_190314_ESMFmesh_c20190714.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/tx0.66v1_190314_ESMFmesh.nc /glade/p/cesmdata/cseg/inputdata/share/meshes/wtx0.66v1_210917_ESMFmesh.nc

[ekluzek]

@jtruesdal it looks like the mesh files used for the FV3 dycore are the above files, so this is a problem. I think the case that might be a problem would be for fluxes mapped using a conservative remapping from CAM to the ocean model. So F compsets would be fine, but B compsets would have bad answers.

[ekluzek]

Some of the above files are used, but some aren't. So I'm going to remove the ones from the list that aren't.

[billsacks]

@ekluzek do you think this is an actual issue or just a theoretical one in the future? From Bob Oehmke's email exchange last week:

The only time we use this for calculation is if user areas are used during conservative weight calculation (e.g. with the —user_areas flag in ESMF_RegridWeightGen), so if you aren’t doing that, it won’t affect the calculation, even then if both sides are using the km^2 unit then it should still work. The real issue would be if there was a difference in the units in two meshes and you were doing something between them using areas (e.g, conservative regridding or pulling out the areas and doing a calculation on the user side).

[ekluzek]

Well we know we do conservative remapping in some cases in the driver. So I'd like to evaluate if area from the mesh files does apply to the conservative remapping. If we aren't using it I suppose it doesn't matter and maybe we just drop this.

If it is being used, then I think the m^2 mesh files are definitely a problem, and I'd like to know that the units are correct for the files that don't have units. We probably need to check the code in CMEPS to see if area is being used for the conservative remapping.

[billsacks]

I did a bit of digging on this. I believe you can find the relevant uses of area in the ESMF API by searching for userarea in the documentation (http://earthsystemmodeling.org/docs/nightly/develop/ESMF_refdoc/node5.html). I have searched for userarea in CTSM, CMEPS and CDEPS, and the only reference I can find is a commented-out line in the LILAC code. My sense from this is that there is currently no problem with the use of m^2 or km^2 to specify areas. This could become relevant long-term if we ever want to use areas as specified on the mesh file rather than ESMF's computed areas for some reason, but for now my recommendation would be closing this as a wontfix under the YAGNI argument. That said, there could be some value in having consistency across the various mesh files used in CESM, so it does seem like a good idea to come up with a recommendation moving forward.

[ekluzek]

Awesome, thanks for that analysis. I did find one minor flaw in it however. I didn't find a use of userarea which is the main way that ESMF deals with area, but there are uses of ESMF_FieldRegridGetArea in our code. ESMF_FieldRegridGetArea either returns the user-area, or it calculates the area. I think this means that since we don't tell the ESMF_MeshCreate to use the area from the file -- that it'll be calculating it at that point. So I think it still doesn't matter, which probably means that we should prefer to NOT add area to mesh files.

[ekluzek]

The one case that I do think is a problem though is the mizuRoute case. In the mizuRoute case I'm giving a mesh that isn't used for regridding, so it has incorrect area. It's a little square near the center of the HRU's for mizuRoute. When ESMF calculates the area of these little squares it's going to be some small area that's incorrect for what's actually happening. For regridding it doesn't matter since it's using a mapping file, but if area is used for other purposes it could be a problem. And it does look like area is used for other things.

So it doesn't matter for almost all of CESM -- except mizuRoute. And in mizuRoute I'm wondering if this is the reason we are having mapping problems?

https://github.com/ESCOMP/mizuRoute/issues/339

[billsacks]

Awesome, thanks for that analysis. I did find one minor flaw in it however. I didn't find a use of userarea which is the main way that ESMF deals with area, but there are uses of ESMF_FieldRegridGetArea in our code. ESMF_FieldRegridGetArea either returns the user-area, or it calculates the area. I think this means that since we don't tell the ESMF_MeshCreate to use the area from the file -- that it'll be calculating it at that point. So I think it still doesn't matter, which probably means that we should prefer to NOT add area to mesh files.

My understanding - maybe wrong - is that this would only use user-defined areas if the grid / mesh was created with the addUserArea flag. So again, I think the uses of this routine in our code are using the ESMF-calculated areas, not the areas on file. Maybe that's what you're saying, too.

[ekluzek]

I'm filing this as a wontfix. It doesn't matter for most of CESM, and I was only speculating it might be a reason for one of the problems we had in mizuRoute. But, that issue was figured out.