New Output Rasters

[dwimjpurnomo]

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

[lautenberger]

Dwi- what are the variable names for each of these three outputs?

[dwimjpurnomo]

Hi Chris, I have pulled request to accommodate the new output rasters required. The variable names:

C%TOTAL_DFC_RECEIVED, C%TOTAL_RAD_RECEIVED, C%HRR_TRANSIENT

[lautenberger]

@dwimjpurnomo I merged your PR and then added the above three outputs, see https://github.com/lautenberger/elmfire/commit/e185747758ec2fcf47780ec95ce00d971258832d. These outputs can be activated from the &OUTPUTS namelist group with the keywords DUMP_TOTAL_DFC_RECEIVED, DUMP_TOTAL_RAD_RECEIVED, and DUMP_HRR_TRANSIENT. Please test them out and see if they're working as expected.

[dwimjpurnomo]

Thank you, Chris.

I have checked. For HRR_TRANSIENT, it is working. Its just it gives the value from 0 - 255. This range can be normalized to 0 - peak HRR. For DFC and RAD outputs, they give raster outputs but don't give any value, like its all 0.

Best,

Dwi

Regards Dwi Marhaendro J Purnomo

On Sat, 15 Jul 2023 at 16:43, Chris Lautenberger @.***> wrote:

@dwimjpurnomo https://github.com/dwimjpurnomo I merged your PR https://github.com/lautenberger/elmfire/pull/22 and then added the above three outputs, see e185747 https://github.com/lautenberger/elmfire/commit/e185747758ec2fcf47780ec95ce00d971258832d. These outputs can be activated from the &OUTPUTS namelist group with the keywords DUMP_TOTAL_DFC_RECEIVED, DUMP_TOTAL_RAD_RECEIVED, and DUMP_HRR_TRANSIENT. Please test them out and see if they're working as expected.

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

[lautenberger]

@dwimjpurnomo I think I know the problem (or at least part of the problem). This is the code in elmfire_io.f90 that writes the DFC raster:

IF (DUMP_TOTAL_DFC_RECEIVED) THEN
   RDUMPME%R4(:,:,:) = RDUMPME%NODATA_VALUE
   C => LIST_BURNED%HEAD
   DO I = 1, LIST_BURNED%NUM_NODES
      RDUMPME%R4(C%IX,C%IY,1) = C%TOTAL_DFC_RECEIVED
      C => C%NEXT
   ENDDO
   FN = 'total_dfc_received_' // SEVEN // '_' // CTSEC
   CALL WRITE_BIL_RASTER(RDUMPME,OUTPUTS_DIRECTORY,FN,CONVERT_TO_GEOTIFF,.TRUE.)
   FNS_TOTAL_DFC_RECEIVED(IDUMPCOUNT) = TRIM(FN)
ENDIF

It's looping over the list of burned nodes to populate a 2D array before writing that to disk, but it should probably be looping over the building list (LB). Can you try replacing LIST_BURNED in the above loop (and the one for RAD too) with LB to see if that fixes it? Also, I think we need to change the variable name LB so that it's not confused with LIST_BURNED, if you agree can you come up with a more descriptive variable name and submit a PR? Thank you.

If this doesn't fix it, I recommend checking if C%TOTAL_DFC_RECEIVED and C%TOTAL_RAD_RECEIVED are being populated correctly or are being set to all zeros. Try putting a breakpoint after lines 386 / 387 in elmfire_spread_rate.f90 so you can check the values of TOTAL_DFC and TOTAL_RADIATION:

C%TOTAL_DFC_RECEIVED = TOTAL_DFC
C%TOTAL_RAD_RECEIVED = TOTAL_RADIATION

[lautenberger]

After merging PR https://github.com/lautenberger/elmfire/pull/24 it's now lines 405 / 406, BTW

[dwimjpurnomo]

Hi Chris, in elmfire.io for RAD and DFC it should be LIST_TAGGED instead of LIST_BURNED. After changing that I got the results. However, it only has a value of 255, the same as HRR, which is not expected

[lautenberger]

This sounds like a data type issue - can you run gdalinfo -stats on one of the output rasters and past that output here?

[dwimjpurnomo]

it is byte. Its supposed to be floating point

[lautenberger]

Yup, that's what I expected. Is that from a .bil file written by ELMFIRE or a .tif file after it's been converted with gdal_translate? ELMFIRE only outputs Int16 and Float32 rasters so it may happening in the post-processing step where the .bil files are converted to GeoTiff.

[dwimjpurnomo]

They are from .tif files. The raw file was .bil and .hdr (not .bin)

[lautenberger]

What does gdalinfo -stats output for the .bil files?

[dwimjpurnomo]

Its Band 1 Block=700x1 Type=Float32, ColorInterp=Undefined NoData Value=-9999

[dwimjpurnomo]

What does Block mean here?

[lautenberger]

I think the block size only matters when working with Cloud Optimized Geotiffs (COGs), see https://www.kitware.com/deciphering-cloud-optimized-geotiffs/ for example.

Since the .bil files coming out of ELMFIRE are Float32 but the GeoTiffs files are Byte, the problem is in the post-processing step. Check your post-processing script, there's probably a line like gdal_translate -ot Byte and if you delete the "-ot Byte" it will create Float32 GeoTiffs as intended.

[dwimjpurnomo]

Yes. It works as expected now.

[lautenberger]

Glad it's working, closing this issue.