Make sure analysis scripts do not rely on mesh info present in input files

[milenaveneziani]

Pretty soon we will default to having no mesh information in output MPAS files. Therefore, we need to make sure that none of our analysis scripts rely on having mesh variables in model files.

A related issue is to make sure that the meshfile (initial condition or restart file) has all the info we need for running MPAS analysis scripts (see for example depth-related fields that are necessary for the OHC calculation).

[xylar]

A related issue is to make sure that the meshfile (initial condition or restart file) has all the info we need for running MPAS analysis scripts (see for example depth-related fields that are necessary for the OHC calculation).

I think this info can still be stored in the analysis members' output files as needed. It does not need to be in the file used to read the mesh. It is just that the mesh info (that is, everything in the mesh stream, which includes things like xCell, yCell, latCell, cellsOnCell, etc.) doesn't need to be stored redundantly in each analysis member's output.

[milenaveneziani]

But wouldn't be nice if we had all the mesh information in one single file? This seems even more important to me if we are moving away from storing mesh variables in output files.

[xylar]

@milenaveneziani, it seems to me the philosophy of AM output, at least in MPAS-O test cases, is that we want separate streams (therefore separate NetCDF files) for separate AMs. I would think that only fields that are needed across several AMs should go into the main output stream to prevent redundancy. Anything specific to an AM should have its own stream (and its own NetCDF file(s)).

[milenaveneziani]

@xylar: I am a bit lost. What I was thinking about is not AM-specific streams, but mesh-related fields such as refBottomDepth that are not found in both the initial condition and restart files (at least this is how it used to be a few months. Not sure if things have changed in this respect lately).

[xylar]

@milenaveneziani, ah, I see. refBottomDepth and such (maxLevelCell, refLayerThickness etc.) are not part of the mesh (because it's ocean-specific) so it would need to be included specifically. I agree that such fields should be in the output stream.

[milenaveneziani]

@xylar: I disagree about having this information in the output stream. Because we may need the same piece of info in different AM's, and, similarly to having mesh variables in output files, we would be adding superfluous output in different files.
Couldn't we instead have all the information we need for our tools to work (mesh, vertical discretization, component-specific general fields, ..) in one file per MPAS component?
By 'tools' I include mesh-generator, paraview-extractor, and MPAS-Analysis.

[xylar]

@milenaveneziani, I believe all the information you're after has to be in the initial condition file and/or the mesh file. There is a very specific definition of what is in the mesh file (it's hard coded in MPAS). Anything not there, e.g. the fields that define the vertical grid, has to be in the initial condition file. Nearly always, the mesh is also in the initial condition file, but this is not an MPAS requirement so it would be better to look up what the mesh file is in the streams file and use that to get the mesh-specific fields (xCell, yCell, etc.) and then to use the streams file to find the initial condition and use that to find the fields related to the vertical coordinate (maxLevelCell, bottomDepth, refBottomDepth, etc.).

I think it wouldn't be a good idea (and it may be too late) to require that this info be in a single file. But it has to be in one or both of the mesh and initial condition files or the model wouldn't run.

Does that help clear things up a bit? If not, maybe I should give you a call so we can chat some more.

[milenaveneziani]

Perfectly clear. And indeed my solution in the past has been to cp the meshfile to something that I called gridfile, and then ncks the info I needed from an initial condition file (refBottom, etc) and add them to my 'gridfile'.
I don't think this is the workflow we want.. And now that we are thinking to remove the mesh info from output files, perhaps it's a good time to address this issue, one way or another.
Thanks for sticking with me on this, @xylar.

[xylar]

@milenaveneziani, okay, great. I think we're on the same page now. I agree that the various tools need to be able to read the the necessary pieces from various sources without causing trouble. I will try to make sure this is true for the paraview extractor. Currently, the only field it could potentially make use of that is not in the mesh is maxLevelCell, which would need to be in either the file passed with -m or the list of files passed with -f (so it couldn't be from some third file). It would be great to be able to parse the streams file as part of the paraview extractor, too, so I'll probably steal the code from this repo a soon as we've settled on something we're happy with.

[pwolfram]

@milenaveneziani, this could be a tricky issue and we should prepare for this challenge ASAP because it could break the analysis. Do we have a timeline on when the mesh will be removed from analysis output files?

[xylar]

@pwolfram, I believe the mesh info is already not part of the analysis output. We rely on a data file that Milena put together that includes the mesh and some of the vertical grid info (e.g. refBottomDepth). My understanding is that the best way to handle this would be to look at the streams file to find the mesh and init files that were used, and read the appropriate mesh/vertical grid data from them. @milenaveneziani, is that consistent with how you see this being handled?

[milenaveneziani]

@xylar, @pwolfram: sorry, I missed your last 2 comments on this one!
indeed we are running into trouble now, because sometimes the model output files are transferred from one machine to another for doing the analysis. This can actually happen often, because not everybody has access to the machine where the simulations are performed.
Because of that, the original init file that is in streams.ocean will not be found.

So, we need to think of a different solution.

[milenaveneziani]

I just talked with @mark-petersen and he suggested to use one of the restart files. so, we would have to look into the streams file again, but looking for the rst filename.
And then, when transferring the data we still need to make sure that the restart files are transferred as well (or at least one of them).

This in my view is still a bit cumbersome than just having all mesh and vertical coordinate information in one single file, but it is less likely to break things (and we will issue a specific error when the rst file is not found).

What do you think?