-
Notifications
You must be signed in to change notification settings - Fork 65
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
matthewhoffman
wants to merge
38
commits into
MPAS-Dev:master
Choose a base branch
from
matthewhoffman:interpolate_mpasOcean_to_mali
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Tool for interpolating MPAS-Ocean output to MALI for forcing standalone simulations #577
matthewhoffman
wants to merge
38
commits into
MPAS-Dev:master
from
matthewhoffman:interpolate_mpasOcean_to_mali
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
This is a replacement to #568 after branches diverged. |
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
There was a problem hiding this 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
force-pushed
the
interpolate_mpasOcean_to_mali
branch
from
November 21, 2024 06:02
2ad751b
to
adce947
Compare
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.
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
force-pushed
the
interpolate_mpasOcean_to_mali
branch
from
November 27, 2024 21:54
9a1a241
to
672a159
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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