NCAR / NCAR/fire_behavior

Fuel Moisture Model implementation

Open
#42 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug Initialization Regression Harness
Dominant language
Fortran
Stars
11
Forks
17
Avg merge
21h 12m
Merged PRs (30d)
1

Description

Step-based moisture scheduling can skip initialization

Classification: source-confirmed initialization defect. Applies to a fresh run with fmoist_run = .true. and fmoist_freq > 1.

Init_fmc_wrffire allocates class moisture and diagnostic arrays without initializing their values. In Advance_fmc_model, lines 159–180, a positive frequency permits an update only when the step is divisible by that frequency. Initialization is then requested only by the condition itimestep == 1. Advance_state increments the step before advancing fire components.

For fmoist_freq = 2, step 1 skips moisture evolution. Step 2 invokes it with initialization false. The class solver consequently reads class moisture that has not been assigned. The previous meteorological values normally initialized through Copy2old are also not established by that initialization path. This can produce compiler-dependent results or invalid values. No particular runtime failure has been demonstrated in this review.

The correction should separate initialization from update scheduling. Initialize class moisture and previous forcing from the first valid atmospheric state regardless of the requested update frequency. Define whether that initialization occurs at the initial time or first advance, and ensure the resulting elapsed moisture time is correct. An explicit initialized-state flag is preferable to inferring initialization solely from a step number. A restart must restore the saved moisture and timing rather than initialize again.

Moisture above extinction produces negative reaction quantities

Classification: source-confirmed nonphysical intermediate values. Applies to the aggregate Rothermel branch when effective moisture exceeds its extinction parameter.

In Set_ros_parameters_wrffire, the routine evaluates ηₘ = 1 − 2.59r + 5.11r² − 3.52r³ with r = M / Mₓ. It uses this value directly in reaction intensity, iboros, and base spread. At r = 2, ηₘ = −11.90. The final spread routine limits returned ROS to nonnegative values, but it does not correct the stored negative reaction quantities.

The established defect is the sign of those intermediate quantities. It does not establish negative final propagation. Calc_flame_length, uses a fractional power of iboros * ros, so downstream diagnostics also need examination wherever ROS and reaction quantities are combined.

For nonnegative physical FMC and positive Mₓ, the proposed correction sets moisture damping to zero at or above extinction and preserves the polynomial below extinction. Validate inputs separately so negative moisture, nonfinite values, or nonpositive extinction parameters are not silently repaired by this clamp. Do not cap the physical moisture state at Mₓ, since wetter fuel is a valid state.

Initial moisture cannot be prescribed independently by class through the namelist

Classification: missing experimental controls. The existing equilibrium initialization is an implemented choice, not itself a bug.

fmc_wrffire_mod.F90, defines fmc_gc_initialization = [2, 2, 2, 2, 3] as a constant. The four dead classes initialize from equilibrium and the fifth from a scalar. Lines 104–108 populate the dead initial-value array from the single fuelmc_g scalar and the fifth entry from fuelmc_g_live. The selected equilibrium modes do not use the four scalar values. These initialization modes and independent class values are absent from the CFBM namelist declaration.

Changing fuelmc_g therefore does not define an independent initial 10-hour or 100-hour moisture perturbation once class initialization runs. Changing fuelmc_g_live affects both prescribed curing and the fifth initial class. A user cannot independently prescribe those two quantities with existing controls. WRF-Fire names such as fmc_1h and fmc_live.

The proposed enhancement adds explicit class initialization modes and values, with current defaults preserved. Suitable modes include equilibrium, the common surface scalar, and a class-specific scalar. Reading a spatial moisture field should be a separately implemented mode with a defined file format and grid mapping, not a newly accepted flag without an input reader.

Implementation requires namelist parsing, validation, MPI distribution, propagation through fmc_t%Init and its callers, and an experiment record of the resolved settings. Restart handling must preserve the saved state and distinguish initial conditions from controls that apply throughout a resumed run.

Moisture lag and rain coefficients are unavailable in the namelist

Classification: missing experimental controls.

In fmc_wrffire_mod.F90, drying_lag, wetting_lag, saturation_moisture, saturation_rain, and rain_threshold are constant five-element arrays. drying_model and wetting_model are also fixed, with only the implemented model selected. The CFBM namelist exposes fmoist_freq and fmoist_dt, which schedule numerical updates but do not change physical lag coefficients.

The missing capability is a controlled sensitivity to the physical moisture response without recompiling. Varying the update interval is a different experiment and should not be described as varying the 1-hour or 10-hour response time. Copying WRF-Fire's &fuel_moisture block into a CFBM namelist does not add this capability.

The proposed enhancement exposes supported coefficients as configuration arrays, preserving current defaults. Units must be explicit: hours for lag, kg water per kg dry fuel for moisture, and mm h⁻¹ for rain quantities. Derive reciprocal lags from the resolved values for each configured component. Validate positive finite lags and rain scales, nonnegative finite moisture and thresholds, and expected array lengths. Do not expose additional model numbers until their equations are implemented. Allowing a short live-class lag would create an artificial atmospheric relaxation experiment, not a physiological live-moisture model.

Ordinary output omits moisture classes and their response diagnostics

Classification: missing output diagnostics. Effective FMC is already output.

fmc_wrffire_mod.F90, stores fmc_gc, fmc_equi, and fmc_lag. The model also calculates fire_rh_fire. In state_mod.F90, Save_state, lines 1888–1995, ordinary fire output includes effective fmc_g and meteorological forcing but does not write these class arrays or relative-humidity diagnostic. Write_restart_fmc, lines 1848–1884, writes fmc_gc and moisture timing, but not the equilibrium and lag arrays.

Quantity Current ordinary output Current FMC restart output Proposed addition
Effective FMC, fmc_g Yes Yes Preserve existing field
Class FMC, fmc_gc No Yes Ordinary class history
Selected equilibrium, fmc_equi No No Class history, labeled as the last update's target
Effective lag, fmc_lag No No Class history in hours
Computed RH, fire_rh_fire No No Ordinary history with its calculation convention
Time of last moisture update No dedicated field in Save_state Yes Timing metadata for interpreting held values

The proposed enhancement writes these diagnostics through a documented optional output level or dedicated moisture-output control. Such a control is not currently available. Class history needs a named moisture-class dimension, ordered class labels, units, and a clear dry-mass convention. The rank of each array and owned MPI extents must follow the existing parallel output methods. Avoid exporting uninitialized halos or creating fields from an unallocated moisture component.

Equilibrium and lag describe the most recent moisture update, while file time may advance between updates. Their output needs the last-update time. After a restart, only some diagnostic fields are restored. Either reconstruct the missing diagnostics without advancing the state or mark them unavailable until a valid update. fire_rh_fire is assigned before the solver caps supersaturated RH, so document that distinction rather than labeling it the bounded RH used by every subsequent equation.

Configuration documentation misstates the moisture option and grid

Configuration.rst, describes fmoist_run as operating on the atmospheric grid with output named fmc_gc. It lists the default of fmc_opt as 1 and labels −1 as constant moisture. The namelist source, instead defaults to FMC_WRFFIRE. fmc_mod.F90 defines that constant as −1. fire_driver_mod.F90, lines 61–80 and 114–121, uses fmoist_run to control initialization and advancement.

The moisture component allocates and advances class moisture on fire-grid bounds. For WRF coupling, [module_first_rk_step_part1.F (../../dyn_em/module_first_rk_step_part1.F), interpolates meteorology before CFBM advances moisture.

The correction should state that −1 selects the implemented WRF-Fire-derived moisture component, with fmoist_run = .false. selecting prescribed surface FMC and .true. enabling evolution, averaging, and spread-parameter updates. It should give the default as −1, identify the fire grid, and distinguish stored class state from fields written to ordinary output.

Also describe equilibrium initialization of the four dead classes, the nearly constant fifth class initialized from fuelmc_g_lh, the dual use of that scalar for curing. Explain fmoist_dt as the numerical update interval rather than a physical fuel response time.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with fmc_wrffire_mod.F90, namelist_mod.F90, fire_driver_mod.F90, advance_mod.F90, fire_physics_mod.F90, and state_mod.F90; trace initialization, scheduling, restart, and ordinary-output paths. Review the linked Configuration.rst and module_first_rk_step_part1.F context before separating the bundled defects, controls, diagnostics, and documentation work. Done requires validated behavior, preserved restart semantics, documented configuration and output conventions, and coverage of the affected paths.

Written by the indexing model from the issue text.

Assessment

Tech stack
fortran
Domain
backend, documentation
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.