the single fire validation run process seems to work and provides some fire model outputs but gives an error on creation of the tarred input deck 'elmfire/runs/hindcasts/input_decks/$RUN_NAME.tar', which is an issue later when trying to run the hindcast via the
01-run.sh script. See lines 11-13 of the hindcast run log attached.

ca-county_20180701_062200.txt

The log message appears to be commanded from '/elmfire/runs/hindcasts/04-launch_run.sh' lines 141-142:

progress_message` "Done setting up, tarring up input deck"
tar -cf $CWD/input_decks/$RUN_NAME.tar ./*

When I run for 30hr, most of the time it only gives the result until 15hr. The input deck is the following.

https://drive.google.com/file/d/1YtfXC3v-L7JPomIBeyAVtQoGsqkjhsWE/view?usp=sharing

Regarding the issue posted by @masonlee277 (using ELMFIRE without CLOUDFIRE), which was solved back in June, the Dropbox page containing the corrections made by @lautenberger is not found (404 error). Could you please republish it?

Reference to the old issue:

          @masonlee277 - I pulled the input deck from the google drive link above, simplified it, and updated it for the current code. This [input deck ](https://www.dropbox.com/s/6d6ky9dxyzplvsw/2023-06-28_sample_input_deck.tgz?dl=1) is running correctly on my end, let me know if you encounter any problems running it on your end.

Originally posted by @lautenberger in #14 (comment)

An error occurs when running tutorial case 1. Here is the log information.

ELMFIRE 2023.03
Reading &MISCELLANEOUS namelist group
Reading &INPUTS namelist group
Reading &OUTPUTS namelist group
Reading &COMPUTATIONAL_DOMAIN namelist group
Reading &TIME_CONTROL namelist group
Reading &SIMULATOR namelist group
Reading &CALIBRATION namelist group
Reading &SUPPRESSION namelist group
Reading &SPOTTING namelist group
Reading &SMOKE namelist group
Reading &MONTE_CARLO namelist group
Reading headers for fuels/topography and weather rasters
/cvmfs/hpcsw.umd.edu/spack-software/2022.06.15/linux-rhel8-zen2/gcc-9.4.0/gdal-3.4.0-2lfwxvv4yfehlamhc5zraivmeu4hbxdi/bin/gdal_translate -of ENVI -co "INTERLEAVE=BSQ" ./inputs/asp.tif ./scratch/asp.bsq
Input file size is 400, 400
0...10...20...30...40...50...60...70...80...90...100 - done.
Problem opening bsq xml header ./scratch/asp.bsq.aux.xml
IOS: 2

Looks like there is some issue with opening the weather/topography inputs or preprocessing them. I changed the PATH_TO_GDAL in the file "elmfire.data.in". And here is how I configured the installation:

export ELMFIRE_FCOMPL_SERIAL_GNU=gfortran
export ELMFIRE_FCOMPL_MPI_GNU=mpifort
export ELMFIRE_INSTALL_DIRECTORY=/home/yqin123/software/bin/elmfire
export ELMFIRE_SCRATCH_BASE=/home/yqin123/scratch/elmfire_scratch
export ELMFIRE_BASE_DIR=/home/yqin123/software/elmfire_public/elmfire_public/
export ELMFIRE_INSTALL_DIR=/home/yqin123/software/bin/elmfire_public/
export CLOUDFIRE_SERVER=172.92.17.198
export PATH=$PATH:$ELMFIRE_INSTALL_DIR:$ELMFIRE_BASE_DIR/cloudfire

All other processes follow the instruction in the documentation.

I wanted to try the Monte Carlo option with many random ignition location and use the CALCULATE_BURN_PROBABILITY = .TRUE. option which is mentionend in the documentation (https://elmfire.io/user_guide/monte_carlo.html).

But in the current version (elmfire_2024.0103) this option seems to be removed.

Is there another option availble to calculate an aggregated file "burn_probability.tif" of the single simulations as mentioned in the documentation?

Hi Chris,

I found this problem when initializing a simulation with a customized phi field. I muted the surface fire spreading (by setting Ux=Uy=0) and kept the spotting as the only mechanism. However, my current implementation of the spotting algorithm requires the wind and fireline intensity information from the linked list LIST_BURNT. The initial values LIST_BURNT%WS20_NOW = 0 and LIST_BURNT%FLIN_SRUFACE = 0. These values can not initiate the spotting, thus no fire spreading.

I am wondering whether it is appropriate to initiate the initially burnt cells with the wind speed and assign fire intensity values to some of the cells (cells located at the fire perimeter, for example).

Thanks,
Yiren

Hi Chris,

I got a message error when installing to campus cluster:

Making elmfire_gnu_mpi_linux
mpifort -c -O3 -unroll -frecord-marker=4 -ffree-line-length-none -cpp -march=native -ffpe-summary=none ../../source/elmfire_vars.f90
/global/software/sl-7.x86_64/modules/langs/python/3.10/bin/mpifort: line 392: x86_64-conda-linux-gnu-gfortran: command not found

I don't know where to start troubleshooting

Hi Chris

When I run ELMFIRE on savio using multiple nodes (each nodes has 20 cores), weird thing happened. Suddenly it created many .bin files but not the .bil and .hdr files. The created bin files start from a number until the last ensemble. Then the elmfire only run until the starting number - 1. The simulation somehow stopped and considered as complete with a message from "orted" in the job ID.

To illustrate:
Lets say we use 100 ensembles.
In one second .bin from 26 to 100 are already created but not the corresponding .bil and .hdr. Then elmfire continue running andreate the remaining ensemble (1 - 25). After the 25 ensembles are done, the simulation stop and considered as complete, without giving the .bil and .hdr outputs for ensemble 26 - 100. At the end of simulation the outputs created:
.bin (1 - 100)
.hdr (1 - 25)
.bil (1 -25)

This doesn't happen when using 1 node in SAVIO.

I tried the new version in the main branch but it doesn't work. It is fine using the one I modified last.

I suggest adding the topic wildfire in the About section, as explained at https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/classifying-your-repository-with-topics

Hi Chris, just a note to enable new rasters for input for the parameters of UCB urban fire model. Thanks.

After installation I try to run elmfire but there was an error with gdalwarp. The full log is attached
nohup2.txt

Hello (:

When running any of the tutorials 1-4, we encountered the same error message: elmfire_2023.0715: command not found.

For example, in tutorial 1, the error message is as follows:

./01-run.sh: line 83: elmfire_2023.0715: command not found.

This could point to an issue with the ELMFIRE_VER variable.

This bug did not occur just a week ago when using the elmfire_2023.06 version, which makes us think this issue may have something to do with a recent update.

I tried with this input and it works, but much slower than using Hamada.

https://drive.google.com/file/d/119VjwXsv0s4xQr8MhSc7dtfCBecbMNPD/view?usp=sharing

This issue is moved here from issue #34 because it is a distinct issue. The original report from @johnsonas6 was that the following input deck caused a runtime segmentation fault:

https://drive.google.com/drive/folders/1bZWmxapb1BopR1CBKafQXWeyiYP8_uCF?usp=drive_link

I was able to reproduce this behavior locally and determined that it was due to the use of RANDOM_IGNITIONS=.TRUE. with USE_IGNITION_MASK = .FALSE. in elmfire.data. The keyword USE_IGNITION_MASK is scheduled for removal and until then this combination will now (as of commit 6b94c73) cause a descriptive error message to be emitted to prevent a run time seg fault.

Until USE_IGNITION_MASK is removed, when RANDOM_IGNITIONS = .TRUE. the user should set USE_IGNITION_MASK = .TRUE. and specify a Float32 ignition mask using the keyword IGNITION_MASK_FILENAME on the &INPUTS namelist group.

In tutorial 04, when trying to use my own fuels and weather inputs instead of data obtained from cloudfire, I receive the following error:

Creating output file that is 0P x 0L.
ERROR 1: Attempt to create 0x0 dataset is illegal, sizes must be larger than zero.

However, when trying the exact same process with the output files of a fellow user, no errors occur.
I am attaching my inputs which caused the error. What might be the issue? How should I change them so that they are compatible with tutorial 04?

https://drive.google.com/file/d/1gZW0G2vbiP2wYKfenSE7BhsUhnSjLm5P/view?usp=sharing

With much appreciation,
Noga Givoli

https://drive.google.com/file/d/1QZNJwqDyKahPp-am9lqUfx1LAvFSs_Qr/view?usp=sharing

Running a fire simulation with extended attack enabled, I am having varying results, by as much as 2x the acreage by changing the SIMULATION_DTMAX parameter. Looking at the source code, I think the issue might lie in this line:

This issue requests a new output type for ELMFIRE, and proposes a configuration schema for it.

Problem statement

For some use cases, it is valuable to know the times since ignition at which each simulated fire reaches certain size thresholds (if ever).

Proposed solution

New configuration in elmfire.data would look like:

&OUTPUTS
...
TIME_AT_BURNED_ACRES(:) = 1.0, 3.0, 10.0, 30.0, 100.0, 300.0, 500.0, 700.0, 1000.0
TIME_AT_BURNED_ACRES_CSV = 'path/to/my/burned-acres-timings.csv'

The output CSV would look like:

icase, atotal_threshold_ac, toa_hr
...
1789, 1.0, 1.43
1789, 3.0, 2.25
1789, 10.0, 5.18
1790, 3.0, 3.12
...

The 3rd line displayed above says: "The simulated fire number 1789 reached a size of 10 acres at 5.18 simulated hours of spread". In this example, we see that fire 1789 never reaches 100 acres, since the next line is about fire 1790. We also see that fire 1790 started with an initial size larger than 1 acre (which is fine), such that no 1 ac event was emitted.

When I run the postprocessing the load average is so high that it reach 10,000. The available cores is 48. It correspond to the number of files to be converted from raw to tif, it is 50,000 files. It does not matter if we use Hamada or UCB model. I am thinking to limit the usage of computational power in the postprocessing. What are the options available?

Problem statement: in some calibration use cases, the users need not know how a simulated fire spreads after having exceeded a certain size threshold. It makes sense to configure this on a per-fire basis.

Proposed solution: in the IGNITIONS_CSV_FILENAME file, allow an optional new column stop_above_atotal, providing a threshold in acres. For example, the following ignitions CSV

icase, iwx_band, x, y, stop_above_atotal
...
19, 342, 572416.24, 1067098.27, 100.0
20, 351, 572424.16, 1067027.98, 10.0
...

means that:

• the simulated fire identified by icase=19 should stop being simulated if it exceeds 100 acres, while
• the simulated fire identified by icase=20 should stop being simulated if it exceeds 10 acres.

Outputs should still be emitted even if these thresholds are reached.

Please add a config option to set a minimum fire size and mass release thresholds before writing smoke outputs. Fires that are under these thresholds need not be written out in smoke CSVs.
FYI @hohsieh @mike-amodeo

I am attempting to run ELMFIRE from tifs already created therefor not using the wx.csv nor the CLOUDFIRE api to gather and create weather data.

When I run this script I am not able to load the fuel_models.csv. I attempted to change the relative path to an absolute path in elmfire_init.f90 but it still failed and was not registering any changes that I had made. I also changed the paths in elmfire.data.in but this didn't affect the error either.

There is either an error in my script that I created for this or a bug in the source. When I run the other tutorials they work fine. I

Code
https://drive.google.com/drive/folders/1sP0oEhmt_IDsRz8xt73A1xs3i_u0fgv-?usp=sharing
In some runs I get the error:
./01-run.sh: line 98: elmfire_2023.06: command not found

mostly I get.
OUTPUT OF RUNNING CODE:
[mnlee2@gs611-hammer elmfire_creek_2.5]$ ./01-run.sh
Starting the script.
Simulation stop time set to: 347400.0 seconds
ELMFIRE_SCRATCH_BASE=/home/mnlee2/scratch
ELMFIRE_BASE_DIR=/home/mnlee2/elmfire/
ELMFIRE_INSTALL_DIR=/home/mnlee2/elmfire/build/linux/bin
CLOUDFIRE_SERVER=172.92.17.198
PATH=/usr/lib64/qt-3.3/bin:/usr/lib64/mpich-3.2/bin:/usr/condabin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/home/mnlee2/.local/bin:/home/mnlee2/bin:/home/mnlee2/elmfire/build/linux/bin:/home/mnlee2/elmfire/cloudfire
Deleted existing output directory (if any).
Copied fuel load csv to misc

The contents of the Misc directory are:
fuel_models.csv
1,FBFM01,.FALSE.,0.034,0,0,0,0,3500,9999,9999,1,12,8000
2,FBFM02,.FALSE.,0.092,0.046,0.023,0.023,0,3000,1500,9999,1,15,8000
3,FBFM03,.FALSE.,0.138,0,0,0,0,1500,9999,9999,2.5,25,8000
4,FBFM04,.FALSE.,0.23,0.184,0.092,0,0.23,2000,9999,1500,6,20,8000
5,FBFM05,.FALSE.,0.046,0.023,0,0,0.092,2000,9999,1500,2,20,8000
6,FBFM06,.FALSE.,0.069,0.115,0.092,0,0,1750,9999,9999,2.5,25,8000
7,FBFM07,.FALSE.,0.052,0.086,0.069,0,0.017,1750,9999,1550,2.5,40,8000
8,FBFM08,.FALSE.,0.069,0.046,0.115,0,0,2000,9999,9999,0.2,30,8000
9,FBFM09,.FALSE.,0.134,0.019,0.007,0,0,2500,9999,9999,0.2,25,8000
10,FBFM10,.FALSE.,0.138,0.092,0.23,0,0.092,2000,9999,1500,1,25,8000
11,FBFM11,.FALSE.,0.069,0.207,0.253,0,0,1500,9999,9999,1,15,8000
12,FBFM12,.FALSE.,0.184,0.644,0.759,0,0,1500,9999,9999,2.3,20,8000
13,FBFM13,.FALSE.,0.322,1.058,1.288,0,0,1500,9999,9999,3,25,8000
14,FBFM14,.FALSE.,0.045913682,0.022956841,0,0,0,2000,2000,2000,0.2,25,8000
15,FBFM15,.FALSE.,0.027548209,0.009182736,0,0,0.059687787,2000,2000,1500,1.2,25,8000
101,GR1,.TRUE.,0.00459,0,0,0.01377,0,2200,2000,9999,0.4,15,8000
102,GR2,.TRUE.,0.00459,0,0,0.04591,0,2000,1800,9999,1,15,8000
103,GR3,.TRUE.,0.00459,0.01837,0,0.06887,0,1500,1300,9999,2,30,8000
104,GR4,.TRUE.,0.01148,0,0,0.08724,0,2000,1800,9999,2,15,8000
105,GR5,.TRUE.,0.01837,0,0,0.11478,0,1800,1600,9999,1.5,40,8000
106,GR6,.TRUE.,0.00459,0,0,0.15611,0,2200,2000,9999,1.5,40,9000
107,GR7,.TRUE.,0.04591,0,0,0.24793,0,2000,1800,9999,3,15,8000
108,GR8,.TRUE.,0.02296,0.04591,0,0.33517,0,1500,1300,9999,4,30,8000
109,GR9,.TRUE.,0.04591,0.04591,0,0.41322,0,1800,1600,9999,5,40,8000
121,GS1,.TRUE.,0.00918,0,0,0.02296,0.02984,2000,1800,1800,0.9,15,8000
122,GS2,.TRUE.,0.02296,0.02296,0,0.02755,0.04591,2000,1800,1800,1.5,15,8000
123,GS3,.TRUE.,0.01377,0.01148,0,0.06657,0.05739,1800,1600,1600,1.8,40,8000
124,GS4,.TRUE.,0.08724,0.01377,0.00459,0.15611,0.32599,1800,1600,1600,2.1,40,8000
141,SH1,.TRUE.,0.01148,0.01148,0,0.00689,0.05969,2000,1800,1600,1,15,8000
142,SH2,.FALSE.,0.06198,0.11019,0.03444,0,0.17677,2000,9999,1600,1,15,8000
143,SH3,.FALSE.,0.02066,0.13774,0,0,0.28466,1600,9999,1400,2.4,40,8000
144,SH4,.FALSE.,0.03903,0.0528,0.00918,0,0.11708,2000,1800,1600,3,30,8000
145,SH5,.FALSE.,0.16529,0.09642,0,0,0.13315,750,9999,1600,6,15,8000
146,SH6,.FALSE.,0.13315,0.06657,0,0,0.06428,750,9999,1600,2,30,8000
147,SH7,.FALSE.,0.1607,0.24334,0.10101,0,0.15611,750,9999,1600,6,15,8000
148,SH8,.FALSE.,0.09412,0.15611,0.03903,0,0.19972,750,9999,1600,3,40,8000
149,SH9,.TRUE.,0.20661,0.11249,0,0.07117,0.3214,750,1800,1500,4.4,40,8000
161,TU1,.TRUE.,0.00918,0.04132,0.06887,0.00918,0.04132,2000,1800,1600,0.6,20,8000
162,TU2,.FALSE.,0.04362,0.08264,0.05739,0,0.00918,2000,9999,1600,1,30,8000
163,TU3,.TRUE.,0.05051,0.00689,0.01148,0.02984,0.05051,1800,1600,1400,1.3,30,8000
164,TU4,.FALSE.,0.20661,0,0,0,0.09183,2300,9999,2000,0.5,12,8000
165,TU5,.FALSE.,0.18365,0.18365,0.13774,0,0.13774,1500,9999,750,1,25,8000
181,TL1,.FALSE.,0.04591,0.10101,0.16529,0,0,2000,9999,9999,0.2,30,8000
182,TL2,.FALSE.,0.06428,0.1056,0.10101,0,0,2000,9999,9999,0.2,25,8000
183,TL3,.FALSE.,0.02296,0.10101,0.12856,0,0,2000,9999,9999,0.3,20,8000
184,TL4,.FALSE.,0.02296,0.06887,0.19284,0,0,2000,9999,9999,0.4,25,8000
185,TL5,.FALSE.,0.0528,0.11478,0.20202,0,0,2000,9999,1600,0.6,25,8000
186,TL6,.FALSE.,0.11019,0.0551,0.0551,0,0,2000,9999,9999,0.3,25,8000
187,TL7,.FALSE.,0.01377,0.06428,0.3719,0,0,2000,9999,9999,0.4,25,8000
188,TL8,.FALSE.,0.2663,0.06428,0.05051,0,0,1800,9999,9999,0.3,35,8000
189,TL9,.FALSE.,0.30533,0.15152,0.19054,0,0,1800,9999,1600,0.6,35,8000
201,SB1,.FALSE.,0.06887,0.13774,0.50505,0,0,2000,9999,9999,1,25,8000
202,SB2,.FALSE.,0.20661,0.19513,0.18365,0,0,2000,9999,9999,1,25,8000
203,SB3,.FALSE.,0.25253,0.12626,0.13774,0,0,2000,9999,9999,1.2,25,8000
204,SB4,.FALSE.,0.24105,0.1607,0.24105,0,0,2000,9999,9999,2.7,25,8000
256,NB,.FALSE.,0.0001,0,0,0,0,9999,9999,9999,0.01,5,1

The contents of the Input directory are:
adj.tif cbh.tif elmfire.data m100.tif phi.tif.aux.xml
asp.tif cc.tif fbfm40.tif m10.tif slp.tif
ca-creek_20200905_013000.ctl ch.tif fuel_models.csv m1.tif wd.tif
cbd.tif dem.tif ignition_mask.tif phi.tif ws.tif

The contents of the Output directory are:

Copied elmfire.data.in to elmfire.data in the inputs directory.
xmin: 268365.396
xmax: 328365.396
ymin: 4089588.178
ymax: 4149588.178
Extracted geospatial metadata from the fbfm40.tif file.
Calculated the center of the domain as X: 298365.396 and Y: 4119588.178.
Extracted spatial reference system as: +proj=utm +zone=11 +datum=WGS84 +units=m +no_defs and cell size as: 30.000000000000000.
Creating output file that is 200P x 200L.
Processing input file ./inputs/adj.tif.
Using internal nodata values (e.g. -9999) for image ./inputs/adj.tif.
0...10...20...30...40...50...60...70...80...90...100 - done.
0 .. 10 .. 20 .. 30 .. 40 .. 50 .. 60 .. 70 .. 80 .. 90 .. 100 - Done
Set parameters in the elmfire.data file.
ELMFIRE 2023.06
Reading &MISCELLANEOUS namelist group
Reading &INPUTS namelist group
Reading &OUTPUTS namelist group
Reading &COMPUTATIONAL_DOMAIN namelist group
Reading &TIME_CONTROL namelist group
Reading &SIMULATOR namelist group
Reading &WUI namelist group
Reading &CALIBRATION namelist group
Reading &SUPPRESSION namelist group
Reading &SPOTTING namelist group
Reading &SMOKE namelist group
Reading &MONTE_CARLO namelist group
Problem opening fuel model table file /fuel_models.csv
Finished running the ELMFIRE simulation.
The contents of the Output directory are:
ERROR 4: `./outputs/*.bil' does not exist in the file system,
and is not recognised as a supported dataset name.

GDALOpen failed - 4
`./outputs/*.bil' does not exist in the file system,
and is not recognised as a supported dataset name.

Converted ./outputs/.bil to GeoTIFF.
ls: cannot access ./outputs/time_of_arrival.tif: No such file or directory
Usage: gdal_contour [-b ] [-a <attribute_name>] [-3d] [-inodata]
[-snodata n] [-f ] [-i ]
[-f ] [[-dsco NAME=VALUE] ...] [[-lco NAME=VALUE] ...]
[-off ] [-fl ...]
[-nln ] [-q]
<src_filename> <dst_filename>

FAILURE: Missing destination filename.

Hi Chris,

I'm interested in modeling fuel break effectiveness in ELM fire with a single ignition and with random ignitions. Most importantly I am curious about advice on using manipulated landscapes (not from cloudfire) and different weather data.

Thank you,

Andrew

Problem statement

For some use cases, it is valuable to know when (if ever) each fire burns certain spatial locations.

Proposed solution

Example elmfire.data:

& INPUTS
TIMED_LOCATIONS_CSV = 'path/to/my-timed-locations.csv'

...

& OUTPUTS
TIMED_LOCATIONS_EVENTS_CSV = 'path/to/my-timed-locations-events.csv'
...

TIMED_LOCATIONS_CSV is an input CSV listing the points at which timings are required, in EPSG:5070 coordinates:

timed_location_id, x, y
42, 572416.24, 1067098.27
17, 572412.32, 1067091.28
...

The number of rows in this CSV will typically be much smaller than the number of pixels in the landscape, maybe one point every square kilometer or so. timed_location_id is an opaque id for each location, which ELMFIRE will convey unchanged to outputs, making it easier for callers to relate inputs to outputs. Ideally any data type should be allowed, but I guess it's fine to make it, say, a 64 bits integer if that makes the implementation easier for ELMFIRE.

TIMED_LOCATIONS_EVENTS_CSV is an output CSV emitted by ELMFIRE, describing which fire burned which location at what Time-of-Arrival:

icase, timed_location_id, toa_hr
1789, 17, 35.8
1791, 42, 21.12

For example, the 2nd row says that fire number icase=1791 burned location timed_location_id=42 at 21.12 simulated hours from ignition.

Callers should not expect any guarantees on the order of the rows - let them sort them themselves if needed.

Hello,

When running ELMFIRE 2023.06, I'm encountering an error shortly after the run starts.

The error points back to line 1700 of elmfire_io.f90. That line is reading the no data value from the input rasters. I figured that some of my input rasters must not have a no data value set, or that the value was 'n/a', hence "bad real number". I tried to fix this by updating all of my input rasters to ensure they have no data set to -9999 and are in the data type specified in the user guide.

If I traced things back correctly, it looks like the file with the error is wd.tif. Odd because it looks like ws.tif did not encounter this error. ws.tif and wd.tif were identical except wd.tif was converted from int16 to float32. If it helps, the source data is gridMET processed and converted to TIFF using xarray and rioxarray.

Thank you!

via @hohsieh:

Besides what's in the table now, it would be helpful to add other necessary information for sampling (if feasible for the fire model). Currently, only area_max is directly available in the fire size statistics table (a_total). Time info is available as metband (number of hours elapsed since the start of the year in which the fire occurred), which requires additional effort to transform into UTC datetime format.

Additional fields to add: id, starting_timestamp (in UTC), mdot_sum, hrr_max, area_max

The id field in both tables is formatted as <yyyy>_<tile_id>_<fire_id>, for example, 2015_080_010_051383.
Or would it be better to split 'id' into three separate fields: year, tile_id, and fire_id (i.e., icase)?

Hi Chris,
We are trying to use campus cluster to run elmfire. When installing elmfire it requires mpifort, which I believe is parallel computing for fortran. Unfortunately, the campus cluster does not have mpifort installed.
To install mpifort the command that I found is "sudo apt install mpich". But obviously we do not have sudo access for campus cluster.

What is the best way to solve it?

Hi Chris,

I updated the spotting model on my end and tried incorporating the HRR_transient into it.

However, when I run a test case with the Eulerian spotting model activated (using the command elmfire elmfire.data), it shows "segmentation fault ..." while outputting results. The results are correct regardless.

Meanwhile, when I run the case using the command elmfire_debug elmfire.data, it informs me something went wrong with lines 5 and 58 in "elmfire.f90" (suggesting: "Floating-point exception - erroneous arithmetic operation."), without outputting any results.

This problem only occurs when I run with my spotting model.

Could you please help me check it out or give me some suggestions on finding out what is wrong? I have attached the test version of ELMFIRE and my test input files here. Please let me know if you need any further clarification.
elmfire_public-UMD_SPOTTING_MODEL.zip
spotting-test-inputs.zip

Thanks,
Yiren

I'm trying to set up the latest version of elmfire with Visual Studio Code, but I'm encountering an error during validation (01-single-fire/01-ca_county.sh). I have attempted debugging and made configurations, as well as installed and launched dotnet and Node.js, but I keep receiving the same error message each time.

I have provided the "01-ca_county.sh" and "template.sh" files for you to review. It seems that the script is attempting to remove the "ca-county_20180701_062200" before creating it (I even tried creating the "ca-county" folder manually).

Error: Specify job launch JSON strong
mv: cannot stat '$ELMFIRE_BASE_DIR/elmfire/runs/hindcasts/runs/ca-county/ca-county_20180701_062200': No such file or directory

These are the "01-ca_county.sh" and "template.sh" files respectively:

#!/bin/bash

Specify inputs below:

YEAR=2018
FIRENAME=ca-county
ACTIVE_FIRE_TIMESTAMP_NUM=1
ALREADY_BURNED_TIMESTAMP_NUM=null
WEST_BUFFER=30
SOUTH_BUFFER=30
EAST_BUFFER=30
NORTH_BUFFER=30
NUM_ENSEMBLE_MEMBERS=100
RUN_HOURS=48
FUEL_SOURCE=landfire
FUEL_VERSION=1.4.0
RUN_TEMPLATE=hindcast

export USE_SLURM=no
export CALC_FITNESS=yes

No need to modify from here down:

cp -f ../template.sh ./run.sh
rm -f -r ./$FIRENAME*

./run.sh $YEAR $FIRENAME $ACTIVE_FIRE_TIMESTAMP_NUM
$ALREADY_BURNED_TIMESTAMP_NUM
$WEST_BUFFER $SOUTH_BUFFER $EAST_BUFFER $NORTH_BUFFER
$NUM_ENSEMBLE_MEMBERS $RUN_HOURS $FUEL_SOURCE $FUEL_VERSION
$RUN_TEMPLATE

rm -f ./run.sh

exit 0

#!/bin/bash

YEAR=$1
FIRENAME=$2
ACTIVE_FIRE_TIMESTAMP_NUM=$3
ALREADY_BURNED_TIMESTAMP_NUM=$4
WEST_BUFFER=$5
SOUTH_BUFFER=$6
EAST_BUFFER=$7
NORTH_BUFFER=$8
NUM_ENSEMBLE_MEMBERS=$9
RUN_HOURS=${10}
FUEL_SOURCE=${11}
FUEL_VERSION=${12}
RUN_TEMPLATE=${13}

export USE_SLURM=${USE_SLURM:-'no'}

CWD=$(pwd)

if [ -z "$FIRENAME" ]; then
echo "Error: specify fire name"
exit 1
fi

AVAILABLE_POLYGONS_CLI=$ELMFIRE_BASE_DIR/cloudfire/available_polygons.py

ACTIVE_FIRE_TIMESTAMP=$AVAILABLE_POLYGONS_CLI --list 'timestamps' \ --active=False --year=$YEAR --firename="$FIRENAME" | \ head -n $ACTIVE_FIRE_TIMESTAMP_NUM

if [ -z "$ALREADY_BURNED_TIMESTAMP_NUM" ] || [ "$ALREADY_BURNED_TIMESTAMP_NUM" = "null" ]; then
ALREADY_BURNED_TIMESTAMP=null
else
ALREADY_BURNED_TIMESTAMP=$AVAILABLE_POLYGONS_CLI --list 'timestamps' \ --active=False --year=$YEAR --firename="$FIRENAME" | \ head -n $ALREADY_BURNED_TIMESTAMP_NUM
fi

YYYYMMDD=echo $ACTIVE_FIRE_TIMESTAMP | cut -d_ -f1
HHMMSS=echo $ACTIVE_FIRE_TIMESTAMP | cut -d_ -f2
HH=${HHMMSS:0:2}
MM=${HHMMSS:2:2}
IGNITION_TIME="$YYYYMMDD $HH:$MM UTC"

ARGS='{
"fireName": "'$FIRENAME'",
"initializationType": "'active_fire_polygon'",
"activeFireTimestamp": "'$ACTIVE_FIRE_TIMESTAMP'",
"alreadyBurnedTimestamp": "'$ALREADY_BURNED_TIMESTAMP'",
"ignitionTime": "'$IGNITION_TIME'",
"westBuffer": '$WEST_BUFFER',
"southBuffer": '$SOUTH_BUFFER',
"eastBuffer": '$EAST_BUFFER',
"northBuffer": '$NORTH_BUFFER',
"numEnsembleMembers": '$NUM_ENSEMBLE_MEMBERS',
"addToActiveFires": "'no'",
"runHours": '$RUN_HOURS',
"fuelSource": "'$FUEL_SOURCE'",
"fuelVersion": "'$FUEL_VERSION'",
"scpInputDeck": "'none'",
"returnAfterQueue": "'no'",
"runTemplate": "'$RUN_TEMPLATE'"
}'

cd $ELMFIRE_BASE_DIR/runs/hindcasts
rm -f -r ./runs/$FIRENAME/${FIRENAME}_$ACTIVE_FIRE_TIMESTAMP

./01-crs.sh "$ARGS"

mv $(pwd)/runs/$FIRENAME/${FIRENAME}_$ACTIVE_FIRE_TIMESTAMP $CWD/

exit 0

We need 3 new output rasters consisting: HRR of the burning cells and heat from direct flame contact and radiation received by the cells

Hi Chris,

In an attempt to compute burn probability, I defined CALCULATE_BURN_PROBABILITY = .TRUE. in the elmfire.data.in file of tutorial 04 together with a few other configurations. No errors occurred but the burn_probability.tif file was not created. Only head_fire_flame_length and head_fire_spread_rate files were generated.
I am attaching the elmfire.data.in file that I used.
For running, I used just the ./01-run.sh command of Tutorial 04: Landscape-scale fire potential.

elmfire_data_in.txt

There is an error in the script that i change lat & long of fuel data the simulation process fail and doesn't work

I tried without using any urban model first, but it didn't give me any .tif outputs. It run, but the only output are spotting outputs in csv files. The error message is that no .bin, .bil, .hdr files are found, which means that those files are not created during the simulation unlike the older version.

I tried to disable the perturbation by making the lower and upper bound to be equal. But when I try to do repetitions, the outputs are still different. How to make the outputs to be equal when we repeat simulations?
Attached is the input decks and the outputs that I get.
https://drive.google.com/file/d/1n7ORrwuOdYdwQhtmF1Qq6HTUsa_Jfsuk/view?usp=sharing

Use case: in a PiRPLO-ish context, estimate variations in total runtime as we consider various distributions of fire durations, without having to rerun simulation.

This would just add a column runtime to burned-acres-timings.csv, with the same semantics and units as the one in fire_size_stats.csv.

Hi Chris,

I've utilized the most recent edition of elmfire for Kincade and have enclosed the results for your evaluation. I attempted to incorporate the suppression algorithm into the elmfire.data and also experimented with the adjusted fuel. However, I'm uncertain about the steps to modify the 01-run.sh for a re-run. Your assistance with this matter would be greatly appreciated. Thanks!

Best,
Maryam

I tried using

IF ((LB_P%IX .LT. IX_LOW_BORDER) .OR. (LB_P%IY .LT. IY_LOW_BORDER) .OR. (LB_P%IX .GT. IX_HIGH_BORDER) .OR. (LB_P%IY .GT. IY_HIGH_BORDER)) THEN
CYCLE
ENDIF

instead of

IF ((LB_P%IX .GE. IX_LOW_BORDER) .AND. (LB_P%IY .GE. IY_LOW_BORDER) .AND. (LB_P%IX .LE. IX_HIGH_BORDER) .AND. (LB_P%IY .LE. IY_HIGH_BORDER)) THEN
.
.
.
ENDIF

to limit the effect of radiation and DFC.

But the results are different. I expect them to be the same since I believe they are doing the same thing

Hi Chris,

I tried using cluster for running ELMFIRE. It works when not using MPIRUN, but it doesn't when using MPIRUN. No error message is shown.

As the current status:
MPIRUN works fine when running normally (./01-run.sh) but doesn't work when using cluster (sbatch).
Not using MPIRUN works for both.

When running normally (the one we did in the meeting), we can only use 10 cores, so not good.

Hi Chris,

Sorry for the late post. As discussed before, when I apply uniform fuel type (102) and constant wind speed (north to south, 15 mph), the fireline intensity is not uniform when I activate the spotting model. When I deactivate the spotting model, this issue of non-uniform occurs at the boundaries of the simulation region.
I suspect that it could be a problem due to my enforcing the value of the level-set variable at spotting ignited pixels to be -1 at every time step. Because it happens at the boundary in the no-spotting cases where the level-set variable is also enforced to be -1. But I am not sure how exactly it could impact the fireline intensity calculation.
I attached the input files I used to run the cases with/without spotting. I pulled the newest version of ELMFIRE and used it to test the cases.test_cases.zip

Thanks,
Yiren