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

ExtData capability in GEOSldas #210

Open
gmao-rreichle opened this issue May 6, 2020 · 4 comments
Open

ExtData capability in GEOSldas #210

gmao-rreichle opened this issue May 6, 2020 · 4 comments

Comments

@gmao-rreichle
Copy link
Contributor

@gmao-rreichle received an email from @smahanam about ExtData capability in GEOSldas. The fact that ExtData does not work for EASE grids makes it difficult to use ExtData in GEOSldas at this time. @gmao-rreichle opened this issue as a reminder that this needs to be addressed eventually.

cc: @weiyuan-jiang @smahanam @bena-nasa


From: Sarith Mahanama sarith.mahanama@ssaihq.com
Mon 04-May-20 8:00 AM
Hi Rolf/Weiyuan,

I made modifications to GEOS_LdasGridComp.F90 to add ExtData capability to GEOSldas. It now does what I expect my modifications do. I chatted with Ben last Friday and he reviewed, he believes I have got my coding correct.

This is just for your information, I made this modification for me to do some offline tests. I'm sure CATCHCN will benefit from this capability one day - like prescribing CO2 or nitrogen deposits (they often do that kind of science experiments).

One caveat though, until an EASE grid factory added to GEOSldas, this does not work with EASE grids. It works fine with CF and old FV grids.

FYI: feature/SM_modisdvg is my branch
[...]

@smahanam
Copy link

smahanam commented May 6, 2020

https://gmao.gsfc.nasa.gov/gmaoftp/sarith/modis_lai_geosldas.jpg

Comparison of middle and bottom panels show ExtData implementation in GEOSldas works fine on the CF180. After your email, @bena-nasa asked a lot of questions about EASE grid transformation, I provided a sample fortan program, by the way I do have convert_easev2.F90 module in Shared/Raster, I am sure it must be available somewhere
EASE grid factory will need that. module. Talk to @bena-nasa

@gmao-rreichle
Copy link
Contributor Author

work on EASE grid in ExtData still in progress...

@gmao-rreichle
Copy link
Contributor Author

Updates from Sarith and Ben:

cc: @weiyuan-jiang


From: Sarith
Date: Friday, July 10, 2020 at 5:24 PM
Subject: GEOSldas ExtData : feature/SM_modisdvg

Hi Rolf,

Above branch is good to import fields from ExtData files. Middle and bottom panels in below 2 examples are LAI output from GEOSldas (middle) and the “MODIS_LAI” data field in the ExtData file (bottom) - Note that ExtData input grid resolution is 0.5 lat/lon.

CF180 example:
https://gmao.gsfc.nasa.gov/gmaoftp/sarith/modis_lai_geosldas.jpg

SMAP_EASEv2_M36 example:
https://gmao.gsfc.nasa.gov/gmaoftp/sarith/MODIS_DVG/modis_lai_geosldas_m36.jpg

It turned out my note “One caveat though, until an EASE grid factory added to GEOSldas, this does not work with EASE grids" in the Github issue is incorrect. EASE grids failed because there was a bug in GEOS_LdasGridComp.F90. There are 2 call ease_inverse lines around lines 480-490 in the ‘develop’ version of GEOS_LdasGridComp.F90. The bug is that lat/lon output from those calls should be converted to radians to get grid ESMF grid lat/lon correct.

Currently, GEOSldas treats EASE as a LatLon grid by setting GEOSldas.GRID_TYPE: LatLon for EASE grids and ExtData transformation works as it is with the LatLon assumption (see above maps).

Ben wrote a ESMF_EASEGridFactory, when we started implementing this module, Ben found the bug and said it was the reason EASE grid transformation for hasn’t worked for me. I did not have to use the new ease grid factory.
As far as I am concerned, GEOSldas modifications in feature/SM_modisdvg is good enough for my work and to import fields from ExtData files in general.

Ben believes it is still good to have a designated grid factory for EASE grids. If we implement the ease grid factory, we need to move easeV2_convert.F90 module to MAPL. GEOSldas and Shared/Raster also use the same module.
[..]

Thanks, Sarith


From: Ben
Mon 13-Jul-20 09:25

Just to add my 2 cents to this for everyone’s clarification (weiyan is familiar with all this). When Sarith asked for help, I did not fully appreciate the full picture and suggested the ease grid factory as anything using ESFM regridding (used by ExtData) needs to go through our factory mechanism.

The basic idea with these factories is that we have an abstract class that lives in MAPL that defines standardized interfaces for constructing the grids either by explicitly passing parameters to a function or through an ESMF config file. Then the actual factories make use of OO-fortran and are extensions of this abstract class, we currently have ones for lat-lon, cubed-sphere, and the tripolar grid. We then have a grid manager that you can use to remember what grids have been created.

What I did not realized at first is that looking at what LDAS does, it looks like you do create a Lat-Lon grid with our factory mechanism, but then overwrite the coordinates with the ones for the ease grid in the actual LDAS gridcomp.

Sarith was trying to import items from a file to fields created on the ldas grid comp which uses this lat-lon, turned ease grid. The ESMF regridders used by ExtData make an assumption the coordinates are in Radians so everybody using them needs to be on the same page as well as having all the grids be made by our grid factories.

Since you are already using the machinery in MAPL to create the grid, having a dedicated ease grid factory makes sense from a code clarity standpoint. The factory can create the grid with the proper coordinates and mark it as an ease grid, distinct from the lat-lon, the ldasgridcomp would not have to bother with overwriting the coordinates, they would come from the factory with the correct values. In addition if you want to do any sort of conservative regridding you need to define the cell corners which means with what is being done how, you have 2 sets of coordinates to overwrite in the grid comp if you are defining the coordinates there. Finally if you ever want another utility to make use of this, the ease grid is nicely defined by one call. The factory does not even need to live in MAPL since I assume you would want control over it as it looks like the generation of the coordinates involves lots of predefind constants for example. Since the factory is an extension of the a base class it can live in another repository.

@gmao-rreichle
Copy link
Contributor Author

Applied bug fix for lat/lon degree-to-radians conversion in pull request #277.
@weiyuan-jiang will look further into development and use of EASE grid factory in GEOSldas.
The GMAO modeling group needs to chime in on the corresponding GEOS GCM GridComp branch ("feature/SM_modisdvg").

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

2 participants