Vapor 3.2 doesn't support WRF-Fire "real" cases

[adamk0]

Describe the bug

In the new 3.2 version mouse navigation, such as zoom in/out that worked with the hold right click and vertical mouse movement stopped working. Also, WRF netcdf files are not rendered correctly. The Z axis is stretched and the lat/lon is not processed correctly judging by the way how the Earth background is displayed.

Helpful additional information (Please click check boxes AFTER submitting ticket)

• [ ] Did VAPOR crash?
• [x ] Did you get wrong results?

Impact

• [x ] High - User productivity significantly degraded
• [ ] Medium - User productivity partially degraded
• [ ] Low - User productivity trivially degraded

To Reproduce

Steps to reproduce the behavior. For example:

1. Go to Import
2. Click on 'WRF_ARW'
3. Click on Renderers
4. Click new
5. Select Image

Vapor_32_OSX_error.vs3.zip

Expected behavior

As in version 3.1.

Attachments

Vapor 3.2

Vapor 3.1

Desktop

OS X 10.12.6 Vapor 3.2

Note: This problem is a regression that is limited to WRF-Fire model outputs with "real" (non-idealized) cases.

[clyne]

Can you provide a link to the data set in addition to the session (.vs3) file? Thanks!

[adamk0]

https://drive.google.com/file/d/1Ikh77UUl7pf41og0Pfl1KkW6tyHGM-PY/view?usp=sharing

[adamk0]

That is not the exact wrf output file used in the screenshots, but it is much smaller, and shows the same issue.

[clyne]

Thanks for providing the data. This is a bit of a conundrum and I'm not sure how to proceed. These data appear to have been generated by WRF-Fire (based on the presence of the FXLONG/FXLAT coordinate variables). According to @nmoisseeva, who reported a problem with WRF-Fire outputs in #801, the outputs may be from idealized runs in which case:

This is a simulation using WRF-SFIRE (based on model version 3.4) configured in idealized large-eddy simulation mode. It contains the main grid on XLAT XLONG (in meters, though wrf stores the data with units of degrees), and a fire subgrid on FXLAT and FXLONG (similarly in meters).

However, in @adamk0 case the data are not idealized, and XLAT and XLONG are in degrees as expected. The problem is there does not appear to be any way to determine if a 3.4 WRF Fire simulation is idealized or not. I.e. there is no way to determine if XLONG/XLAT are in meters or in degrees.

Any thoughts from @adamk0 or @nmoisseeva on how to resolve this would be welcome.

thanks!

[adamk0]

That is true, and quite unfortunate that the XLAT and XLONG variables do not carry proper units. However, I think it should be possible to identify the idealized cases. One way of doing that is by looking at the projection variables encoded in the global file attributes: CEN_LAT = 0.f ; CEN_LON = 0.f ; TRUELAT1 = 0.f ; TRUELAT2 = 0.f ; Values of zero would typically indicate an idealized case.

An alternative method could base on the values of DX and DY attribute compared to the X and Y mesh sizes derived from XLAT and XLONG. For real cases, there will be an order of magnitude difference between the mesh size in degrees compared to meters. For idealized cases, they should generally match.

[nmoisseeva]

My suggestion would be the same as Adam’s, i.e. checking for realistic coordinate values. I believe similar logic had to be added to previous version of Vapor (2.6?). https://sourceforge.net/p/vapor/bugs/1259/ Maybe you’d be able to recycle some of the existing code.

On Feb 7, 2020, at 4:13 PM, Adam Kochanski notifications@github.com<mailto:notifications@github.com> wrote:

That is true, and quite unfortunate that the XLAT and XLONG variables do not carry proper units. However, I think it should be possible to identify the idealized cases. One way of doing that is by looking at the projection variables encoded in the global file attributes: CEN_LAT = 0.f ; CEN_LON = 0.f ; TRUELAT1 = 0.f ; TRUELAT2 = 0.f ; Values of zero would typically indicate an idealized case.

An alternative method could base on the values of DX and DY attribute compared to the X and Y mesh sizes derived from XLAT and XLONG. For real cases, there will be an order of magnitude difference between the mesh size in degrees compared to meters. For idealized cases, they should generally match.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/NCAR/VAPOR/issues/2215?email_source=notifications&email_token=ABKNM5AE4WY5WRHNUU2JCMDRBX2JXA5CNFSM4KQVWH52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELFBQZA#issuecomment-583669860, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABKNM5H74AH5K4YIEHCG6MDRBX2JXANCNFSM4KQVWH5Q.

[clyne]

@nmoisseeva In the example data set you provided the XLONG and XLAT coordinate variables were in meters, but despite being labeled incorrectly were otherwise valid. Is this generally true of all idealized WRF-Fire simulations? I.e. XLONG and XLAT contain valid coordinates in units of meters?

[adamk0]

Yes, that is correct. XLAT and XLONG are valid coordinates, but either in meters (in idealized cases) or degrees (in real cases).

[clyne]

Thanks. We'll see if we can come up with something that works better. FYI we're moving to a continuous release model so you should not have to wait for the next "stability" release to get the changes.

[adamk0]

Great! Thank you.

One other question, not directly related to this issue. Do you think it would be possible at some point to visualize in Vapor 2D fire variables specified on the refined fire mesh, defined by FXLAT and FXLONG?

[clyne]

Well the good news is that is already supported.