Skip to content

wind horizontal interpolation for wrf staggered grid winds - #67

Open
masih-e wants to merge 1 commit into
developfrom
develop-staggered-winds
Open

masih-e wants to merge 1 commit into
developfrom
develop-staggered-winds

Conversation

@masih-e

@masih-e masih-e commented Nov 2, 2026 •

Copy link
Copy Markdown
Collaborator

Description of changes:

Adds wind_hinterp_opt = 3, a WRF C-grid stagger-aware horizontal wind interpolation. Instead of interpolating destaggered mass-grid winds, it uses WRF's native U/V placement together with PH/PHB and ZNT, following WRF-Fire more closely. It is available in the WRF-coupled path (Interp_wrfstaggered_winds_to_cfbm in io/wrf_mod.F90) and in standalone runs forced by wrfout files that provide staggered U/V, PH, PHB and ZNT (Interp_wrfout_staggered_winds_to_cfbm). The option is valid only with wind_vinterp_opt = 0; the namelist check stops the run otherwise.

This is a port of 597020d from ros-hwinds-sb40-restart-dev33 onto current develop (284b19e). The WRF-CFBM branch cfbm-staggered-winds calls these routines and cannot build against develop without them.

Conflict resolutions against develop:

  • io/namelist_mod.F90: keeps develop's fuelmc_g_live. The fuelmc_g_lh rename (4f7493d) is not part of this PR.
  • io/wrfdata_mod.F90: drops a duplicate Get_z0 (develop reads z0 before the wind select); reads phl once ahead of the staggered branch.
  • state/state_mod.F90: keeps develop's Interpolate_vars_atm_to_fire layout (fz0 computed first, Interp_winds2grid for 3D winds) and adds the staggered path as a branch in the 3D-winds case. z0 is still destroyed at the end of the routine, as on develop.

Behavior relative to 597020d: in standalone runs, wind_hinterp_opt only takes effect when set to 3. For options 1 and 2, 3D winds go through develop's Interp_winds2grid, which uses hinterp_opt. The default (wind_hinterp_opt = 2) does not enter the new code path.

Type of change

  • New feature (non-breaking change which adds functionality)

Tests conducted:

Platform: NCAR Derecho. Compiler/libraries: GCC 12.4.0, Cray MPICH 8.1.29, NetCDF 4.9.2, CMake 3.26.6 (ncarenv/24.12).

  • Standalone fire_behavior builds.
  • WRF-CFBM (WRF v4.8.0, branch cfbm-staggered-winds) builds and links against this branch; the wrf executable contains Interp_wrfstaggered_winds_to_cfbm.

Documentation:

  • Documentation has been updated for these changes doc/Configuration.rst documents wind_vinterp_opt, hinterp_opt and wind_hinterp_opt. Note: it describes options 1 and 2 of wind_hinterp_opt as nearest/bilinear mass-grid wind interpolation. That holds for the WRF-coupled path; in standalone runs those two options defer to hinterp_opt (see above). This wording may need adjusting before merge.

Contributions:

Maria Frediani developed the original stagger-aware wind interpolation implementation (597020d). Masih Eghdami ported it onto current develop, resolved integration conflicts, and verified standalone and WRF-CFBM builds. Codex assisted with code review and focused numerical checks.

Port of 597020d (from ros-hwinds-sb40-restart-dev33) onto develop
284b19e, so WRF-CFBM can use wind_hinterp_opt=3 with current develop.

Conflict resolutions:
- namelist_mod: keep develop's fuelmc_g_live in the /fire/ group;
  the fuelmc_g_lh rename (4f7493d) is not part of this port.
- wrfdata_mod: drop the duplicate Get_z0 (develop reads z0 before the
  wind select); read phl once ahead of the staggered branch.
- state_mod: keep develop's Interpolate_vars_atm_to_fire layout (fz0
  computed first, Interp_winds2grid for 3D winds) and add the staggered
  path as a branch inside the 3D-winds case. z0 is not destroyed there
  because develop destroys it at the end of the routine.

Behavior change relative to 597020d: in standalone runs,
wind_hinterp_opt only has an effect when set to 3. For options 1 and 2,
the 3D winds go through develop's Interp_winds2grid, which uses
hinterp_opt.

(cherry picked from commit 597020d)
@masih-e
masih-e force-pushed the develop-staggered-winds branch from fcebc44 to 00d4099 Compare November 2, 2026 20:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants