Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tool for interpolating MPAS-Ocean output to MALI for forcing standalone simulations #577

Open
wants to merge 38 commits into
base: master
Choose a base branch
from

Conversation

matthewhoffman
Copy link
Member

@matthewhoffman matthewhoffman commented Jul 29, 2024

Script to interpolate existing MPAS-Ocean output files to a MALI mesh to be used to force standalone MALI simulations.

[details to be filled out]

To do

  • add z_bounds array
  • add 3d mask
  • fix xtime

alexolinhager and others added 26 commits May 6, 2024 14:19
Creates new script that interpolates MPAS-Ocean thermal forcing and sub
ice shelf melt rates to a MALI mesh for one way coupling. Still a work
in progress at this point
Implements the thermal forcing calculation, as well as reorganizes
script to object oriented. Further work is labeled with "<< TO DO >>:"
Finishes to-do list of interpolation script. Script capabilities are
now all complete, but script still needs to be tested and likely debugged
Two changes to get xtime written correctly:
* when the char array is generated, pad it to 64 characters
* fix a bug in that the return code to encoding.update was being
  assigned to xtime
Previous code was giving an error when landIceFreshwaterFlux exists.
minLevelCell does not exist in older meshes, which assumed it was 1.
…al attr

The global attribute version could sometimes have the value 'file'.
… files

There will likely be other files in output directories, so ensure we are
only working with the relevant ones.
* introduce start and end year options
* add time loop to main function
* create get_data function to retrieve needed data for each year
* adjust remap_mpas_to_mali to handle a year argument

A few comments:
* I’ve commented out writing of the mesh fields to keep file size down.
  This is unrelated to the handling of years and perhaps should be a command line option
* I had to adjust handling of various details of xarray data types to get this to work
* creation of the mapping file should be moved out of the time loop so it only occurs once!
This only needs to happen once.  This commit also changes some variable
names to be more precise.
This commit creates 2 masks about the extent of ocean data and moves
them to before interpolation so that MALI has access to the interpolated
mask values, rather than trying to construct them after the fact.  The
masks get interpolated in a separate file from the TF/melt data.

It is not yet clear if there will be a single mask definition that is
appropriate for all applications, so this approach forces the MALI user
to make a conscious decision about how to define the mask.

The two masks are:
* the entire ocean domain
* the open ocean
We want to do ver. before horiz interp to avoid any horiz/vert "mixing" due to
potential mpas-ocean hybrid coordinate.  Also, this should speed up ncremap
because the number of ismip6 vert levels is less than most ocean meshes.
After this change, “scalloping” in the open ocean is gone.
As this required substantial refactoring, there are a lot of related changes to
file handling and xarray objects.
@matthewhoffman
Copy link
Member Author

This is a replacement to #568 after branches diverged.

matthewhoffman and others added 2 commits July 30, 2024 10:57
Previous results had the vertical coordinate upside down.  These changes
correct that and are more careful about indexing conventions.
They had been reversed.

Co-authored-by: Alexander Hager <[email protected]>
This allows locations inside the ice shelf or below the bathymetry to be
identified on the MALI mesh.
* Use cavity Tf coefficients everywhere because we want TF appropriate
  for cavities (even if extrapolated from the open ocean)
* include landIcePressure in the Tf calculation
Copy link

@irenavankova irenavankova left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes make sense and the outputs (shared on slack) look physically reasonable.

@matthewhoffman matthewhoffman force-pushed the interpolate_mpasOcean_to_mali branch from 2ad751b to adce947 Compare November 21, 2024 06:02
This is a mask on the MALI mesh with the ISMIP6-ocean vertical
coordinate that indicates where valid MPAS-Ocean data exists (including
inside cavities).

To support this, a notable change is that nan is no longer inserted in
the TF field outside of the valid range.  Instead data is vertically
extrapolated and one should rely on orig3dOceanMask to identify where
the TF data can be used.
@xylar
Copy link
Collaborator

xylar commented Nov 21, 2024

The fix looks good to me, too.

Now that the year loop has been moved to the main driver, the time
averaging function can be simplified to only handle the single case of
time-averaging one year.  The year loop had to be moved to the main
driver to avoid running out of memory when processing many years.

Note there still is code in the function for the case of not
time-averaging.  The non-time-averaged case cannot currently be handled
by the script, and this is left as a placeholder until later when the
driver is restructured to support non-time-averaging.
This commit changes the threshold for overlap between an MPAS-Ocean grid
cell and a MALI grid cell for retaining interpolated values from 0.99 to
1.0.  It also fills all locations that don't have valid data with nan
instead of extrapolating, making it easier to see what was intentionally
interpolated and what wasn't.
With vectorization, this function goes from
243.6 to 2.5 seconds for a single call on the v2.1 SORRM mesh.

I confirmed the output looks the same as before but speckling in TF is
now gone.
@matthewhoffman matthewhoffman force-pushed the interpolate_mpasOcean_to_mali branch from 9a1a241 to 672a159 Compare November 27, 2024 21:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants