Modify mesh mask with new mesh_mask_modifier tool

[slevis-lmwg]

Description of changes

mesh_mask_modifier is a tool that modifies mesh_mask files. It reads the mesh_mask file and outputs a modified copy of the file.

mesh_mask_modifier will complement the fsurdat_modifier tool, which modifies fsurdat files. When a user introduces land in place of ocean grid cells in their fsurdat file, they need to modify the mesh_mask file for their fsurdat modifications to take effect in a simulation.

Specific notes

Contributors other than yourself, if any:
@ekluzek

CTSM Issues Fixed (include github issue #):
Fixes #1644

Are answers expected to change (and if so in what way)?
N/A ...new tool

Testing performed, if any:
Test run in progress. Typed:
./mesh_mask_modifier modify_slevis.cfg
in /glade/work/slevis/git/mksurfdata_toolchain/tools/modify_mesh_mask

[slevis-lmwg]

@billsacks @ekluzek @adrifoster and I talked at stand-up about the slowness of my code. A few ideas came up:

• fortran can run nested loops like these much faster than python
• xarray/pandas may have non-loop solutions (xarray is built on top of pandas); pick Anderson Banihirwe's brain!
• does it make more sense to use the existing tool that generates mesh files rather than developing a new tool for modifying mesh files...

[billsacks]

Thanks for the summary, Sam. To clarify on this:

• xarray/pandas may have non-loop solutions (xarray is built on top of pandas); pick Anderson Banihirwe's brain!

I think both are built on top of numpy, so I'd think that general whole-array operation techniques that work in numpy would work here as well. If there were some function (in xarray or elsewhere) that was geared specifically for this kind of use (finding the overlapping points between two spatial domains) then all the better. But if it's hard to find a way to cast this in terms of existing functions or whole-array operations, then doing it in Fortran might be the best bet.

[adrifoster]

Hey all,

I was thinking about this more and it might be easier to think about this outside of xarray.

I would think (?) there should be a way to do something faster if you just pull out the latitudes and longitudes into np arrays. Or perhaps, as @billsacks suggested as I was chatting with him, 1 big np array where the rows (for example) are the lats/lons from 1 file and the columns are lats/lons from the other file.

Then you may be able to do some whole-array operations to get a matrix of T/F.

I was messing around with an example of this but am having to get back to my regularly scheduled manuscript writing for the week...

I will think on this more if I have time and report back with any other ideas! But since @slevisconsulting you know much more about the requirements for this function, perhaps these ideas aren't tractable.

[slevis-lmwg]

Thank you @adrifoster @billsacks for your comments. I expect to return to this around the middle of next week. (Still distracted with the move.)

[slevis-lmwg]

@ekluzek I'm initially asking for your review and would also be happy if you have additional reviewers in mind. This is a relatively simple tool and development has stopped at this point. It's probably close to ready.

[slevis-lmwg]

The tool already has user instructions, but I just now decided to also add detailed instructions for a specific use-case, using text that I previously included in Isla Simpson's corresponding google doc.

[ekluzek]

@slevisconsulting I have two thoughts here after starting to use it.

The first is:

• Move to a shared directory (modify_inputdatasets)?
  Currently this tool is in. it's own directory (as is modify_fsurdat). Personally it seems like normally directories should have more than one thing in them. So a shared directory makes more sense to me.
• Add capability to handle other variable names besides the standard names for surface datasets?
  I'm using it to get a mask from a domain file, so I'd like to be able to customize the variable names, which should be straightforward to do.

[ekluzek]

@slevisconsulting there are still some checkboxes that should be addressed. You did add some unit testing, so I'll check off that one, but the other two should be handled.

[slevis-lmwg]

I think I have addressed what we discussed.
@ekluzek pls let me know if I have missed anything.
All tests (python and clm_pymod) PASS.

Just for the record: when I'm in the ncar_pylib environment, the new test's nco commands work without a module load nco beforehand. But in the recommended ctsm_py environment, I need to invoke module load nco before starting the test.

[slevis-lmwg]

Made test links on cheyenne and izumi, so that now both dev105 and dev106 link to dev104:
ln -s ctsm5.1.dev104 ctsm5.1.dev106

[slevis-lmwg]

@ekluzek I thought I'd test on izumi but ran into this problem:

>>> module load lang/python
module-info mode load in progress
>>> ./py_env_create
Use conda to install the python environment needed to run the CTSM python tools in the conda environment: ctsm_py
Using the file: ./python/conda_env_ctsm_py_cgd.txt
Create ctsm_py
conda create --force -n ctsm_py -q

CustomValidationError: Parameter channel_priority = 'strict' declared in <<merged>> is invalid.
The value 'strict' cannot be boolified.

Error creating conda environment ctsm_py

Is this user error on my part or would you like me to open an issue?

ADDITIONAL INFO
I tried this (on izumi still):

conda env list
conda activate /home/slevis/anaconda/envs/ctsm_py
./fsurdat_modifier fillindianocean/modify_fsurdat.cfg

and got a malformatted .nc file as in #1658 but fixed the problem by unloading python:
module unload lang/python

Next (out of curiosity) I tried ./py_env_create from the already active ctsm_py enviroment and didn't get an error!

[ekluzek]

@slevisconsulting go ahead and create an issue about this. I just tried on izumi on your branch and I don't see this problem. But, that means there is likely some environment issue that we need to track down. So having your problem clearly identified in an issue would help track it down. We need this to work for everyone everywhere so it's important to track down these user environment issues.

[slevis-lmwg]

cheyenne testing
clm_pymods PASS
python (make all) PASS

I made links on both cheyenne and izumi from the dev109 to the dev110 baselines.
(dev108 --> dev109 had no updates to python codes, so no need to rerun testing.)

[ekluzek]

@slevisconsulting it looks like there is one checkbox that isn't completed. See above for this July/15th comment that has one checkbox that's open.

@slevisconsulting it looks like there isn't any testing for this new script. We should add some level of testing for it. You could add some unit testing, a test suite test, and/or a test/tools test for it. It also looks like the default config file won't actually work as it is, it would be good to have one that was actually functional.

• Add testing for mesh_modifier
• Get config file that will be functional

Can you take care of that one? It just needs a functional example of a config file that can be run to test it.

[ekluzek]

Ok @slevisconsulting and I discussed the working config file. This was a requirement just to make sure testing was in place. There is a system test in place that creates a working config file.

So I'm removing the requirement since the test sys covers it.

[slevis-lmwg]

Can you take care of that one? It just needs a functional example of a config file that can be run to test it.

@ekluzek here's notes from our discussion just now:

• The system test for mesh_mask_modifier generates a .cfg file and a landmask.nc file on the fly.
• To supply a working .cfg file, we would need to provide a landmask.nc file, which adds a maintenance consideration.
• We decided the template .cfg is sufficient.

[ekluzek]

@slevisconsulting one thing I realized we should update at some point. You point to a test file in the mesh_modifier tool and it's README.

/glade/work/slevis/git/mksurfdata_toolchain/tools/modify_input_files/islas_examples/modify_mesh_mask/fill_indian_ocean/fill_indianocean_slevis.nc

Since it's a personal path we can't rely on that staying around. So we should either add it to python/ctsm/test/testinputs or put it in the inputdata repository somewhere. Or remove the mention of it. Personal paths to specific files on specific machines aren't useful in the long run, we should try to avoid mentioning them.

We can do this after I merge this, but I wanted to add a note about it now.