openwfm / wrf-sfire Goto Github PK

Replace atmosphere -> fire wind interpolation by mass-consistent approximation following the terrain.

in /glade/scratch/kochansk/WRF-SFIRE_4.2/wrf-sfire/test/em_real at 80eb347
copied to /glade/p/univ/ucud0004/jmandel/WRF-SFIRE_4.2_adam
module_fr_sfire_core at line 902 crash in internal check avoiding fall through in a sequence of if statements

Hi Dr. Mandel,

I have recently tried to run WRF-Chem-Fire by conducting ndown one-way nesting method since the turbulence scheme could be different for different domains. The domain setting for my case is 12km-4km-1km-200m. The fire model needs high resolution and the LES could be more reasonable for such resolution. While I receive the error message: crash: read_emissions_table: increase max_chem.

The fire model is totally fine when I run the WRF-Fire by one-way nesting. The WRF-Chem model can be also successfully finished under ndown one-way nesting method while the WRF-Chem-Fire model cannot. I do not think it is due to my namelist.fire_emissions or namelist.fire setting since I also tried an online one-way coupling by running 4 domains together and It works fine (#16 (comment)). Also, I tried to run the first two domains by online one-way nesting and run ndown to provide boundary and initial conditions to 1km domain. Then, I ran 1km and 200m together by online one-way nesting. The WRF-Fire-Chem can also be finished at this setting. Under these experiments, I think something wrong happens in the WRF-Fire-Chem model for real case. It seems I need to wrap the fire model in a parent domain to run WRF-Fire-Chem. Do you have any ideas for the error message?

Also, I have reported the WRF-Fire-Chem cannot print the emission or the fire information during the simulation (#43 (comment)). It seems the information is hidden when the fire model is in a daughter domain. When I run WRF-Fire by ndown nesting (I just have one domain for the fire simulation and the fire model in parent domain), the model shows the information. I guess the print information is only provided for ideal case or the ndown running (running WRF-Fire-Chem without nesting). Do you have any ideas for getting the emission or fire information when doing a nesting simulation?

I can provide all my input data for my real cases for checking: https://drive.google.com/drive/folders/1fTeuU1ZfY2y0KzHiDXHLg9tWQCHY6xq9?usp=sharing. If you have any requirements, please let me know.

Thanks,
Zongrun

Check if WRF-SFIRE-Chem works after the transition to WRF 4 and fix if needed. There will be differences in chem since we took it in and changes in chem we made long time ago...

The default is now fire_wind_log_interp = 1, which was fixed in #10
Previous default fire_wind_log_interp = 4 (interpolation to a fixed height and apply wind reduction factors) is obsolete and not parallel consistent #13.
Should we clean up the code that supports ire_wind_log_interp = 4 ? I do not quite understand the indexing there. This includes deleting variables uah and vah.

We do not want to make changes in WPS but real.exe should be easier. We need to have fxlong and fxlat for perimeter preprocessing in wrfinput. Running wrf-sfire to generate the first wrfout to get fxlong and fxlat from there is awkward.

Of course now we would have to check that fxlong and fxlat as computed inside SFIRE following #7 is the same.

Follow up on #10: Check the namelist.input options, data in namelist.fire, the defaults, and the wiki documentation.

Check if the increased halos from a70bf7c done in #10 in are really needed and reduce them if not.

When running option ifire=1, ROS is missing on wrfout files. Registry/registry.fire was modified from hr to r on https://github.com/openwfm/WRF-SFIRE/blob/master/Registry/registry.fire#L84. Instead, variable ROS_FRONT was defined to be written on wrfout files https://github.com/openwfm/WRF-SFIRE/blob/master/Registry/registry.fire#L87. However, fire_sfire1 package does not include ros_front variable.

copied to /glade/p/univ/ucud0004/jmandel/WRF-SFIRE-chem/test/em_inv_chem
SFIRE:git commit 60811b1
SFIRE:reading emissions table for 13 fuel categories
SFIRE:crash: set_fire_params: fuel category out of bounds

In a large restart run.

Some data sources have additional fuel categories such as 99 for no fuel. These cause run time errors since no fuel should be coded as no_fuel_cat=14 in namelist.fire

There are differences between the master branch and the wrf-fire-track/master branch for some of the test experiments within the test/em_fire directory. In the master branch, soft links to exe files are not always created and there are differences between the input_sounding, input_fc, and input_lu files that are found in the wrf-fire-track/master branch for the fireflux_small and two_fires experiments.

For testing purposes, the hill experiment has been run with identical settings in both the master and the wrf-fire-track/master branches. These runs may be found on the Kingspeak cluster on the following paths.

master:
/uufs/chpc.utah.edu/common/home/kochanski-group4/jhaley/wrf4/WRF-SFIRE/test/em_fire/hill_01
wrf-fire-track/master:
/uufs/chpc.utah.edu/common/home/kochanski-group4/jhaley/wrf3/WRF-SFIRE/wrfv2_fire/test/em_fire/hill_01

In branch dvm_branch, has prereq #6 #10

Check rh_fire and other fuel moisture variables in registry.fire and in check_size in phys/module_fr_sfire_driver.F.

WRF-SFIRE simulations sometimes crash because of a too large time step. That motivates the use of an adaptive time step for running fire-atmosphere simulations with WRF-SFIRE. The main parameters to control the adaptive time step are defined in the domains section and they are:

Parameter | Default | Definition
use_adaptive_time_step | .false. | T/F use adaptive time stepping, ARW only
step_to_output_time | .true. | if adaptive time stepping, T/F modify the time steps so that the exact history time is reached
target_cfl (max_dom) | 1.2,1.2 | vertical and horizontal CFL <= to this value implies no reason to reduce the time step, and to increase it
max_step_increase_pct (max_dom) | 5,51 | percentage of previous time step to increase, if the max(vert cfl, horiz cfl) <= target_cfl, then the time will increase by max_step_increase_pct
starting_time_step (max_dom) | -1,-1 | flag = -1 implies use 6 * dx (defined in start_em), starting_time_step = 100 means the starting time step
max_time_step (max_dom) | -1,-1 | flag = -1 implies max time step is 3 * starting_time_step, max_time_step = 100 means that the time step will not
min_time_step (max_dom) | -1,-1 | flag = -1 implies max time step is 0.5 * starting_time_step, min_time_step = 100 means that the time step will not
adaptation_domain | 1 | default, all fine grid domains adaptive dt driven by coarse-grid; 2 = Fine grid domain #2 determines the fundamental adaptive dt.

A WRF-SFIRE adaptive time step test was performed in Cheyenne: /glade/u/home/angelfc/project/WRFx/wrfxpy/wksp/wfc-adaptive-test
The results need to be tested and validated against the same simulation but without adaptive time step also in Cheyenne here: /glade/u/home/angelfc/project/WRFx/wrfxpy/wksp/wfc-from-web-2021-09-26_15-15-35-2021-09-26_12:00:00-48

Create a new option to generate ideal.exe from dyn_em/module_initialization_sfire.F that would not conflict with dyn_em/module_initialization_fire.F. Currently, dyn_em/module_initialization_fire.F serves both ifire=1 and ifire=2 but dyn_em/module_initialization_fire.F has dependencies elsewhere in the fire code. This would replace the conflict surface dyn_em/module_initialization_fire.F by a conflict surface in the build system.

Hi Dr. Mandel,
Is there a method to access the fire emissions when running the WRF-SFire with WRF-Chem? If not, what is the equation for online calculation for WRF-SFire? Is it fine to use the following equation to estimate?
For each fuel category
Emission_sub = fuel loading (fgi in namelist.fire) * consumed fraction (avg_fuel_frac: output from wrf-fire) * emission factor (factors in namelist.fire_emissions) * grid area
And the sum of emission for each fuel category is the total emission of the fire for a specific time step.
Thanks,
Zongrun

On the em_rxcadre case, the fire ignites but does not seem to progress. LFN looks too smooth. Check ideal cases first for proper fire progression and use of fuel data.

Partial revert of #12 to put the check back but with a smaller minimum size.

d059afe introduced new 3DTKE km_opt=5 which broke km_opt=2. This is a problem because km_opt=5 is is not compatible with some surface schemes.
To do:

1. tell WRF developers
2. fix and do pull request

Use the same vertical log interpolation of horizontal wind for input to Massman canopy wind parameterization and for interpolation to flame height.

For the PREEVENTS project.
Comments on WRF-SFIRE edits here, for the other side at UtahEFD/QES-Winds#2.

Error message:
SFIRE:WARNING:time step start:check_lfn_tign_ij: inconsistent state
crash: i,j= 3524, 771 lfn= 0.00000 >=0 tign= 3996.6665 < time_now= 3996.6667

Explanation: Location i,j on fire is defined as lfn<0, then tign is computed as tign(i,j)<time_now
But with perimeter ignition tign is given and lfn computed as lfn = time_now - tign

1. at time step start the time_now was just increased, should we even test for it
2. with unnormalized numbers rounded to zero in optimized build, it is possible that a<b but b-a = 0 though a and b would have to be very small
3. consistent messages - warning or crash

rsl.out.0112 in /glade/u/home/kochansk/scratch/WRF-SFIRE_4.2/wrf-sfire/test/em_real13_crash
using /glade/p/univ/ucud0004/jmandel/em_real13_crash

Define NFUEL_CAT fuel categories from LANDUSE categories in the sub-grid mesh. The LANDUSE categories are defined in WRF user guide and are later on processed in the code using LANDUSE.TBL. They can be easily included in the sub-grid mesh creating a new variable identical to LANDUSEF but adding subgrid=yes in GEOGRID.TBL. The last part that is missing is to generate a table to transform LANDUSE categories into NFUEL_CAT categories, probably into namelist.fire.

See also #22 - reconcile fire registry entries

Split standalone off from https://github.com/openwfm/wrf-fire and make it work with https://github.com/openwfm/WRF-SFIRE

Useful to identify compiled executables and for user support. We had similar in wrf-fire.git since 2008, 7b2743f d8dee91 139cff4.

Make obvious these are tracking branches.

fxlong and fxlat was provided by customized WPS but it is not available from stock WPS we need to use with WRF v4. The code for creating fxlat and fxlong is inside SFIRE, but the ignition coordinate check always fails.

Parallel testing shows small differences with with diferent processor grids on testing_GFSF with fire on. But all is good when the fire is off, cf. #12

Process 3D smoke field from HRRR-Smoke into WRF-SFIRE. The first step was to modify METGRID.TBL to get the smoke field into metgrid format files (openwfm/wrfxpy#69). Then, some modifications in real were able to transfer those fields into input and boundary conditions for tr17_1 tracer fields. However, some experiments have proven that the boundary conditions for tr17_1 are not used even if correctly specified in wrfbdy files.

In addition to parallel consistency #13 test also if the numbers are the same (up to rounding errors) between different compilers, intel/gnu/pgi.

Merge with wrf-model/WRF/wrf-model#1435

On Centos 8, configure produces the message

The moving nest option is not available due to missing rpc/types.h file.
Copy landread.c.dist to landread.c in share directory to bypass compile error.

But doing so makes a mess of git, it is too easy to pick it up by git commit -a
The configure script looks also in /usr/include/tirpc/rpc/types.h but when it does not find that it gives up.

Find where the file is on Centos 8 and modify configure as needed.

Transition remaining test/em_fire/* ideal problems ported from openwfm/wrf-fire to ifire=1, test, and fix.

Interpolate U and V to a 3D boundary layer at fire mesh resolution and given heights.

Add Balbi fire model as an alternative to Rothermel model.

@Fergui writes:
As promised, I generated two identical cases in WRF v3.4 and WRF v4.2 to show that they have FXLONG and FXLAT coordinates differently defined. I also created a Python code that reads at both wrfout files, generates numpy arrays for all the coordinates, prints min and max values, and plots both arrays using matplotlib. Please, find:

• WRF v3.4 case: /uufs/chpc.utah.edu/common/home/u6015636/repos2/branches/wrfxpy3/wksp/testing-coord
• WRF v4.2 case: /uufs/chpc.utah.edu/common/home/u6015636/repos2/wrfxpy/wksp/testing-coord
• Python script in Kingspeak under /uufs/chpc.utah.edu/common/home/u6015636/repos2/test_coord

Upgrade to the latest release of the upstream software and test.

The last step of the diagnostics described at https://wiki.openwfm.org/wiki/How_to_diagnose_fuel_properties_in_WRF-Fire#Step-by-step_instructions gives an error. See also openwfm/wrf-fire-matlab#5.

Update https://www.openwfm.org/wiki/WRF-SFIRE_user_guide, archive and replace obsolete pages.

Hardcoded check enforces minimum patch size 10.

wrf-model#369 5340346 Fri Feb 16 11:26:35 2018 -0700

The approximation in subroutine fuel_left does not vary the output smoothly enough resulting in spikes of the heat flux, which is constant times the time derivative of fuel left. For a reasonable approximation, the fire mesh needs to be very fine so that the fuel decay stretches over several cells and is approximately linear in each, but there will still be some artifacts when the wireline enters the cell at certain angles. Implement numerical quadrature for diagnostics and train a fast surrogate.

From @tartanrunner25: I noticed a bug in the WRF-SFIRE code, where the canopy top winds were about 1-2 m/s too slow than what I expected (10-20% difference). The canopy top for our RxCADRE simulation should be between vertical levels 3-4. However, the winds between these levels were 8-9 m/s., while the winds computed at the canopy top were closer to 7 m/s, which technically does not make sense if I am interpreting Jan's log wind interpolation code. Need to determine whether there's a bug with his code, or perhaps I did something stupid on my end when I tried replicating his codes results. This issue was not present for the test case we looked at, however, in this case the winds were being interpolated between

Identify which registry objects we use and recreate them under unique SFIRE names and reduce potential conflicts with future changes in wrf-model/WRF.

In testing-GFSF, Intel compiler/MPI get stuck or error out at or after printing total emissions, which are computed by MPI_SUM_ALL when file_print_msg > 0. Debug the issue and add a flag in namelist.input to disable the computation.

Complete WRF pull request wrf-model#792. Adam' summary:

From: Adam Krzysztof Kochanski [email protected]
Sent: Monday, July 22, 2019 3:12 PM
To: Branko Kosovic [email protected]
Cc: Domingo Munoz-Esparza [email protected]; Pedro Jimenez Munoz [email protected]; Mandel, Jan [email protected]
Subject: Meeting summary
...

1. We will keep the 5-layer fuel structure keep the 1000h load to maintain combability with the future fire models dealing with thermally thick 1000h fuel.
2. To keep the code flexible and in line with WRF conventions we will leave the num_fmc dependency defining the number of fuel classes, but we will remove it from the namelist template to prevent end users form accidental changes that could break the code. num_fmc is already only registry.fire and no other files
3. To improve the transparency, the FMC_GC will be filled with the specific values from namelist called: fmc_1h, fmc_10h, fmc_100h, fmc_1000h and fmc_lh.
4. We will change the way how the fuel moisture is initialized, so it is added to met_em files and then processed by real.exe, not via geogrid how it is done right now.
5. Within the real.exe there will be a check if the fmc values are present in the met_em files, if not, the fmc_XX values form the namelist will be populated into FMC_GC. Pedro will send an example how to do that.
6. The initialization from the equilibrium will be activated by a separate switch in the namelist, and the activation will be executed from the fire code, overwriting whatever fmc_gc was in the wrfinput file.
7. We will rename the moisture section and consolidate drying / wetting lags.
8. Most of the advanced functions will be removed from the template namelist in order to simplify it, but still the ability to override the default values by namelist entries will be kept in place.
9. We will fix the linkage between the ROS and the fuel moisture that got broken during transplanting the fuel moisture code.
10. We will work on the adding the fuel moisture variable description to the namelist.input_readme while Branko, Pedro and Domingo will update the rest of the fire-related variables.
11. We don’t expect any problems with unphysical drying of the fuel near the fireline (long drying lag, and the dilution of the heat flux in larger atmospheric cells).
    ...