mksurfdata_esmf produce wrong output when using a mesh file and does not check for mesh compatibility with nx and ny

[negin513]

Brief summary of bug

I was trying to use mksurfdata_esmf for south Africa domain. At first, I've noticed all the variables on the output were zeros and was not correct. I've noticed a few other issues while working with this that I summarized below.
These issues are also relevant for non-WRF regional cases that require mesh files.

1. The user can specify mesh file with ./gen_mksurfdata_namelist.py through --model-mesh option. The code by default assume values of nx=-999 and ny=-999 which produce files that are have only zeros as their output.
   It was not clear that the code needs --model-mesh-nx and --model-mesh-ny, and by default it was assigning a wrong value (-999) which produced wrong results (only zeros) without any errors or warnings.

@ekluzek and I was not sure what is causing this issue, so I highly suggest improving this as it might cause confusion for other users.

Solution:

• These --model-mesh-nx and --model-mesh-ny flags should be required when using --mesh-files option instead of assigning a default value of -999. There are different ways to do this, but at the very least the code should check via ifs and print out some errors instead of proceeding with default values.

2. Since mesh files are in 1-d format, I am not sure how to figure out values of nx and ny from the mesh files. How can the user find nx and ny from the mesh files to provide inputs of ./gen_mksurfdata_namelist.py?

3. For a mesh file, the workflow works without any complains with any random values of nx and ny but the output file is not correct. For example to figure out nx and ny I looked at my wrfout files (2d files), but it is not clear which direction is nx and which dimension is ny.
   The help does not provide any information about this (directions of nx and ny) and using the wrong nx and ny (for example flipped nx and ny) still produces a surface dataset files that is wrong. We need to add some testing to make sure nx and ny is compatible with the mesh file provided.

Solution:

• We either need to remove the requirements for nx and ny and require the code to detect nx and ny from the mesh file on the fly.
• At the very least we need to put in some error checks for wrong nx and ny, so the code does not proceed without any errors or warning.

I have talked with @slevisconsulting about this today, and he mentioned he noticed similar issues.

• It seems like the best solution to address all the above would be for the workflow to automatically detect nx and ny, instead of relying on the user input which might not be compatible with each other.
• At the very least we need to add some error checking to make sure the values provided by the user are compatible with the mesh file.

General bug information

CTSM version you are using: ctsm5.2.mksurfdata

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

Configurations affected: WRF-CTSM and regional cases.

[XiulinGao]

Since I'm working on the WRF regional simulation and also in the process trying to use mksurfdata_esmf to make surfdata on Greg's Lobata (running into lots of problem but thanks to @glemieux for all the help!), I can help answer your second question: if you ncdump the mesh file there's actually information about the original grid dimension, which is the origGridDims variable. But I agree that if mksurf_esmf can automatically detect nx and ny from the mesh file but does not require user to input it would be great. My understanding is that nx should always be the row dimension and ny should be the column dimension in the case of WRF 2d-array lon and lat, but agree that a clear definition is indeed necessary!

[mvertens]

@negin513 @slevisconsulting - there is no way to determine nx and ny from a mesh file - since it only contains a one dimensional representation of the underlying mesh. That is why you need to specify nx and ny separately. I agree that error checking is needed.

[slevis-lmwg]

if you ncdump the mesh file there's actually information about the original grid dimension, which is the origGridDims variable

@XiulinGao I noticed the same in the mesh files that I generated for your wrf grids; however, @negin513 showed me an example of a mesh file that she was using that didn't include the origGridDims variable in it...

[ekluzek]

We talked about this a bit in our CTSM software this morning. Two checks that we want to add into the code are:

• Check that both NX and NY are > 0
• Check that NX*NY is equal to the size of the mesh file

Those are the simple checks that can be done. Most anything else would have to be more sophisticated.

[negin513]

Another important point is to make --model-mesh-nx and --model-mesh-ny required when the user choose --model-mesh so it gives a meaningful error instead of proceeding with the process.

[negin513]

Thanks to @XiulinGao and @slevisconsulting for pointing origGridDims variable in mesh file includes nx and ny.
I checked and it seems like origGridDims indeed shows nx and ny and the variable exist with the mesh files created from WRF domains. For other regional mesh files, the variable does not exist on the mesh file. But maybe we can check if this variable exist and use that in the code?

---

Another possibility might be checking centerCoords and finding the index of min and max lats and lons and calculating nx and ny using these values. ie.
nx = index (max lat) - index (min lat)
Similarly:
ny= index (max lon) - index (min lon).

@mvertens, @ekluzek , and @slevisconsulting : I am not as familiar with mesh files, do you think this approach works? Are there some edge cases that this approach cannot be applied to?

[ekluzek]

@negin513 that would likely work for regular lat/lon grids. But, it's going to fail for unstructured grids. But, unstructured grids are going to have ny == 1, so if you can assess if it's an unstructured grid you could use this for other cases.. I think it would also fail if the distance between gridcells isn't a constant value though, and that would be a more common case. WRF grids are likely to be on a projection system where the distance between gridcells won't be equal.

[slevis-lmwg]

Closed with merge of #1796