[develop] Add Community Fire Behavior Model #1139
Conversation
…essfully, but won't run correctly.
cleanup create_nems_configure_file.py to use arguments rather than environment variables, add fire capabilities
- Add remainder of configurable fire namelist options to config_defaults - Add fire namelist filenames and paths to config_defaults - Add LEVP (number of vertical levels) as a config variable, and explicitly set levp and npz as namelist variables. This will require some updates to documentation - Generate the majority of the UFS_FIRE namelist in the workflow generation script. The rest (start and end times) will be set in the run_fcst step to account for cycling
- Needed correct naming template for input ICS and LBCS in config.fire.yaml - Incorrectly formatted lines in create_nems_configure_file.py - Fix incorrect namelist location for levp - Forgot to ignore FIRE_INPUT_DIR when creating &fire namelist
- Fill in &time namelist section - Link namelist.fire to namelist.input for now (until we can get the name changed) - Link in geo_em file Stuck on namelist errors for now due to old weather model hash.
…file does not exist. This avoids weird error handling from calling an argparse error class.
- Force bash to output decimal numbers when creating fire namelist - Remove rogue ln command
- Create a new variable FIRE_NUM_TASKS to choose the number of tasks to assign to the fire behavior model. - Modify PE_MEMBER01 so it accounts for FIRE_NUM_TASKS if set - Check that FIRE_NUM_TASKS is positive if running the fire model - Remove last remnants of old namelist variables - Update nems.configure to assign weather model to first petlist, then the fire tasks last
- Remove deprecated namelist options "fire_grows_only" and "fire_lfn_ext_up" - Add functionality to create_diag_table_file.py that gives the ability to add additional entries to an existing diag_table - When UFS_FIRE is active, add line to diag_table for "fsmoke" tracer
…_workflow Resolved Conflicts: Externals.cfg parm/ufs.configure ush/create_ufs_configure_file.py ush/generate_FV3LAM_wflow.py ush/get_crontab_contents.py ush/set_namelist.py
…ack where it should be!
…ile. This gives ~5x speedup for create_symlink_to_file on derecho
mkavulich
force-pushed
the
feature/ufs_fire_workflow
branch
from
de7f71f
to
c77770f
Compare
|
@christinaholtNOAA @MichaelLueken I believe I have addressed all your comments. Note that I did update how the fire ignition variables are handled in Let me know if you have any more comment/concerns. |
There was a problem hiding this comment.
@mkavulich - While attempting to run the two new WE2E tests, they failed to submit because FIRE_ATM_FEEDBACK > 0.0 for these new configurations. Should the test configuration use FIRE_ATM_FEEDBACK: 0.0 instead of FIRE_ATM_FEEDBACK: 1.0?
Initial capability needs FIRE_ATM_FEEDBACK=0.0
FIRE_ATM_FEEDBACK = 0.0
FIRE_ATM_FEEDBACK = 0.0
There was a problem hiding this comment.
Thanks, @mkavulich! The tests are successfully generated and run. Also, thank you very much for updating the documentation in ConfigWorkflow.rst. We'll need to see if there is some way to pull information directly from config_defaults.yaml into the ConfigWorkflow.rst file so that we don't need to repeat modifications to both.
|
@MichaelLueken Thanks for the review. Let me know when the data is staged for the WE2E tests; I'll likely need to make some modifications to those test files to point to the correct data. |
|
The UFS Fire data has been staged on Tier-1 platforms:
And many thanks to @RatkoVasic-NOAA for staging the data across the platforms! |
- New variable to WE2E test data, we should use this to consolidate test variables in the future - Shorten fire tests to 3 hours - Fix extra prints in workflow generation
|
@MichaelLueken I pushed the final changes for the new fire WE2E tests, I believe this PR is ready for merging presuming all tests pass and @christinaholtNOAA approves. |
MichaelLueken
added
the
run_we2e_coverage_tests
|
The Jenkins tests are all failing in the |
|
On Hera, you can see the directory structure for GNU - |
|
@MichaelLueken Thanks for the update. I pushed a fix that should work, can you try again? |
|
Thanks, @mkavulich! The Jenkins tests have been resubmitted. |
|
The Jenkins tests are now running without issue, but there is a conflict in |
|
All Jenkins WE2E tests have successfully passed! I will be able to merge this PR once the conflict in |
DESCRIPTION OF CHANGES:
This PR introduces the Community Fire Behavior Module (ufs-community/ufs-weather-model#2220) to the SRW App. In addition, there are a number of general improvements to the UFS SRW code and workflow. All of these changes are described in more detail below.
Community Fire Behavior Module
Documentation has been added to the Users Guide, but the basics are that the fire build requires an additional build flag
and has an additional
fire:section inconfig.yaml. There is an example fire configuration available in the new example configconfig.fire.yaml. Many settings are described in detail inconfig_defaults.yaml, but I am working on additional details.The fire model outputs additional netCDF files with fire-specific information; two example plots of this data can be found here:
Sample data for the case in the example file has been staged on Derecho (/glade/derecho/scratch/kavulich/FIRE/2024/test_data) and Hera (/scratch2/BMC/fv3lam/kavulich/UFS/workdir/UFS_FIRE/test_data). I will reach out to EPIC to see if they would be willing to officially stage this sample data on all Level 1 platforms for community use and potential future tests. This PR does not include a WE2E test because the testing system does not currently have a neat way to handle multiple build types, but in theory the new example case could be used.
Two new pre-defined domains
SUBCONUS_CO_1kmandSUBCONUS_CO_3km, for use with high-resolution fire experiments, are added.build_settings.yamlIn
developthere is currently no way to reference build settings at configure and run time. There was a vestigial capability in theufs_srweather_app.settings.inwhich was added 4+ years ago, but it has never really been used or updated and it is in an ad-hoc format that cannot be easily used. I have leveraged this existing capability to create a new file,build_settings.yamlin the build directory that contains useful build information (the application built, the compiler, the git hash, etc.) and can be easily read using uwtools in the existing workflows and run scripts. Specifically this is used in this PR to ensure that the app has been built with the fire behavior capability if fire options are selected, but this should prove very useful in other parts of the workflow going forward; for just a few examples:This new file and the unused (but potentially useful in the future)
ufs_srweather_app_meta.h.infiles are moved to thesorcdirectory to keep the source code more organized and uncluttered.Improve capability to use a different set of vertical levels
Currently the instructions for running SRW with a different number of vertical levels from the default 65 is quite convoluted, involving the need to manually edit the template namelist file. This PR adds LEVP as a configuration variable to more easily allow for runs with different vertical levels. The users guide instructions have been updated accordingly.
Flexible config file name
Now rather than being forced to use the name
config.yamlfor your experiment config, you can reference any yaml file by using the-coption for workflow generation:With these changes,
EXPT_CONFIG_FNis removed as a configurable option, but this was uselessly self-referential anyway.Additional options for
retrieve_data.pyA big limitation in specifying filenames in the current app is that there is no capability for filenames to change based on the forecast hour vs the cycle hour. Therefore a new set of variables, identical to the originals but with the prefix
f, can now be used when specifying filenames with respect to the forecast hour rather than the cycle hour.An example of this new usage can be seen in the newly added
config.fire.yamlexperiment:This instructs
retrieve_data.pyto look for filenames specific to the valid forecast hour for the specific lateral boundary condition file. So for forecast hour zero (valid 2020081318), the expected filename will be20200813.hrrr.t18z.wrfprsf00.grib2. But at the 18 hour forecast, the LBC filename will be20200814.hrrr.t12z.wrfprsf00.grib2. This was not previously possible without these new variables, and represents a vast improvement in flexibility for users.Speedup of symbolic linking
I found that (depending on the platform) the
create_symlink_to_file.shfunction could take as many as several seconds for each link, an absurdly long time for such a simple operation! I removed some superfluous logic from this function andboolify.sh(which ensures that booleans are properly compared in bash, a necessary evil), which brought this time down to tenths of seconds. This results in a speedup of a minute or more for the run_fcst task, depending on the platform and the settings.Various random improvements
SyntaxWarning: invalid escape sequenceFCvariable, which is needed by the Fire Behavior component.Type of change
TESTS CONDUCTED:
A number of fundamental test runs have been conducted on Derecho, Hera, and Orion, both with and without the ATMF build. Not all are passing, but seems to be unrelated to this development; see the note at the top. This section will be updated once those issues are resolved.
DEPENDENCIES:
#1136 should be merged first, as it includes a fix for Hera runs with the new UFS weather model hash.
DOCUMENTATION:
Users guide has been updated with instructions for building and running with these new capabilities; see draft documentation build in the Github checks below. Specifically, this is the new chapter on the UFS_FIRE capability.
ISSUE:
CHECKLIST
CONTRIBUTORS (optional):
Thanks to the whole Fire Behavior team for bringing me on to this project, and their extensive efforts to get this capability ready for use by the scientific community: @danrosen25 @masih-e @pedro-jm and @mefrediani