lautenberger / elmfire

Eulerian Level set Model of FIRE spread
https://elmfire.io
Eclipse Public License 2.0
23 stars 11 forks source link

Add more fields to fire size and smoke output #6

Closed fitnr closed 1 year ago

fitnr commented 1 year ago

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)?

lautenberger commented 1 year ago

@hohsieh In the smoke-metadata branch I've added a fuel fields to fire_size_stats.csv. Here's a snapshot:

image

I did not add area_max since that already exists (as column surface fire area).

Units: To avoid working with very large numbers, I'd prefer units of MW or GW for HRR and units of g or kg for PM 2.5 release.

In the individual smoke .csv files, should the time column be time relative to ignition (in seconds, minutes, or hours?) or a UTC time stamp? For generality, I would prefer elapsed time as opposed to a UTC timestamp since it will be common to run simulations that don't necessarily have a real-world start time.

hohsieh commented 1 year ago

Thanks @lautenberger. I prefer UTC time because that's currently how I use the elapsed time (to get the UTC timestamp for stratified sampling based on the year-month of the fires). Inputs for HYSPLIT are UTC time, too. Are you using the individual smoke .csv file for running simulations or other works? If there are reasons elapsed time would be better, I do have a workflow to transform elapsed time to UTC (modified from your post-process script).

lautenberger commented 1 year ago

Re: time column in smoke outputs - sounds like there's a need to have both elapsed time and absolute time / UTC timestamp across different ELMFIRE use cases. So what I'm thinking is that rather than adding a configuration option to the &SMOKE namelist group to write one type of timestamp or the other, that it would be preferable to include two time columns in the smoke .csv files:

  1. Elapsed time in hours, and
  2. UTC timestamp

For simulations that are run without specifying a particular year and start time - which is a lot of simulations, including those under synthetic wind/weather conditions - the UTC timestamp could just begin at the Unix epoch, 1970-01-01 00:00:00.

hohsieh commented 1 year ago

That sounds good. Are there fires running without a particular year and start time in the v2 current and future runs? I only see fires starting from 2011 UTC in v2 fires. To run those fires in HYSPLIT, what years of weather data should I use (1970 January)?

fitnr commented 1 year ago

@lautenberger Could you also add the icase to the smoke output? It's currently present in the file name, but it would be easier to have it in the file itself.

lautenberger commented 1 year ago

This is complete as of commit 7a11cbcf6d19d3e1c41d7bf4da940c1eca0dd874. @fitnr this is the updated header for fire_size_stats.csv:

image

Note the units of HRR Peak are in MW.

Smoke outputs now look like this:

image

Note the addition of column B - timestamp. Additionally HRR is now in units of MW and area in units of ha.

I'd prefer to not have icase in the smoke outputs since it's static and not changing temporally.

fitnr commented 1 year ago

The icase value may be static within one run, but we're interested in collecting all of the data from many runs into one database. That makes it a useful identifier as part of a multi-column primary key.

fitnr commented 1 year ago

Also, is it correct that the area column in the smoke outputs is in hectares, and the area columns in fire_size_stats are in acres?

lautenberger commented 1 year ago

Yes, previously the smoke outputs had area in units of sq m, now that's multiplied by 0.0001 to give hectares