PCT_URBAN=0 at 0° longitude using 0°-360° longitude mesh but works using -180-180 longitude mesh

[YuanSun-UoM]

Brief summary of bug

I used mksurfdata_esmf for Europe (crossing 0° longitude) and found PCT_URBAN was incorrect using a 0-360 longitude mesh, but the other parameters seemed correct.
I also used a -180°-180° longitude mesh to generate the regional surface data, where the PCT_URBAN>0 at 0° longitude.

General bug information

CTSM version you are using: ctsm5.3.021

Does this bug cause significantly incorrect results in the model's science? Not.

• Users could use 180°-180° longitude mesh as an alternative to generate correct surface data.
• PCT_URBAN=0 did not abort simulations.

Configurations affected: Not applicable

Details of bug

PCT_URBAN=0 at 0° longitude when using 0°-360° longitude mesh.

Important details of your setup/configuration so we can reproduce the bug

I compiled the mksurfdata_esmf using the GNU compiler on ARCHER2.
ESMF version:8.6.1
PIO version: 2.6.2

Important output or errors that show the problem

Please see input and output files in https://www.dropbox.com/scl/fo/zrr05povz7fj21u21dlz8/AFMFt5pDCzyjopS2AFyTwoU?rlkey=wbun43dqua3q5q5uj99aru4ko&st=mgg4b2pc&dl=0

[olyson]

I was able to replicate this with ctsm5.3.021.
The surface dataset with a -180 to 180 type mesh generated with this namelist looks ok:
/glade/work/oleson/ctsm5.3.021/tools/mksurfdata_esmf/surfdata_180-180mesh.namelist
/glade/work/oleson/ctsm5.3.021/tools/mksurfdata_esmf/surfdata_3.6x3.6_180-180_hist_2022_78pfts_c250510.nc

while the surface dataset with a 0 to 360 type mesh generated with this namelist has 0 PCT_URBAN across Greenwich:
/glade/work/oleson/ctsm5.3.021/tools/mksurfdata_esmf/surfdata_0-360mesh.namelist
/glade/work/oleson/ctsm5.3.021/tools/mksurfdata_esmf/surfdata_3.6x3.6_0-360mesh_hist_2022_78pfts_c250510.nc

The longitude coordinates in the 0 to 360 surface dataset for a latitude slice are shown here:

[wwieder]

Is our solution here to use the -180-180 mesh for creating regional datasets directly with mksurfdata_esmf? @ekluzek thought there was an outstanding issue about using different mesh files?

[ekluzek]

We should just document this as something that can be done. I'll also find the issue pointed out above and link in here.

[wwieder]

@slevis-lmwg do you have other ideas here. I think the summary from the SE meeting was leaning for addressing this with documentation, but maybe not code changes.

[olyson]

@YuanSun-UoM , I'm trying to understand why the nodeCoords variable in the 0-360 mesh file would have these coordinates that seem to be going from around 359 to 180 periodically, e.g., from an ncdump of the mesh file:

359.233978271484, 37.2479667663574,
359.645385742188, 36.9415435791016,
359.632690429688, 37.2589263916016,
180.042083740234, 36.9507522583008,
180.031524658203, 37.2681884765625,
0.43890380859375, 36.9582748413086,
0.430450439453125, 37.2757568359375,

Does that seem right to you? I don't actually know what the nodeCoords variable is used for.