Fuel moisture model pull request final changes 2020 - Revision history

Jmandel: /* Piecewise constant interpolation instead of piecewise linear AMSWERED */

2020-02-08T00:15:27Z

Piecewise constant interpolation instead of piecewise linear AMSWERED

← Older revision		Revision as of 00:15, 8 February 2020
Line 82:		Line 82:
	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		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 ~~AMSWERED~~===		===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 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.''

Jmandel: correcting for the PR comment

2020-02-08T00:11:53Z

correcting for the PR comment

← Older revision		Revision as of 00:11, 8 February 2020
Line 126:		Line 126:
	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.		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 ~~the~~ time step ~~itself is~~ 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.		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===		===Fuel classes initialized for a real case ANSWERED===

Jmandel at 00:10, 8 February 2020

2020-02-08T00:10:13Z

← Older revision		Revision as of 00:10, 8 February 2020
Line 129:		Line 129:

	===Fuel classes initialized for a real case ANSWERED===		===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?		''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.		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.

Jmandel: /* Piecewise constant interpolation instead of piecewise linear AMSWERED */

2020-02-08T00:09:37Z

Piecewise constant interpolation instead of piecewise linear AMSWERED

← Older revision		Revision as of 00:09, 8 February 2020
Line 85:		Line 85:
	''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 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 ~~some resolution~~.		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===		===Fixed dt only ANSWERED===

Jmandel: /* Fire_ifun_end ANSWERED */

2020-02-08T00:08:47Z

Fire_ifun_end ANSWERED

← Older revision		Revision as of 00:08, 8 February 2020
Line 126:		Line 126:
	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.		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 the time step itself is passes ifun=3 to ifun=6. The correct value is 3. 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.		By design, initialization is done in passes ifun=1 to 2, and the time step itself is 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===		===Fuel classes initialized for a real case ANSWERED===

Jmandel: /* Fuel moisture model not activated should not change results on fire problems DONE */

2020-02-07T22:25:36Z

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

← Older revision		Revision as of 22:25, 7 February 2020
Line 6:		Line 6:

	==Fuel moisture model not activated should not change results on fire problems DONE==		==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		Comparing
	https://github.com/wrf-model/WRF/pull/792#issuecomment-582070283		https://github.com/wrf-model/WRF/pull/792#issuecomment-582070283

Jmandel: /* Fire_ifun_end IN ANSWERED */

2020-02-07T22:23:51Z

Fire_ifun_end IN ANSWERED

← Older revision		Revision as of 22:23, 7 February 2020
Line 116:		Line 116:
	Maybe have a better look at what happened in those parallel cases? See also '''Distributed memory''' above.		Maybe have a better look at what happened in those parallel cases? See also '''Distributed memory''' above.

	===Fire_ifun_end IN ANSWERED===		===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?		''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 ~~ifun =~~ 2, and the time step itself is passes ifun=3 to ifun=6. The ~~repository shows~~ I changed fire_ifun_end = 2 in the ~~initializatio~~ to 3 in 73fcb8565fa104c on Sep 6 2010~~, with the comment "interpolate winds atm2fire in init". Apparently I wanted~~ to have ~~the initialization to include also the preparation stage of the first time step in order to have the~~ winds ~~interpolated to the fire mesh at the beginning of~~ the ~~first time step~~ for ~~some reason~~. The ~~value fire_ifun_end = 3 for initialization end ended up~~ in ~~the~~ WRF ~~repository~~ in cd867781f4 on Dec 30 2010~~. It did not hurt anything it only means that the pass ifun=~~3 ~~of the first time step is done twice, but it was illogical~~. I ~~reverted the value~~ 3 to 2 in 2f4650eecd0e9dc4a9 on Dec 15 2012 but the fire code in WRF ~~was never updated by a new version~~. ~~In this pull request,~~ I ~~used~~ 2, which ~~passed all test~~.		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 the time step itself is passes ifun=3 to ifun=6. The correct value is 3. 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.

	===Fuel classes initialized for a real case ANSWERED===		===Fuel classes initialized for a real case ANSWERED===

Jmandel: /* Does the FFM work with restart? DONE */

2020-02-07T22:12:44Z

Does the FFM work with restart? DONE

← Older revision		Revision as of 22:12, 7 February 2020
Line 88:		Line 88:

	===Does the FFM work with restart? DONE===		===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:		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:

Jmandel: /* Piecewise constant interpolation instead of piecewise linear */

2020-02-07T22:10:22Z

Piecewise constant interpolation instead of piecewise linear

← Older revision		Revision as of 22:10, 7 February 2020
Line 77:		Line 77:
	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		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===		===Piecewise constant interpolation instead of piecewise linear AMSWERED===
	''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 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.''

Jmandel: /* Fixed dt only ANSWERED */

2020-02-07T22:09:59Z

Fixed dt only ANSWERED

← Older revision		Revision as of 22:09, 7 February 2020
Line 83:		Line 83:

	===Fixed dt only ANSWERED===		===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?		''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.		Currently the time keeping supports fixed time step only.