Add a class to help manage and interpolate static datasets#637
Add a class to help manage and interpolate static datasets#637mgduda merged 4 commits intoMPAS-Dev:developfrom
Conversation
There was a problem hiding this comment.
When testing this function, I was a bit confused by the range of latitudes that it produced. If I grabbed the most north east tile mgr % get_tile(5. * pi, 2.0 * pi, tile) some of the range of latitudes produced by tile_to_latlon were greater than .5 * pi, and I'm not sure exactly why that would be.
A first thought is that this is because known_lat is not equal to exactly 5. * -pi. @mgduda, is that correct?
There was a problem hiding this comment.
Typically, the known_lat and known_lon values for a dataset give the coordinates of the center of a pixel. So if the boundary of the pixel extends to, e.g., the South Pole, then the pixel's center coordinates will be greater than -Pi/2.
There was a problem hiding this comment.
I just left a comment for lines 642 and 643 that may be related.
3b49edf to
cd6417d
Compare
|
@mgduda thanks for the primarily review. I just pushed an update fixing the warnings and other issues you found. |
e0b1a3b to
fe0709a
Compare
|
@mgduda, I have just pushed an update to this branch that includes the changes above. I have pulled them out of 469c271 and moved them into 9111cfb and I have added the |
fe0709a to
40b0e09
Compare
There was a problem hiding this comment.
In lines 692 and 693, I think int should be nint.
There was a problem hiding this comment.
Trying out nint (as well as floor and ceiling) will cause the geotile_manager to generate tile names that don't exist for the dataset. Although, I'm not sure if this behavior is correct or not. For instance the geotile_manager will generate the tile 42001-43200.21601-22800 for the point: (1.57080, 0.00000). The calculation is:
* lat = 90.0
* (lat - known_lat) / dx = 21599.5059
* nint(21599.5059) = 21600
However, I don't think this is correct, as the very last tile contains the 21600 pixel: 42001-43200.20401-21600.
So perhaps the tile filename generation is incorrect? Perhaps off by one?
There was a problem hiding this comment.
Are the pixel coordinates that are returned by mpas_geotile_mgr_latlon_to_pixel supposed to be 0-based or 1-based?
There was a problem hiding this comment.
Let's assume that every latitude value in the interval [-Pi/2, Pi/2] is uniquely mapped to a j-index. Then for the center latitude, lat, of a given pixel, we can either say that all latitudes in the interval [lat - Pi/2, lat + Pi/2) map to that pixel, or that all latitudes in the interval (lat - Pi/2, lat + Pi/2] map to that pixel. Regardless of which we choose, there will always be a pole, i.e., -Pi/2 or Pi/2 that is not mapped to some j-index and that therefore needs special treatment.
40b0e09 to
5c48f9f
Compare
|
Okay @mgduda, I just pushed an update that addresses your above comments, except for changes on line 692 and 693, which I left a comment on! |
5c48f9f to
bab82e2
Compare
|
@mgduda I have just pushed an update to this branch which adds a default value to |
bab82e2 to
fc4248b
Compare
|
It looks like the changes to |
There was a problem hiding this comment.
Since pixel_y is declared as an integer, should 0.0 be changed to 0?
fc4248b to
a16d043
Compare
|
@mgduda okay, I have just pushed an update that resolves rounding pixel_y values, changes 0.0 -> 0 and reworked the commit history to remove commit 04e88f0. Let me know if you see anything else. |
There was a problem hiding this comment.
Should pixel_y be mgr % pixel_ny on the r.h.s.?
There was a problem hiding this comment.
I think you're right. I'll push an update.
a16d043 to
d0cdeb3
Compare
To help with future efforts in parallelizing the interpolation of static fields, a class has been added, mpas_geotile_type, which helps with reading and storing static datasets. As well, it contains routines for converting pixel coordinates into latitude and longitude. Currently, the mpas_geotile_type is not being used anywhere within the init_atmosphere core, it is only being compiled.
The pixel_to_latlon function of the mpas_geotile_manager is currently not planned to be used in the parallelization interpolation of static fields, so it is being removed.
This commit adds a function to the mpas_geotile_manager with a function to convert latitude, longitude coordinates into Cartesian coordinates, given a radius.
In previous commits mpas_geotile_manager.F was being compiled, but there was not a target for it in the Makefile. This meant that there was no dependencies for mpas_geotile_manager.F which would cause its compilation to fail occasionally when the mpas_geotile_manager.F was compiled before mpas_parse_geoindex.F.
d0cdeb3 to
a1160b8
Compare
|
@mgduda Okay, I just pushed an update! |
mgduda
left a comment
There was a problem hiding this comment.
I think we're ready to merge!
Update MPAS-Source: COMPASS and Documentation files This PRi brings in a new mpas-source submdoule with changes only to the ocean core. It updates files unrelated to the E3SM forward model, including: * Move load_compass_env.sh to the ocean dir (MPAS-Dev/MPAS-Model#618); * Update ISOMIP+ docs, including tutorial for Ocean0 on LANL IC (MPAS-Dev/MPAS-Model#653); * Fix path to docs in Travis CI (MPAS-Dev/MPAS-Model#644); * atmosphere core init changes (MPAS-Dev/MPAS-Model#637); * New Mesh: WC14to60kmL60E3SMv2r03 (MPAS-Dev/MPAS-Model#628); * Fix ISOMIP+ viz scripts (MPAS-Dev/MPAS-Model#642); * Add support for custom critical passages and land blockages (MPAS-Dev/MPAS-Model#586); and * New Mesh: WC12to60kmL60E3SMv2r01 (MPAS-Dev/MPAS-Model#555) [BFB]
Update MPAS-Source: COMPASS and Documentation files This PR brings in a new mpas-source submdoule with changes only to the ocean core. It updates files unrelated to the E3SM forward model, including: * Move load_compass_env.sh to the ocean dir (MPAS-Dev/MPAS-Model#618); * Update ISOMIP+ docs, including tutorial for Ocean0 on LANL IC (MPAS-Dev/MPAS-Model#653); * Fix path to docs in Travis CI (MPAS-Dev/MPAS-Model#644); * atmosphere core init changes (MPAS-Dev/MPAS-Model#637); * New Mesh: WC14to60kmL60E3SMv2r03 (MPAS-Dev/MPAS-Model#628); * Fix ISOMIP+ viz scripts (MPAS-Dev/MPAS-Model#642); * Add support for custom critical passages and land blockages (MPAS-Dev/MPAS-Model#586); and * New Mesh: WC12to60kmL60E3SMv2r01 (MPAS-Dev/MPAS-Model#555) [BFB]
This merge adds a new module to the init_atmosphere core, mpas_geotile_manager, which contains a class, mpas_geotile_mgr_type, which can be used to help read, store and interpolate static fields. Currently, it is only being compiled, but in the future will be used to parallelize the interpolation of static fields.