Add utility script to convert existing mpas-o ics to omega ics#562
Add utility script to convert existing mpas-o ics to omega ics#562katsmith133 wants to merge 5 commits into
Conversation
xylar
left a comment
xylar
left a comment
There was a problem hiding this comment.
Thanks so much for getting this going! It's pretty close to what we need.
One small development workflow detail: Make sure to use pre-commit when you're committing files so they get linted. Easy enough to lint later but it makes the commit history a little messier.
I have a few comments, largely similar to @cbegeman's.
We need to figure out how we want surface pressure handled, because that's pretty central to not just the EOS but the correct computation of the p* coordinate. That's the one piece that I think might need further discusison.
|
@xylar and @cbegeman, thanks for the draft review! Linting: I interpreted this statement polaris/docs/developers_guide/quick_start.md Lines 553 to 556 in e68cf04 to mean that the pre-commit was active, but I see now that that is not the case. I will make sure to fix that in the next commit. Thanks!
PS vs AS: Thanks for that catch! Something must have switched it up in my brain 🤦♀️ Everything else: Will work on making those changes today! |
katsmith133
force-pushed
the
add-mpaso-ic-to-omega-conv
branch
from
cdff9ae to
8784e5d
Compare
|
Ok, made most of the changes from both of your reviews (please let me know if I didn't address them in the way you anticipated), just need to change the pressure calculation and how we want to define surface pressure, and then also add in the Earth radius scaling discussed in E3SM-Project/Omega#395 (comment). Also maybe add in some documentation, but I'll leave that for when I change it away from being a draft. Also, linting is back in the game! |
|
If we want to include the sphere radius fix here, we would also need to renormalize all the Cartesian mesh coordinate ( |
@xylar I am open to doing the work, if that is what you think is the best course of action. What is the other option if we dont do the scaling in this script? Have it in the Omega code? I can see benefits to both. |
That's a good question. I would personally prefer it not be something Omega tries to compensate for and just be an error if the sphere radius of an input file doesn't match the PCD value but others may very well feel differently. Probably we should discuss this more on the Omega side. See E3SM-Project/Omega#395 (comment). |
|
Is it an option to just have these fields properly scaled during mesh creation in compass? I thought we were going to make a new mesh anyhow since the recent ones have ice shelf cavities. |
@vanroekel, perhaps you can weight in here but my understanding was that there wasn't any appetite for creating new Compass meshes without ice-shelf cavities and that we would go with the older E3SM initial conditions that were constructed without them. I think there's a risk of going down a rabbit hole if we try to create new meshes and initial conditions in Compass. We won't be able to use them in E3SM itself, for example, so they would only be useful for standalone testing. But also PCD isn't in Compass so we'd need to manually intervene to set the sphere radius. One manual intervention won't be too hard to do or to document but if it turns into several, which seems plausible, that's where we start needing a special Compass branch for the new mesh and we're down a rabbit hole. It seems preferable to me to prioritize the translation script for any pre-Polaris initial conditions and Polaris itself for any new ones. |
Thanks for reminding me of that @xylar. No need to rehash settled discussions. |
|
I agree with @xylar's recap and priorities. |
|
Maybe we can proceed without the sphere radius fix. I don't think it's crucial for initial global Omega simulations. Let me know if I'm missing something. |
Not fixing the sphere radius is one option. To me, that feels like it would make comparison between MPAS-Ocean and Omega a bit more challenging. MPAS-Ocean will use the sphere radius in the metadata in standalone mode. Omega will use the one from PCD but will have coordinate arrays that are consistent with the other. It feels to me like the happy medium is just scaling the coordinate variables and setting the |
It does look like at least second derivatives rely on the actual coordinates https://github.com/E3SM-Project/Omega/blob/develop/components/omega/src/ocn/HorzOperators.h#L336 |
|
I'd prefer that we do the scaling here as part of this tool. I went through the mesh converter and here are the affected variables: Scaled by R (linear distances):
Scaled by R² (areas):
|
|
Ok, I can work on including the rescaling. Just to be clear this would be something like this? Or is it more complicated? |
|
Yep, that's exactly it. |
|
Ok, one more question. I have is so that it changes the Options:
|
|
I think we want to remove almost all global attributes. The config options for sure. No need to try to translate them to Omega equivalents. They're just provenance. The ones to keep are those specifically for MPAS meshes:
Maybe also these (though Polaris and Omega will not use them):
|
|
Ok, here's what I've got (this is all for the QU240 mesh): Surface Potential Temp (MPAS) - Conservative Temp (Omega) Map Percent Diff of Surface Absolute Salinity (Omega) - Practical Salinity (MPAS) Map Here is the header info for the Omega netcdf file: And here is the header info for the new MPAS netcdf file: Both files have zero velocities and both Any other verification that would be helpful in making sure things are being done correctly? |
| ds.encoding['unlimited_dims'] = [ | ||
| d for d in ds.encoding['unlimited_dims'] if d in ds.dims | ||
| ] | ||
| ds.to_netcdf(output_file) |
There was a problem hiding this comment.
I think we probably want to use https://mpas-dev.github.io/MPAS-Tools/master/generated/mpas_tools.io.write_netcdf.html#mpas_tools.io.write_netcdf
The reason is that this will use the NetCDF default fill values. We should also talk about the format to use. I had thought we wanted NETCDF3_64BIT_DATA and this is what Polaris produces. But it sounds like E3SM v4 will use NETCDF4.
There was a problem hiding this comment.
For now I have changed it to use mpas tools. Perhaps we should discuss the format in the next Omega meeting?
|
Your test output from the QU240 initial condition looks very promising! Thanks for those comparisons. |
|
Ok, updated to mpas tools Temperature absolute difference (top = this PR, bottom = McDougall 2002): 
Salinity percent different (top = this PR, bottom = GSW Toolbox): Header info from new Omega netcdf file: Header info from new MPAS netcdf file: |
|
One more variable needs conversion: |
4 participants
PR adds a utility script to convert existing MPAS-O initial conditions to Omega initial conditions. In general, it converts potential temperature/absolute salinity to conservative temperature/practical salinity using the GSW toolbox, it sets the velocity fields to zero, it renames variables to match expected names in Omega using
mpaso_to_omega.yaml, and it computes and addsPseudoThickness.Flags:
--input-file(required) = input path and name of MPAS-O initial condition file.--output-file(required) = output path and name of Omega initial condition file.--eos-type(optional, defaults toteos10) = choose betweenteos10andlinearto either convert to conservative temperature and practical salinity for use withTEOS-10EOS option in Omega, or keep the same potential temperature and absolute salinity for use with theLinearEOS option in Omega. Output file is appended withteos10eosorlineareosto help keep track.--zero-velocity-mpas-file(optional, defaults to not executing this) = option to output another initial condition file that is for MPAS-O, but with the velocity fields set to zero.Note:
mpaso_to_omega.yamldoes not contain all the variable names we need to convert (eg.latCelltoLatCell). For now these are still included in the new omega ic file, but with the old names. Options:mpaso_to_omega.yamlto upper camel casempaso_to_omega.yamlthat are needed for Omegampaso_to_omega.yamlLeaving PR in draft mode for now until things are more finalized and the below checklist can be filled in.
Checklist
api.md) has any new or modified class, method and/or functions listedTestingcomment in the PR documents testing used to verify the changes