search

lautenberger / elmfire

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

New input raster for UCB model #1

Closed dwimjpurnomo closed 1 year ago

dwimjpurnomo commented 1 year ago

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

lautenberger commented 1 year ago

Hi Dwi- I'll need more specifics, please provide a description of each raster so that I can use appropriate variable names and input keywords. Thank you!

dwimjpurnomo commented 1 year ago

Hi Chris,

It would be REAL: Peak HRR (HRR_PEAK), FTP per area (FTP_PA), DFC coefficient (DFC_COEFF), radiation coefficient (RAD_COEFF) INTEGER: 3 time constants = early stage (EARLY_TIME), fully developed (DEVELOPED_TIME), decay (DECAY_TIME).

Please let me know if this information is not enough.

Regards Dwi Marhaendro J Purnomo

On Fri, 14 Apr 2023 at 16:55, Chris Lautenberger @.***> wrote:

Hi Dwi- I'll need more specifics, please provide a description of each raster so that I can use appropriate variable names and input keywords. Thank you!

— Reply to this email directly, view it on GitHub https://github.com/lautenberger/elmfire/issues/1#issuecomment-1509402693, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJC32S7DPA2G53RDIFJC73TXBHPW7ANCNFSM6AAAAAAW667WDQ . You are receiving this because you authored the thread.Message ID: @.***>

lautenberger commented 1 year ago

@dwimjpurnomo In addition to the above, don't we also need building area and separation distance?

@yqin123 I believe we would also need a raster for BLDG_FOOTPRINT_FRAC?

dwimjpurnomo commented 1 year ago

Hi Chris,

We already have them, no?

Best,

Dwi

On Fri, 28 Apr 2023, 08:53 Chris Lautenberger, @.***> wrote:

@dwimjpurnomo https://github.com/dwimjpurnomo In addition to the above, don't we also need building area and separation distance?

@yqin123 https://github.com/yqin123 I believe we would also need a raster for BLDG_FOOTPRINT_FRAC?

— Reply to this email directly, view it on GitHub https://github.com/lautenberger/elmfire/issues/1#issuecomment-1527764202, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJC32SYT6IVZVTDWSBPKU7LXDPRW3ANCNFSM6AAAAAAW667WDQ . You are receiving this because you were mentioned.Message ID: @.***>

yqin123 commented 1 year ago

@lautenberger Hi Chris, Yes, it would be great if you could add a raster for BLDG_FOOTPRINT_FRAC.

@dwimjpurnomo In addition to the above, don't we also need building area and separation distance?

@yqin123 I believe we would also need a raster for BLDG_FOOTPRINT_FRAC?

lautenberger commented 1 year ago

@dwimjpurnomo regarding input rasters for urban/WUI spread, ELMFIRE currently has rasters for Hamada model inputs - HAMADA_A, HAMADA_D, and HAMADA_FB for area, separation distance, and burnable fraction respectively.

However, I would like to make this more general and rename them BLDG_AREA, BLDG_SEPARATION_DIST, BLDG_NONBURNABLE_FRAC or similar and also create a new namelist group - probably named &URBAN or &WUI - for all of the urban/WUI inputs. So I think that means our updated list of WUI/urban spread rasters is:

@dwimjpurnomo I wasn't sure if the above rasters HRR_PEAK, FTP_PA, DFC_COEFF, RAD_COEFF, EARLY_TIME, DEVELOPED_TIME, and DECAY_TIME are INPUTS or rather intermediate quantities that are calculated at run time? They look to me like they're not inputs but I thought I'd check.

dwimjpurnomo commented 1 year ago

Hi Chris,

At the moment, the model still need input of HRR etc as inputs, such as from FDS simulation. So they are not calculated when we run elmfire.

Best,

Dwi

On Mon, 1 May 2023, 10:58 Chris Lautenberger, @.***> wrote:

@dwimjpurnomo https://github.com/dwimjpurnomo regarding input rasters for urban/WUI spread, ELMFIRE currently has rasters for Hamada model inputs

  • HAMADA_A, HAMADA_D, and HAMADA_FB for area, separation distance, and burnable fraction respectively.

However, I would like to make this more general and rename them BLDG_AREA, BLDG_SEPARATION_DIST, BLDG_NONBURNABLE_FRAC or similar and also create a new namelist group - probably named &URBAN or &WUI - for all of the urban/WUI inputs. So I think that means our updated list of WUI/urban spread rasters is:

  • BLDG_AREA: Input. Average area of building in a pixel (sq m)
  • BLDG_SEPARATION_DIST: Input. Separation distance between buildings (m). This is a function of wind direction so it will be a 3D array where the "z" index corresponds to wind direction bin
  • BLDG_NONBURNABLE_FRAC: Input. Fraction of buildings that are nonburnable, this is a holdover from the Hamada model

@dwimjpurnomo https://github.com/dwimjpurnomo I wasn't sure if the above rasters HRR_PEAK, FTP_PA, DFC_COEFF, RAD_COEFF, EARLY_TIME, DEVELOPED_TIME, and DECAY_TIME are INPUTS or rather intermediate quantities that are calculated at run time? They look to me like they're not inputs but I thought I'd check.

— Reply to this email directly, view it on GitHub https://github.com/lautenberger/elmfire/issues/1#issuecomment-1530015287, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJC32S7EMLAJCHJB3TMRQVTXD72UNANCNFSM6AAAAAAW667WDQ . You are receiving this because you were mentioned.Message ID: @.***>

lautenberger commented 1 year ago

@dwimjpurnomo I don't think it makes sense to specify HRR directly as a raster input as that would require a 30 m resolution multiband raster to account for the temporal nature of HRR - too much memory and i/o overhead.

I'd prefer an approach similar to how surface fuel models are used to look up parameters for the Rothermel model. You could define different building HRR archetypes - analogous to fuel models - and then hit a lookup table to get HRR(t) for that particular building archetype. The HRR curve could be specified by a &RAMP function similar to FDS or as a csv file, for example. With this approach, the necessary raster input becomes an integer HRR archetype code, analogous to a fuel model, plus a specification of HRR(t) (and possibly other parameters) for each archetype. Let's discuss this in our meeting later today.

lautenberger commented 1 year ago

@dwimjpurnomo @yqin123 I created the branch urban-spread-inputs for this work. Here's where things currently are:

Five raster inputs have been added to the &INPUTS namelist group:

  1. BLDG_AREA_FILENAME: Building area (sq m), formerly HAMADA_A. Float32 data type.
  2. BLDG_FOOTPRINT_FRAC_FILENAME: Fraction of a pixel occupied by buildings (new input). Float32 data type.
  3. BLDG_FUEL_MODEL_FILENAME: Building fuel model (new input). Int16 data type.
  4. BLDG_NONBURNABLE_FRAC_FILENAME: Fraction of nonburnable buildings (formerly HAMADA_FB) Float 32 data type.
  5. BLDG_SEPARATION_DIST_FILENAME: Separation distance between buildings (m), formerly HAMADA_D. Float32 data type. Note that this should eventually be made a function of wind direction.

Are any additional raster inputs needed?

A new namelist group &WUI has been created:

&WUI
BLDG_AREA_CONSTANT                    = 20.0
BLDG_SEPARATION_DIST_CONSTANT         = 10.0
BLDG_NONBURNABLE_FRAC_CONSTANT        = 0.0
BLDG_FOOTPRINT_FRAC_CONSTANT          = 1.0
BLDG_FUEL_MODEL_CONSTANT              = 1
BLDG_SPREAD_MODEL_TYPE                = 1
USE_BLDG_SPREAD_MODEL                 = .FALSE.
USE_CONSTANT_BLDG_SPREAD_MODEL_PARAMS = .TRUE.

To enable the building spread model functionality, set USE_BLDG_SPREAD_MODEL = .TRUE.. The keyword BLDG_SPREAD_MODEL_TYPE specifies which model to use. Let's assume that BLDG_SPREAD_MODEL_TYPE = 1 is the Hamada model and BLDG_SPREAD_MODEL_TYPE = 2 is the UCB / UMD model currently under development.

If USE_BLDG_SPREAD_MODEL = .TRUE.., ELMFIRE will read in the five &INPUT rasters in the first paragraph above unless USE_CONSTANT_BLDG_SPREAD_MODEL_PARAMS = .TRUE.. In that case, ELMFIRE will use BLDG_AREA_CONSTANT, BLDG_SEPARATION_DIST_CONSTANT, etc. in lieu of reading in rasters.

For the UMD/UCB building spread model, several parameters that characterize structure flammability characteristics are needed. The file containing these inputs is specified by the BUILDING_FUEL_MODEL_FILE keyword on the &MISCALLANEOUS namelist group, e.g. BUILDING_FUEL_MODEL_FILE = 'building_fuel_models.csv'. This is a headerless CSV file that is parsed with the following READ statement:

READ(LUINPUT,*,IOSTAT=IOS) INUM,SHORTNAME,T_1MW,T_EARLY,T_FULLDEV,T_DECAY,FUEL_LOAD,HRRPUA_PEAK,FTP_CRIT,ABSORPTIVITY,HEIGHT,NONBURNABLE_FRAC

In column order, the inputs are: INUM: Building fuel model number, assumed to be between 0 and 100. Integer. SHORTNAME: Fuel model description, e.g. 'Single level 2000 sq ft residence'. String (80 chars). T_1MW: Time to 1 MW HRRR (s). Float32. T_EARLY: 'Early' time constant (s). Float32. T_FULLDEV: 'Fully developed' time constant. Float32. T_DECAY: 'Decay' time constant (s). Float32. FUEL_LOAD: Fuel load (MJ/m2?). Float32. HRRPUA_PEAK: Peak heat release rate (MW). Float32. FTP_CRIT: Critical flux time product (MJ/m2?). Float32. ABSORPTIVITY: Integrated radiative absorptivity (-). Float32. HEIGHT: Building height (m). Float32. NONBURNABLE_FRAC: Building nonburnable fraction (-), may be redundant with analogous raster input. Float32.

The columns in the building fuel model file can easily be adjusted so let me know if there are other parameters that will be needed or some of the above that are not needed.

lautenberger commented 1 year ago

Merged into main.