search

NCAR / VAPOR

VAPOR is the Visualization and Analysis Platform for Ocean, Atmosphere, and Solar Researchers
https://www.vapor.ucar.edu/
BSD 3-Clause "New" or "Revised" License
179 stars 49 forks source link

WRF-CHEM not reading X extents correctly #3301

Closed sgpearse closed 6 months ago

sgpearse commented 1 year ago

To reproduce: 1) Import the WRF-CHEM file at /glade/p/cisl/vast/vapor/Bugs/3301 2) Note the X extents range from -180 to -180

Note that ncdump -v XLONG produces reasonable values for the X coordinate.

clyne commented 1 year ago

/glade/p/cisl/vast/vapor/Bugs/3301 is an empty directory.

sgpearse commented 1 year ago

Sorry about that. Directory updated.

clyne commented 1 year ago

The reason that invalid coordinates are being generated is because the STAND_LON global attribute in the WRF file appears to be initialized to a nonsense value: 1.e+20f. The STAND_LON attribute is use to set the lon_0 parameter for the PROJ format string for the Mercator projection. See here. The value is intended to specify the longitude of the projection center in degrees. Typically this value is inside of the range of values for XLON. See Katrina as an example.

As an aside, supporting map projections in VAPOR is inherently problematic and may not off much or any value to the user. They are a legacy from on geographic coordinates were first introduced in VAPOR in order to support WRF data sets, which include map projection information. However, very few other geoscience models that I'm aware of include map projections in their outputs. In the general case VAPOR fabricates a projection transform using the Cylindrical Equidistant projection, which is really just a scaling of lat and lon by a constant value to go from degrees to meters.

Long story, short: at some point it might be worth considering making the map projection for horizontal coordinates optional. I.e. use degrees as the unit for horizontal coordinates. Ditto for always trying to transform the vertical coordinates from whatever the native coordinate system in the model uses to 'meters above the ground'. Both of these transforms (for vertical and horizontal) were done in an attempt to get everything in meters so that flow advection calculations make sense.

StasJ commented 1 year ago

As John mentioned, this is due to malformed metadata. Potential solution would be to provide an option to disable dataset projections.

sgpearse commented 1 year ago

Potentially related to better issuance of warnings, IE #3405