Remove critical_passages stream from initial_state in global_ocean test group

[xylar]

We do not deepen critical passages in any mesh configuration, so the critical_passages mask is not needed during init. Requiring the file in stream.ocean makes it difficult to swap the mesh used in initial_state for another mesh (e.g. one generated on a different machine or with a previous version of compass).

closes #204

[vanroekel]

@xylar I'm trying to test this on chrysalis with the WC14. I've set up the init phase and pointed at meshes already made on chrysalis in the inputdata server. This is what I was trying to do that I mentioned over slack. However when I do this, I get an error I did not get before

OSError: input file(s) missing in step initial_state of ocean/global_ocean/WC14/PHC/init: ['/lcrc/group/e3sm/ac.vanroekel/testXylarPRinit/ocean/global_ocean/WC14/mesh/mesh/culled_mesh.nc', '/lcrc/group/e3sm/ac.vanroekel/testXylarPRinit/ocean/global_ocean/WC14/mesh/mesh/culled_graph.info']

It's likely this is unrelated but am confused why the init test is looking for these files. They aren't in the streams or any links I see. Could you offer some advice on this?

[xylar]

@vanroekel, I'm happy to take a closer look tomorrow but it looks like you didn't set up the test case that creates the mesh. The initial state test case can't run without it. Could you try setting up both and see if it works?

[vanroekel]

Sorry for the false alarm. I did indeed try that and once I set it up and ran the mesh test things were fine even if I pointed at a different mesh, just didn't get a chance to post back to this issue. I'll approve this works great.

[vanroekel]

approving based on visual inspection and testing on chrysalis. Thanks @xylar!

[xylar]

@vanroekel, I'm sorry, I read your first message quickly and didn't take the time to understand the problem you were facing. One of these cases where I'm trying to give a quick response when I don't really have time for a thorough one. Obviously, that's not always very helpful.

I understand the issue. Each step of a test case keeps its inputs. These need to be absolute paths to the original files, not local symlinks because Parsl will use these absolute paths to determine when the inputs are available and the step can run.

However, this is confusing and creates needless extra work in the specific case you're working with in which you want to replace the mesh (and graph file) with another one. The simplest solution I can come up with for this particular case at the moment will involve #184 (which I will merge soon). Instead of computing the mesh, you would set up the cached version of it. That still might involve a needless download, depending on the machine you're running on, but shouldn't require a half hour to create a mesh you're going to throw away.

[xylar]

Testing

I ran this branch with the ocean nightly test suite on Chrysalis with intel/impi and everything was bit-for-bit with previous tests, suggesting that even the QU240 mesh was, indeed, not deepening critical passages.

I also set up the EC30to60 test cases as follows:

compass setup -n 80c 81 82 ...

This creates a cached version of the mesh test case and normal versions of the PHC/init and PHC/performance_test test cases. Then, I replaced the links in initial_states to point to the EC30to60E2r2 versions:

mesh.nc -> /lcrc/group/e3sm/public_html/inputdata/ocn/mpas-o/EC30to60E2r2/ocean.EC30to60E2r2.210210.nc
graph.info -> /lcrc/group/e3sm/public_html/inputdata/ocn/mpas-o/EC30to60E2r2/mpas-o.graph.info.200904

Then, I added/replaced the following config options in init.cfg:

# Options related to the vertical grid
[vertical_grid]

# the type of vertical grid
grid_type = tanh_dz

# Number of vertical levels
vert_levels = 80

# Depth of the bottom of the ocean
bottom_depth = 6000.0

# The minimum layer thickness
min_layer_thickness = 1.0

# The maximum layer thickness
max_layer_thickness = 200.0

I ran the initial_state step an got a mesh with 80 vertical levels as expected. I was then able to run the performance_test using this new mesh.

@vanroekel, that's the workflow I would suggest in the future. Perhaps that's what you are already doing, with the exception that I am using the cached version of the mesh test case.