hytest-org / hytest

https://hytest-org.github.io/hytest/
22 stars 13 forks source link

CONUS404 and CONUS404-PGW on slightly different grids #559

Open aputman-usgs opened 1 month ago

aputman-usgs commented 1 month ago

Hi,

I'm writing to ask if it is expected behavior that CONUS404 and CONUS404-PGW are on slightly different grids. I am accessing both on Hovenweep as follows:

url = 'https://raw.githubusercontent.com/hytest-org/hytest/main/dataset_catalog/hytest_intake_catalog.yml'
dataset_pgw_str = 'conus404-pgw-hourly-onprem-hw'
dataset_ctl_str = 'conus404-hourly-onprem-hw'
hytest_cat = intake.open_catalog(url)
conus404cat = intake.open_catalog(hytest_cat['conus404-catalog'].path)
conus404_ctl = conus404cat[dataset_ctl_str].to_dask()
conus404_pgw = conus404cat[dataset_pgw_str].to_dask()

The datasets also have different crs info so it's hard to check if they are on the same crs. Are they on the same crs? Can you point me to any guidance on this? Thank you!

pnorton-usgs commented 1 month ago

@aputman-usgs - I took a look that these two products. They are on the same grid and while the two crs entries have different attributes, they do represent the same geospatial information. I've replaced the crs variable in CONUS404-PGW so it has the identical information as CONUS404.

@amsnyder Could you transfer the updated .zmetadata file for CONUS404-PGW to the OSN-POD?

aputman-usgs commented 1 month ago

Hey Parker - thanks for the clarification and the update.

amsnyder commented 1 month ago

Thanks @pnorton-usgs - could you updated your zarr processing scripts to reflect the changes too? I am pushing the data to the OSN pod now...will close this out once the data transfer is finished.

amsnyder commented 1 month ago

Also - does the wrfxtrm zarr need updated? I didn't see any changes to .zmetadata when I pushed the data sync

aputman-usgs commented 1 month ago

Hi again,

Today when I loaded the datasets (as above) I double checked whether the crs_wkt, x, y, lat, and lon values for the two datasets were identical or not. The crs match now due to your updates (thanks!), and the two datasets have the same number of grid cells (x=1367, y=1015, which is the same as before), as well as identical lats and lons. However, it still seems like the values for x and y are slightly offset:

{ABB77239-21F5-484A-966C-338E4AB16B9A}

Is this still expected behavior? seems like if the crs are the same, and the lats and lons are the same, the x and y indices should also match between the datasets? or is there something I'm misunderstanding?

pnorton-usgs commented 4 weeks ago

@aputman-usgs I have a vague recollection of dealing with this for the original CONUS404. I'll go dig through my notes and see what I can find.

pnorton-usgs commented 4 weeks ago

@aputman-usgs - Try it again and see if they match properly now.

aputman-usgs commented 4 weeks ago

Yes- they do. Same script shows:

{F3052641-827B-4F92-9FE8-9ACE515F93B3}

TY!

pnorton-usgs commented 4 weeks ago

@amsnyder - CONUS404-PGW_hourly and CONUS404-PGW_xtrm will need to have the crs, x, and y variables transferred to the OSN-POD along with their respective .zmetadata files. I have updated both of these dataset with the corrected x and y projected coordinates and recreated the crs for them.

This was something that was done after-the-fact with prior workflows. I need to update the source WRF constants netCDF file (which is used by the processing workflows) with these updated variables so this does not happen in the future.

amsnyder commented 4 weeks ago

Thank you @pnorton-usgs! @aputnam, I pushed those updates to the OSN pod - please let me know if you see any other discrepancies

aputman-usgs commented 4 weeks ago

will do. Thanks!