Porting WRF-SFIRE fuel moisture model to WRF4

From openwfm
Jump to navigation Jump to search

Initial progress

Testing of fmc_g added

Get the test code:

git clone ssh://git@github.com/openwfm/WRF-Fire-merge.git
cd WRF-Fire-merge
git checkout added-fmc_g
git log

to make sure you are at commit 132444f0db67544179c7998f5653c488dd41e836 . Build on kingspeak following How_to_build_WRF4#University_of_Utah_CHPC and run the basic hill test case:

cd test/em_fire
./ideal.exe
./wrf.exe >& wrf.log &

This will use fuel moisture from namelist.fire. To read fmc_g from wrfinput, set

fire_fmc_read=0

in namelist input. This will change as more of wrf-fire is merged in. In any case, fmc_g in wrfinput has to be set by other means, such as using ncreplace in Matlab.

To run real problem, build WPS for this WRF. Variable fmc_g should be in wrfinput but not set, you have to set it by other means.

Testing to be done

  • Compare builds and execution paths:
    • Build from branch develop vs. branch added-fmc_g with fire_fmc_read not set in namelist.input. The numbers should be exactly the same.
    • Change fuelmc_g in namelist.fire to see if it is having the expected effect
    • Build from branch added-fmc_g with fire_fmc_read=0 in namelist.input and with fmc_g manually inserted into wrfinput, to see if it is working as expected
  • From the testing I have already done it seems that the code is slow. I do not know why. I do not know if that is already the case for WRF4 (currently at 4.0.3). Compare speed with wrf-fire on the hill problem.
  • So just in case, I created branch v4.0.3-added-fmc_g which is the same as branch added-fmc_g except it is based on current branch master instead of branch develop and I am testing the hill problem there and in branch master. But are no differences in the fire model files.
  • Real problems need to be tested, with data processed by WPS4

Continued progress

The WRF4 code with the fuel moisture model from wrf-fire is being created in branch fuel-moisture-model. It is not ready for testing yet. Note that the merge is started from branch develop as requested in WRF instructions. The current WRF is at tag v4.0.3 which is few commits behind branch develop.

The original plan (one out of several actually)

Too much complexity. There were quite a few conflicts already in cherry pick to 3cdb542af7ce submitted to 3.3 where not much changed. After a day or so, I decided I may as well do it right.

See also