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

Change grid_type = 'setmask' to use kmt_type instead (NUOPC / CMEPS) #805

Closed
apcraig opened this issue Dec 8, 2022 · 10 comments
Closed

Comments

@apcraig
Copy link
Contributor

apcraig commented Dec 8, 2022

This came from #660.

@dabail10
Copy link
Contributor

dabail10 commented Dec 8, 2022

This is tricky, and I would like some discussion about this. The logic here is that when we are in prescribed ice mode, we want to read the grid and mask information from the mesh file and not from the "grid/kmt" file. So, this is not just kmt. So, maybe the string is not clear. Maybe it should be 'setgrid'? Or 'meshgrid'? Otherwise if we are not in prescribed mode, we read the grid and kmt file and check the lat/lon/mask against the mesh file.

@dabail10
Copy link
Contributor

Thoughts on this? @apcraig @eclare108213 @DeniseWorthen

@DeniseWorthen
Copy link
Contributor

@dabail10 I'm not sure this change would impact us since we always run grid_type='tripole'. For UFS, we don't have a prescribed ice mode; like you say, we read the grid and kmt file and check it is consistent w/ the mesh file.

@apcraig
Copy link
Contributor Author

apcraig commented Dec 14, 2022

Are you proposing we add a mode where instead of grid/kmt, CICE could read a mesh file? I don't think we want to use grid_type for that. grid_type still needs to be dispaced or tripole or whatever, even if a mesh is read. Lets say a mesh could also be used from non-prescribed cases, that's how we'd want it to be able to work. I would use grid_format and set it to meshnc or something like it. So, grid_file sets the mesh filename, grid_format=meshnc, grid_type is still as now. Would that work?

@dabail10
Copy link
Contributor

I like this idea.

@DeniseWorthen
Copy link
Contributor

We create the mesh for MOM6/CICE6 by first creating a SCRIP file (from the MOM6 supergrid) and converting that to an ESMF mesh using ESMC_SCRIP2unstruc. Similarly, for a rectilinear global or regional grid, it is trivial to create a SCRIP file using netCDF operators. So, would it be more general to allow the reading of a SCRIP file rather than a mesh file? In either case (reading SCRIP or mesh), you need the mask (kmt) information added to the file or else you'll still need to have the kmt file read.

@dabail10
Copy link
Contributor

This brings up another issue that is out there. We really need to add an option to read the MOM6 supergrid directly instead of requiring this conversion to kmt/grid files. I don't think we want to add a capability to read SCRIP grid files. The mesh files are the new NUOPC requirement. As you highlighted, when we run in prescribed ice mode, we are using only the mesh file and do not use the kmt/grid files.

@apcraig
Copy link
Contributor Author

apcraig commented Dec 15, 2022

That all sounds reasonable. We can implement whatever we need and can add quite a bit of flexibility. We could add

  • mesh including kmt
  • mesh + separate kmt file
  • scrip + kmt file
  • mom supergrid

and some additional options for prescribed grid if that's a special case. You just need to decide what you want to support. They could all be added via various grid_format settings.

@DeniseWorthen
Copy link
Contributor

I'm a little confused why this is listed as a NUOPC/CMEPS issue vs a general issue about possible file formats CICE itself could read to create the grid.

@dabail10
Copy link
Contributor

I think it started out that way because 'setmask' was a NUOPC/CMEPS issue only. However, I agree that it is kind of growing beyond this. I am going to submit a PR to fix this issue and then we can start another about more general grid/kmt handling.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants