Fuel moisture model pull request final changes 2020

From openwfm
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


This page is mirrored by hand at https://github.com/openwfm/WRF-Fire-merge/wiki/Fuel-moisture-model-pull-request-final-changes-2020

Last changes for https://github.com/wrf-model/WRF/pull/792

Fuel moisture model not activated should not change results on fire problems DONE

To ensure backward compatibility, we would like to perform a test to ensure that switching off the FMM does produce the same results as the existing WRF-Fire code.

Comparing https://github.com/wrf-model/WRF/pull/792#issuecomment-582070283 46b548370c9eff7c9 (right after merge develop at 33bf83c664426b2674) with the develop branch at 33bf83c664426b2674

Using same input files in test/em_fire and test/em_fire/two_fires. The fuel moisture flags are missing thus at defaults values.

Shared memory

configure -d, 13, nesting 1

  1. /glade/work/jmandel/merge/WRF-Fire-merge-with-develop branch fuel_moisture_model at 46b548370c9eff7c9a8
  2. /glade/work/jmandel/merge/WRF-Fire-merge-develop branch develop at 33bf83c664426b267452

ncdiff test/em_fire/wrfout_d01_2006-01-01_09:06:00 OK (the default simple_hill case)

ncdiff test/em_fire/two_fires/wrfout_d01_2006-01-01_10:00:00 OK

Distributed memory

configure, 15, nesting 1

  1. /glade/work/jmandel/merge/WRF-Fire-merge-with-develop-dm at 46b548370c9eff7c9
  2. /glade/work/jmandel/merge/WRF-Fire-merge-develop-dm at 33bf83c664426b2674

ncdiff test/em_fire/wrfout_d01_2006-01-01_09:06:00 OK (the default simple_hill case)

ncdiff test/em_fire/two_fires/wrfout_d01_2006-01-01_10:00:00 OK

Result

Branch fuel_moisture_model at 46b548370c9eff7c9a8 and branch develop at 33bf83c664426b267452 give the same output files, except XLONG and XLAT which are now set in ideal.exe and the fuel moisture variables, which do not exist in branch develop, and are not in registry packages yet.

There is a small but statistically significant difference in variable FIRE_SMOKE between 1 processor with debugging on and 16 processors optimized, relative difference up to 0.013. The difference is exactly the same with or without the fuel moisture model.

Comparison of netcdf files done by https://github.com/openwfm/wrf-fire-matlab/blob/b5f918af9127ca9335b5ac8d32dd3c5d7769a9db/netcdf/ncdiff.m

Update the pull request commit message DONE

https://github.com/wrf-model/WRF/pull/792#issuecomment-579035015 there should be 15 files modified

Done, https://github.com/wrf-model/WRF/pull/792#issuecomment-582208931

km_opt=5 fix now in the develop branch, merge DONE

https://github.com/wrf-model/WRF/pull/792#issuecomment-579035675

  • /glade/u/home/jmandel/merge/WRF-Fire-merge-base-dm tag fuel-moisture-model-base-dec10-2019 at f9559af4b8a835f71 vs. /glade/u/home/jmandel/merge/WRF-Fire-merge-with-develop-dm branch fuel-moisture-model-merged-with-develop at 46b548370c9eff7c9
  • /glade/u/home/jmandel/merge/WRF-Fire-merge-base-dm/test/em_fire/rain/ vs /glade/u/home/jmandel/merge/WRF-Fire-merge-with-develop-dm/test/em_fire/rain: no change with np=16

Done at 46b548370c9eff7c9

Fire group comments

https://github.com/wrf-model/WRF/pull/792#issuecomment-579397773

Registry package using fmoist_run variable DONE

Add a new package for the fuel moisture model (FMM) variables, similar to ifire==2, using fmoist_run variable. This will reduce the allocated memory when the FMM is not used.

I had to do also fmoist_interp, which activates only interpolation and mixing of FMC in the fuel classes at every location. This is useful for the case when FMC_GC is given in wrfinput but the user does not want the fuel moisture model model to run, e.g., for a fire of a short duration.

Testing the FMM does not run: A. fmoist_run=false fmoist_interp=false (default): /glade/work/jmandel/merge/WRF-Fire-merge-with-develop-dm/test/em_fire/two_fires/wrfout_d01_2006-01-01_10:00:00 at 46b548370c9eff7c9a8bb7 B. /glade/work/jmandel/merge/WRF-Fire-merge-package-interp-dm/test/em_fire/two_fires/wrfout_d01_2006-01-01_10:00:00 at d564d7da21e33eaec9f B same result as A.

Testing when FMM runs: C. fmoist_run=true fmoist_interp=true: /glade/work/jmandel/merge/WRF-Fire-merge-with-develop-dm/test/em_fire/rain/wrfout_d01_0001-01-01_00:00:000 at 46b548370c9eff7c9a8bb7 D. fmoist_run=true fmoist_interp=true: /glade/work/jmandel/merge/WRF-Fire-merge-package-interp-dm/test/em_fire/rain/wrfout_d01_0001-01-01_00:00:00 at d564d7da21e33eaec9fd3ef D same result as C

Testing when FMM runs partially: E. fmoist_run=true fmoist_interp=false: /glade/work/jmandel/merge/WRF-Fire-merge-package-interp-dm/test/em_fire/rain2 runs OK F. fmoist_run=false fmoist_interp=true: /glade/work/jmandel/merge/WRF-Fire-merge-package-interp-dm/test/em_fire/rain3 runs OK G. fmoist_run=false fmoist_interp=false: /glade/work/jmandel/merge/WRF-Fire-merge-package-interp-dm/test/em_fire/rain4 runs OK

Perhaps remove fmoist_freq and just leave fmoist_dt ANSWERED

Good idea; we use fmoist_dt mostly anyway. However, this close to the release I would prefer to make only truly necessary changes; any change at this point makes it necessary to repeat the testing. Perhaps in future then

Piecewise constant interpolation instead of piecewise linear ANSWERED

Maybe not now but for the future consider not doing interpolation from atmospheric to fire grid fuel moisture rather downscaling (i.e., all of the values within an atmospheric grid cell will have the same fuel moisture values of each class). This would then lead to removal of halo exchange for fmc_g and fmc_gc.

Maybe as an option in future then, e.g., we should test if this does not introduce visible blockiness at resolutions we use.

Fixed dt only ANSWERED

In module_fr_fire_driver.F, there is a comment about “time – assume dt does not change”. Is that true or does the FFM work also with time varying dt?

Currently the time keeping supports fixed time step only.

Does the FFM work with restart? DONE

In general, does the FFM work with restart? Are the logical variables such as run_advance_moisture, moisture_time, run_fuel_moisture, moisture_initializing properly set when restarting?

Yes, we use restart routinely and this port preserves this, as confirmed by the following tests.

Testing restart capability to commit d564d7da21e33eaec9 of repository https://github.com/openwfm/WRF-Fire-merge/tree/fuel-moisture-model. The test consists of comparing WRF-SFIRE results at the same time step running the simulation with and without restart option. The test is performed using:

  • HS - Simple hill experiment in serial: /glade/u/home/angelfc/project/merge/fuel-moisture-model-angel/test/em_fire/hill
  • HP - Simple hill experiment in parallel: /glade/u/home/angelfc/project/merge/fuel-moisture-model-angel_mpi/test/em_fire/hill
  • RS - Rain experiment in serial: /glade/u/home/angelfc/project/merge/fuel-moisture-model-angel/test/em_fire/rain
  • RP - Rain experiment in parallel: /glade/u/home/angelfc/project/merge/fuel-moisture-model-angel_mpi/test/em_fire/rain

The results using ncdiff.m routine are:

  • HS: base/wrfout_d01_0001-01-01_01:00:00 vs restart/wrfout_d01_0001-01-01_01:00:00 - all p-values are 0.
  • HP: base/wrfout_d01_0001-01-01_01:00:00 vs restart/wrfout_d01_0001-01-01_01:00:00 - all p-values are 0.
  • RS: base/wrfrst_d01_0001-01-01_08:00:00 vs restart/wrfrst_d01_0001-01-01_08:00:00 - all p-values are 0.
  • RP: base/wrfrst_d01_0001-01-01_08:00:00 vs restart/wrfrst_d01_0001-01-01_08:00:00 - all p-values are 0.

Also testing parallelism:

  • HS vs HP: restart/wrfout_d01_0001-01-01_01:00:00 vs restart/wrfout_d01_0001-01-01_01:00:00 - all p-values are 0 except for the variable fire_smoke.
  • RS vs RP: restart/wrfrst_d01_0001-01-01_08:00:00 vs restart/wrfrst_d01_0001-01-01_08:00:00 - all p-values are 0 except for the variables MIN_PTCHSZ and fire_smoke.

For more details, look at test_restart.log in each respective folder and test_parallel.log at each respective parallel folder. (base is called prerestart in those files)

Maybe have a better look at what happened in those parallel cases? See also Distributed memory above.

Fire_ifun_end ANSWERED

The call to fire_driver_em() has now fire_ifun_end = 2, where it used to be 3. According to the code comments in module_fr_fire_driver.F, fire_ifun_end = 3 has to do with initialization of time step. Is that skipped now or embedded within fire_ifun_end = 2?

This comment refers to the line https://github.com/openwfm/WRF-Fire-merge/blob/d564d7da21e33eaec9fd3ef235cb74a8ec48edd5/phys/module_fr_fire_driver_wrf.F#L51 , where in subroutine fire_driver_em_init, fire_driver_em is called with the argument fire_ifun_end = 2.

By design, initialization is done in passes ifun=1 to 2, and each time step consists of passes ifun=3 to ifun=6. The correct value is 2. I changed fire_ifun_end = 2 in the initialization to 3 in 73fcb8565fa104c on Sep 6 2010 to have fire winds from the start for diagnostics. The code included in WRF in cd867781f4 on Dec 30 2010 still had 3. I changed 3 back to 2 later in 2f4650eecd0e9dc4a9 on Dec 15 2012 but at that point we could no longer update the fire code in WRF. The mergediff tool noted the difference and I picked the original 2, which did not change results, as verified in the tests @davegill asked for.

Fuel classes initialized for a real case ANSWERED

How are the fuel classes initialized for a real case? It seems that the FM values are prescribed from the solution of the fuel moisture model? Could you document/explain that?

The variables FMC_GC and FMEP are assumed by WRF to be set in wrfinput. This is done in WPS, outside of the scope of this PR. We set them by running a version of the model in Python with RAWS data assimilation ( https://github.com/openwfm/wrfxpy/blob/master/rtma_cycler.sh ). This is at the moment done through GEOGRID ( https://github.com/openwfm/wrfxpy/blob/master/tests/fmda_geogrid.json ). As we discussed last summer, METGRID is more appropriate for that purpose. It would also allow us to input several time levels of FMC_GC and FMEP so that is definitely the plan. The FMEP variable containts modified parameters from RAWS data assimilation.