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 12 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! |
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: |
03fb442 to
9270a94
Compare
|
Ok, added a few more features:
|
| p_interface = np.zeros(ds.sizes['nCells']) | ||
| if 'atmosphericPressure' in ds: | ||
| p_interface = p_interface + ( | ||
| ds['atmosphericPressure'].isel(Time=time_index).values | ||
| / Pa_per_dbar | ||
| ) | ||
| if 'seaIcePressure' in ds: | ||
| p_interface = p_interface + ( | ||
| ds['seaIcePressure'].isel(Time=time_index).values / Pa_per_dbar | ||
| ) |
There was a problem hiding this comment.
The sum of atmosphericPressure and seaIcePressure should also be stored as surfacePressure, which will be converted to SurfacePressure in Omega once #610 gets merged (and this gets rebased).
There was a problem hiding this comment.
Note: we probably want surface pressure to be relative, subtracting 10.1325 dbar from atmospheric pressure as discussed in #610 (comment).
|
To create a new initial condition using the linear Eos without error, I had to manually change |
Ah, yes, sorry @hyungyukang I have that change in my local branch and had forgotten to push it up. I will do that shortly along with some other changes. |
4e3e4b9 to
f550a9b
Compare
5 participants
PR adds a utility script to convert existing MPAS-O initial conditions to Omega initial conditions.
In general, it:
mpaso_to_omega.yamlPseudoThicknessRefPseudoThicknessand sets it equal torestingThicknessfrom MPASWindStressMeridionalandWindStressZonal, where the first is set to zero everywhere and the second is set to a latitudinally dependent piecewise polynomial wind stress profile similar to that used in the NeverWorld2 idealized configuration (Marques et al, 2022). This wind stress profile is configurable within the script, but not through the command line.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.--visualization(optional, defaults to off) = produces 3 figures: 1. a comparison of the difference between surface potential temp from MPAS and surface conservative Temp from Omega, 2. a comparison of the percent difference between surface absolute salinity in Omega and the surface practical salinity in MPAS, 3. a plot of the surface zonal wind stress assigned toWindStressZonal.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. I am making an assumption that these will be fixed as the names get changed in Omega.Checklist
api.md) has any new or modified class, method and/or functions listedTestingcomment in the PR documents testing used to verify the changes