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

New DOCN mode to ingest multi level ocean fields to send to CISM #273

Open
mvertens opened this issue Apr 15, 2024 · 10 comments
Open

New DOCN mode to ingest multi level ocean fields to send to CISM #273

mvertens opened this issue Apr 15, 2024 · 10 comments
Assignees
Labels
enhancement New feature or request

Comments

@mvertens
Copy link
Collaborator

mvertens commented Apr 15, 2024

In CISM, subroutine glad_gcm (in glad_main.F90) is set up to receive two 3D ocean fields on the CISM grid:

real(dp),dimension(:,:,:),intent(in) :: salinity ! input ocean salinity (g/kg)
real(dp),dimension(:,:,:),intent(in) :: tocn ! input ocean temperature (deg K)

The first dimension is the ocean level, and the second and third are the horizontal dimensions. CISM also has an internal ocean_data derived type that includes an integer nzocn (the number of ocean levels) and a 1D array zocn (the ocean elevation in

Should the input ocean temperature should be the potential temperature rather than the in situ temperature?

To compute sub-shelf melting internally, CISM needs a 3D variable called thermal_forcing (TF), which depends on ocean T, S, and depth. Each time glad_gcm is called, CISM uses T and S at each level to compute TF. The resulting TF is accumulated and averaged over a mass balance time step, like the SMB and temperature fields (qsmb and tsfc) from the land model.

In addition the mediator also needs the ocean masks (i.e. bathymetry) at the sub-grid levels passed.
So in short, a data ocean model should pass 3D T, S and mask fields to the mediator. The mediator should regrid these fields to the CISM grid(s), inserting a fill value where the ocean and ice-sheet grids don't overlap. And at some point during initialization, CISM needs to be told how many ocean levels there are and where they're located.

@whlipscomb - please add more details that you think are necessary. Can you also point me to a dataset that would have these fields so that I can start prototyping this.

@mvertens mvertens self-assigned this Apr 15, 2024
@mvertens mvertens added the enhancement New feature or request label Apr 15, 2024
@whlipscomb
Copy link

@mvertens — I think this is a good level of detail for now.

@Katetc asked Gustavo ocean datasets. In an email, Gustavo suggests:

One option is to use the forced ocean/sea ice CESM2 simulation from OMIP2.
The CESM OMIP2 output can be found at:
/glade/collections/cmip/CMIP6/OMIP/NCAR/CESM2/omip2/r1i1p1f1

@gustavo-marques
Copy link

@mvertens:
I am thinking of how this capability can be extended to work with MOM6 output, which might have variable vertical resolution. If the ocean model sends a 3D ocean thickness to the mediator, then it would be possible to remap T and S to the CISM grid regardless of the vertical coordinate.

@whlipscomb
Copy link

@mvertens and @gustavo-marques: Just to confirm: CISM needs a depth coordinate associated with each field value. For the case of variable vertical ocean resolution, the simplest approach (from CISM's point of view) might be to remap all ocean values to a common set of vertical levels (e.g., values spaced every 60 m between 0 and 1800 m). But this isn't strictly necessary. As long as CISM knows the full set of depths in each ocean column, the model can interpolate linearly between adjacent depths to get the value it needs at the base of the ice shelf.

@mvertens
Copy link
Collaborator Author

mvertens commented Apr 19, 2024

@gustavo-marques @whlipscomb - I like the approach that @whlipscomb is suggesting. This would imply that the ocean is always sending 30 levels of T and S to the mediator at fixed heights. This vertical interpolation could be done in the ocean cap.
On the other hand - thinking about this some more - if we adopt this - then vertical interpolation would have to be implemented in the mom cap, docn, and pop - and in docn be able to handle variable vertical resolutions. Whereas just implementing this in cism would reduce the need for the duplication of vertical interpolations. @gustavo-marques - what do you think is the better approach? @gustavo-marques - I am assuming that the vertical resolution (even a variable one) is not time evolving - is that correct?

@mvertens
Copy link
Collaborator Author

@gustavo-marques @whlipscomb - I now have a docn stream that ingests both the salinity and the potential temperature from the OMIP data and sends it to the mediator. I can plot mediator history files that have effectively the same profiles at each vertical level as in the OMIP datasets that I'm using. So at this point we need to decide how to handle the vertical levels based on the discussion above.

@mnlevy1981
Copy link
Contributor

On the other hand - thinking about this some more - if we adopt this - then vertical interpolation would have to be implemented in the mom cap, docn, and pop - and in docn be able to handle variable vertical resolutions.

@mvertens My take on @whlipscomb's suggestion is that the restriction should be "the ocean must pass 3D fields on a static vertical grid [identical across columns and not changing in time]" and then CISM can interpolate from whatever the ocean grid happens to be to the levels it wants data on. The MOM cap will need to interpolate because our configuration of MOM uses a vertical grid that varies both spatially and temporally, but MOM already has routines available to do this interpolation. The POP grid is invariant and presumably we can generate datasets for DOCN on a static vertical grid as well so I don't think POP or DOCN need to do any interpolation, they just need to tell CISM what their [static] vertical grids are so CISM can interpolate if necessary.

@mvertens
Copy link
Collaborator Author

@mnlevy1981 - thanks. This is super helpful. So basically what I am concluding - what we can assume is that data passed to CISM from the ocean will be on a static vertical grid - across columns and not changing in time. So what CISM needs is simply the vertical levels on that grid. Does that make sense?

@mnlevy1981
Copy link
Contributor

mnlevy1981 commented Apr 19, 2024

@mvertens That does make sense! A thought I just had, though -- should the mediator be responsible for the vertical interpolation? I.e.

  1. Ocean tells the mediator what vertical levels it will be passing data on [static levels, so MOM6 will interpolate from its time-varying levels to some grid before sending data to MED]
  2. CISM tells the mediator what vertical levels it wants to receive data on
  3. Data flow is OCN -> MED, MED interpolates, MED -> CISM

That might be a can of worms...

@mvertens
Copy link
Collaborator Author

I think this would be the most difficult implementation. The mediator is already quite complex and if possible we want to reduce the permutations of what it needs to do. It seems to be that since this capability is already available in MOM and in CISM there is no need to introduce it in the mediator.

@whlipscomb
Copy link

@mvertens and @mnlevy1981 — Just to clarify: we can be flexible with CISM. We'll want a fixed number of ocean levels (say, 30) for every CISM grid point, but if necessary (e.g., if it's hard to do the vertical interpolation consistently in the other components), we could work with levels whose depths vary spatially and/or in time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants