Bathymetry from JIGSAW being used in base_mesh.nc

[xylar]

In COMPASS global_ocean test cases there is a step in build_mesh.py:
https://github.com/MPAS-Dev/MPAS-Model/blob/ocean/develop/testing_and_setup/compass/ocean/jigsaw_to_MPAS/build_mesh.py#L60-L64
where we "inject" the bathymetry from a topography file into the mesh. This topography appears to come from JIGSAW:
https://github.com/MPAS-Dev/MPAS-Model/blob/ocean/develop/testing_and_setup/compass/ocean/global_ocean/config_files/config_base_mesh.xml#L15
so it's not clear to me why this is a topography we would trust or want to be using.

The critical bug is that not only do we use it to set a variable called bathymetry (never used again as far as I can tell), but we also set cullCell based on where this is above 20. (How was this threshold chosen?!)

This cullCell field propagates to the cull_mesh stage and is treated as the starting land mask onto which other land masks are added ("maxed" as it were). I had to dig into the cell-culler code to reming myself that this was another possible source of land masking.

Anyway, long story short, the solution is to skip the inject_bathymetry.py stage of build_mesh.py. I don't see any reason to do this stage and am curious how this crept into the workflow.

[xylar]

Here's an example of the "base" land mask coming from the JIGSAW topography:

Not a good starting point...

[xylar]

Likely also a source of weirdness around the Canadian Archipelago:

[mark-petersen]

The inject_bathymetry.py script was made to be able to visualize some bathymetry on a full spherical mesh. It was just meant to assist visualization of the location of refined meshes relative to coastlines in that first step with jigsaw.

@sbrus89 and @pwolfram, did you use the bathymetry in the file earth_relief_15s.nc for coastlines for the CONUS mesh, or was that just for early testing? Or is it just used in the Deleware mesh?

I remade the EC60to30 with this line commented out:

inject_bathymetry.py
121     #nc_mesh.variables['cullCell'][:] = nc_mesh.variables['bathymetry'][:] > 20.0

It is all here if anyone has time to look:

/lustre/scratch4/turquoise/mpeterse/runs/190306_mesh_culling_no_bathymetry/ocean/global_ocean/EC60to30/init

I changed permissions. I need to run for a flight now, but I'll try to remake those images of the coastline mesh in the next few days.

[pwolfram]

@mark-petersen, I need this key information to do the wetting / drying globally and particularly for the Delaware mesh. Please do not comment this out because we need this information for the full run and it is also, as you mention, extremely helpful for debugging too. There is probably a better way to deal with this long term but please don't remove this functionality until we have the long term solution.

[pwolfram]

cc @sbrus89 and @xylar

[pwolfram]

The long and short of it is that we need to be able to build the mesh based on topographic constraints based on elevation and this was solution employed. I don't believe we have a similar functionality but given this discussion that might have changed, especially over the last several weeks I've been gone. Any clarification here would be helpful; I agree we want the most robust solution possible.

[xylar]

@pwolfram, why is it necessary to set the cullCell array? This is the step that is causing problems and would need to be "undone" in the cull_mesh stage.

[xylar]

The long and short of it is that we need to be able to build the mesh based on topographic constraints based on elevation and this was solution employed.

I agree that the mesh can be created using this topography if you like. It is not the same topography we use for the bathymetry, which is potentially problematic especially around Antarctica, but for CONUS, for example, it is probably just fine.

The problem arises from setting cullCell. If that array is being used in some way to create the mesh, it is not the right field to use because it really does mean that these cells get culled in the final mesh (not what we want -- we have a 7 or 8 part script that determines which cells are land and which are ocean).

[xylar]

If the cullCell functionality is needed, one option is for inject_bathymetry.py to be called only by the Deleware Bay test case and not by anything in global_ocean, in which case we can leave it alone. Another would be to have a flag or break the functionality into two scripts such that the bathymetry can be added to some meshes without setting cullCell.

In any case, the need for a solution to this is quite pressing. We need new V2 meshes can be generated from code on ocean/develop (not a local copy with certain steps commented out) within the next days to a week so they can be vetted in time to go into production.

[xylar]

The preferred way to cull cells for the global ocean is this script:
https://github.com/MPAS-Dev/MPAS-Model/blob/ocean/develop/testing_and_setup/compass/ocean/global_ocean/cull_mesh.py
If this would also work for Delaware Bay, I think that would be preferable.

[xylar]

@pwolfram, could you point me to the Delaware Bay test case so I can take a look at how you use inject_bathymetry.py? I hunted around on your various branches and didn't see the test case even on the branches with "Delaware Bay" in the name.