Fire data for wrf-sfire

[llsalazar]

Good morning

Does running wrf-sfire need specific features for fuel and elevation data? Because we are having problems with our data that when converted and then processed with the geogrid, it shows meaningless

We have data with 8 bit

[janmandel]

Hi @llsalazar we are using static data including topography as described in https://wiki.openwfm.org/wiki/Running_WRF-SFIRE_with_real_data_in_the_WRFx_system#Get_static_data and geotiffs with 13 Anderson categories from landfire.gov. We do hear from users who run WRF-SFIRE with other data including in other countries so it is definitely not restricted to that, but I would expect it took them some troubleshooting.

@Fergui can you please comment?

Note: This thread is a continuation of #62

[llsalazar]

It is that we continue having the same problem with the fuel data. We've made some changes to our data but we couldn't fix it.I leave you a link where you can see our fire data in case you find an error that we have not been able to identify. https://drive.google.com/drive/folders/17Y6Tp_6juKRvWByLQ9h9XIRXns3oRIKA?usp=sharing

Thanks for your help

This is our geogrid.log geogrid.log

This is the error that shows us when running wrf.exe: SFIRE:reading emissions table for 13 fuel categories SFIRE:nfuel_cat( 1, 1)= 0 SFIRE:Possibly nfuel_cat is uninitialized on input SFIRE:nfuel_cat must between 1 and nfuel_cat= 13 SFIRE: or 14 and 100 for no fuel SFIRE:crash: set_fire_params: fuel category out of bounds -------------- FATAL CALLED --------------- FATAL CALLED FROM FILE: LINE: 204 crash: set_fire_params: fuel category out of bounds

This is our namelist.wps &share,, wrf_core = 'ARW',, max_dom = 3,, start_date = '2022-06-11_00:00:00','2022-06-11_00:00:00','2022-06-11_00:00:00' end_date = '2022-06-11_03:00:00','2022-06-11_03:00:00','2022-06-11_03:00:00' interval_seconds = 3600,, io_form_geogrid = 2,, opt_output_from_geogrid_path = '../geogrid/',, active_grid = .true.,.true.,.true.,, /,, ,, &geogrid,, parent_id = 1,1,2 parent_grid_ratio = 1,3,3 i_parent_start = 1,102,104 j_parent_start = 1,92,88 e_we = 297,283,229 e_sn = 267,253,235 geog_data_res = '.30s','.30s','.30s' dx = 5560,, dy = 5560,, map_proj = 'lambert',, ref_lat = 40.338,, ref_lon = -4.262,, truelat1 = 40.338,, truelat2 = 40.338,, stand_lon = -4.262,, geog_data_path = '../WPS_GEOG',, opt_geogrid_tbl_path = '../geogrid',, ref_x = 148.5,, ref_y = 133.5,, /,, ,, &ungrib,, out_format = 'WPS',, prefix = 'FILE',, /,, ,, &metgrid,, fg_name = 'FILE',, io_form_metgrid = 2,, opt_output_from_metgrid_path = '../metgrid/',, opt_metgrid_tbl_path = '../metgrid/',, /,,

[Fergui]

Hi @llsalazar, if you are using custom fuel categories, you will need to specify them in namelist.fire. Your GeoTIFF raster has values ranging from 0 to 15. For the default 13 Albini categories, the values should range from 1 to 14 (where 14 represents unburnable). The code is complaining because it finds values that are 0 and are outside the default range. If you need to do some conversions for some categories, you can change NFUEL_CAT options in wrfxpy here: https://github.com/openwfm/wrfxpy/blob/master/src/geo/var_wisdom.py

[llsalazar]

Good morning Angel Thanks for your answer

We changed the data as you recommended, but it has kept giving us the same error.

It calls our attention that when the geogrid processes the data geog processes NFUEL_CAT twice.

Once we have the geogrid outputs (the geo_met*) the NFUEL_CAT and ZSF data show a meaningless map, however the rest of the geog variables do show correctly. We changed our data to 16 bits, we changed the projection as well, and still we still get the same error.

I leave you a link with the data changes and the geogrid outputs in case you can see them and help us with our doubts, I would greatly appreciate it. https://drive.google.com/drive/u/0/folders/17Y6Tp_6juKRvWByLQ9h9XIRXns3oRIKA

Greetings

El lun, 3 abr 2023 a la(s) 19:01, Angel Farguell @.***) escribió:

Hi @llsalazar https://github.com/llsalazar, if you are using custom fuel categories, you will need to specify them in namelist.fire. Your GeoTIFF raster has values ranging from 0 to 15. For the default 13 Albini categories, the values should range from 1 to 14 (where 14 represents unburnable). The code is complaining because it finds values that are 0 and are outside of the default range.

— Reply to this email directly, view it on GitHub https://github.com/openwfm/WRF-SFIRE/issues/63#issuecomment-1494673466, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXZTCHTMSWEVVO5GRLTXETTW7L647ANCNFSM6AAAAAAWOKHB6Y . You are receiving this because you were mentioned.Message ID: @.***>

[Fergui]

Hi @llsalazar,

The geogrid processing the NFUEL_CAT twice is normal behavior. It shows the message two times because processing NFUEL_CAT requires two stages in the code.

I went ahead and used wrfxpy to convert your GeoTIFF files into the geogrid format, by applying these fuel translations: 15 -> 14 0 -> nearest neighbour interpolation

Then, I slightly modified your namelist.wps:

• Removed the opt options since they are optional
• Add the "subgrid_ratio_x = 1,1,20" and "subgrid_ratio_y = 1,1,20" in &share section

Running ./geogrid.exe in WPS using your namelist.wps slightly modified and the processed geogrid files, the final results are:

I discovered that the issue was probably related to the new version of pyproj. I am doing some modifications in the wrfxpy code to fix the issue, and you will be able to try again.

Note that your GeoTIFF file is not large enough to encompass your domain 3.

A new issue https://github.com/openwfm/wrfxpy/issues/70 is opened.

[llsalazar]

Thank you very much for your answer, we will take into account all the details that you indicate.

Regards

El mié, 5 abr 2023 a la(s) 20:59, Angel Farguell @.***) escribió:

Closed #63 https://github.com/openwfm/WRF-SFIRE/issues/63 as completed.

— Reply to this email directly, view it on GitHub https://github.com/openwfm/WRF-SFIRE/issues/63#event-8938429375, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXZTCHQPTMOD4MQSGFUXJ5DW7W6H3ANCNFSM6AAAAAAWOKHB6Y . You are receiving this because you were mentioned.Message ID: @.***>

[llsalazar]

Good morning Angel Farguell How can I know when you have the modifications in the wrfxpy code ready?

regards

El mié, 5 abr 2023 a la(s) 20:50, Angel Farguell @.***) escribió:

Hi @llsalazar https://github.com/llsalazar,

The geogrid processing the NFUEL_CAT twice is normal behavior. It shows the message two times because processing NFUEL_CAT requires two stages in the code.

I went ahead and used wrfxpy to convert your GeoTIFF files into the geogrid format, by applying these fuel translations: 15 -> 14 0 -> nearest neighbour interpolation

Then, I slightly modified your namelist.wps:

• Removed the opt options since they are optional
• Add the "subgrid_ratio_x = 1,1,20" and "subgrid_ratio_y = 1,1,20" in &share section

Running ./geogrid.exe in WPS using your namelist.wps slightly modified and the processed geogrid files, the final results are: [image: Screenshot 2023-04-05 at 12 48 23 PM] https://user-images.githubusercontent.com/9255649/230176470-36fc0622-2d8d-4a20-b65c-84e496579742.png [image: Screenshot 2023-04-05 at 12 48 33 PM] https://user-images.githubusercontent.com/9255649/230176486-ebcaa11b-4c37-433a-8e78-921c66ede9a8.png

I discovered that the issue was probably related to the new version of pyproj. I am doing some modifications in the wrfxpy code to fix the issue, and you will be able to try again.

Note that your GeoTIFF file is not large enough to encompass your domain 3.

— Reply to this email directly, view it on GitHub https://github.com/openwfm/WRF-SFIRE/issues/63#issuecomment-1497965362, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXZTCHVZRJXHXP3EUE5KQLLW7W5I7ANCNFSM6AAAAAAWOKHB6Y . You are receiving this because you were mentioned.Message ID: @.***>

[Fergui]

In my comment, I pointed to a new issue in wrfxpy that was closed last week: https://github.com/openwfm/wrfxpy/issues/70

[llsalazar]

Buenos días Muchas gracias por su ayuda, ya hemos logrado correr el modelo

El lun, 10 abr 2023 a la(s) 16:27, Angel Farguell @.***) escribió:

In my comment, I pointed to a new issue in wrfxpy that was closed last week: openwfm/wrfxpy#70 https://github.com/openwfm/wrfxpy/issues/70

— Reply to this email directly, view it on GitHub https://github.com/openwfm/WRF-SFIRE/issues/63#issuecomment-1501884920, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXZTCHT4LBGVTK7DQ7LH54TXAQKFVANCNFSM6AAAAAAWOKHB6Y . You are receiving this because you were mentioned.Message ID: @.***>