Move jigsaw_to_MPAS to MPAS-Tools

[xylar]

@dengwirda has expressed interest in using jigsaw_to_MPAS outside of COMPASS.

This would be useful for making new MPAS meshes for potential river and land components to come.

It would also mean that changes to jigsaw_to_MPAS would be more challenging, since they would involve:

• changing a branch on MPAS-Tools
• building a test conda package
• building a test conda environment
• running COMPASS with the test environment
  This sounds daunting but it can be done without too much difficulty as long as the process is documented.

It could also have many advantages:

• obviously, other infrastructures and workflows besides COMPASS could use it
• jigsaw_to_MPAS would be a proper python module, rather than a "fake" one that we have to link to in every test case
• dependencies could be maintained as part of releases of the mpas_tools conda package, rather than through the separate compass metapackage
• ...

[xylar]

cc @dengwirda, @proteanplanet, @sbrus89, @pwolfram, @mark-petersen, @jonbob

[xylar]

Small thing: maybe also a chance to rename the module to something like jigsaw_to_mpas. Python convention is no capital letters in modules. Underscores are frowned upon but seem hard to avoid here.

[dengwirda]

@xylar I think we could call this, say, mesh_creation_tools, for consistency with mesh_conversion_tools, etc. There's also support for non-JIGSAW workflows here (i.e. Triangle) that should be kept I think.

Let me make an initial PR to MPAS-Tools that combines this move with some related changes needed for ICoM meshing.

[xylar]

@dengwirda, go ahead, but please put it as a module of conda_package/mpas_tools, not at the same level as mesh_conversion_tools. While I can't help the legacy of how the repo is laid out, I would like all new python tools to be part of the conda package.

[xylar]

And mesh_creation_tools works for me, but I called the wrappers for the mesh_conversion_tools just conversion under the conda package.

[xylar]

@dengwirda, I would also be careful about putting in a ton of work before having a discussion with the folks (e.g. @pwolfram and @sbrus89) that would also be affected by us making this move. Maybe they already know.

[pwolfram]

@dengwirda and I previously discussed this issue, which is related to moving some key grid generation features out of the model into tools. @sbrus89, please let us know your thoughts. If we can tag a version of the conda environment to each COMPASS case, ensure this with an assert, then we should be able to work around issues related to previously having all code contained inside a single repo.

[sbrus89]

To me, it feels like jigsaw_to_MPAS belongs in MPAS_Tools. So, I'm in favor of this as long as @xylar thinks the additional overhead for maintaining it inside MPAS_Tools isn't prohibitive. I also like the change to mesh_creation_tools.

As @pwolfram mentioned, we'll have to come up with a strategy for how to make sure existing COMPASS cases use the correct version of the conda environment. I believe this is the reason we haven't made this shift already. Perhaps, this can be done by extending #482. We could have COMPASS generate this script separately for each case, based on a version tag in the case xml files.

[xylar]

@sbrus89, if you're good with this change, I'm good with it for sure! It's a bit more work for me but I'm more worried about others. I'm used to the 4-step workflow I outlined above but I figured others would be intimidated.

Regarding keeping things synced, yes, as long as you have the right compass environment, it will have one and only one version of mpas_tools. So there is essentially no difference. The whole point of having compass as a metapackage was to make sure that the tools (which could include mesh_creation_tools now) stay in sync with MPAS-Model.

[xylar]

@dengwirda, I've given it some thought and I'm not sure I like the idea of moving jigsaw_to_MPAS into MPAS-Tools in conjunction with other changes. I think that sounds dangerous, time consuming and difficult to debug. My preference would be to move exactly what we have over, likely with a rename, and to then make changes within MPAS-Tools as part of follow-on work. I think that would be the least disruptive approach.

Would that be an approach you could get behind? I would, of course, include you as a reviewer on the pull request to make that initial move so that you could make sure none of that work was incompatible with the changes you envision making after that.

[dengwirda]

@xylar Yes, happy to do this in two stages as you suggest.

Also want to check whether there's any specific build / make instructions on hand for MPAS-Tools?