Prescribed Burned Area idea

[rosiealice]

Hi all,

I am wondering if anyone has given any thought to having prescribed burned area - where we overwrite the burned area calculations in SPITFIRE with some sort of external forcing (like GFED). This is a similar idea to the reduced complexity approach that we use already for LAI and PFT are, but just for fire... Wwe have a project where we have plans to work on this, but I think it's possible for use to be more ambitious about how we implement it if there are other people interested.

One issue that immediately arises when you think about this is that our existing means of prescribing drivers is a climatology (for FATES-SP mode) and in principle it would be good (given the IAV of fires) to be able to have this be more like a 'stream' type field.

@adrifoster I remember you saying once you had been thinking about how to do that for SP mode. Did you ever figure out how to manage that?

Anyway, this is really a placeholder to see if anyone else is thinking about and similar types of implementation (either of fires or of other time-varying inputs) and/or discuss what the right conceptual model is for the implementation of this approach. Maybe we should mirror, for example, how the transient land use information is read and passed into FATES?

Tagging @zosiast who is also working on this project at CICERO...

[ckoven]

Hi Rosie, we are currently writing this into a proposal as a task. So yes, particularly if that gets funded. One question is how to do the patch-level downscaling of the prescribed burned area, particularly as relates to the patch-level yes/no gate on minimum combustion energy. If you leave the gate then you run into the possibility that you have no patches into which to distribute the fire, if you don't then you'll always have some amount of patch-level predicted burned area that you could use to distribute the prescribed burned area across, though it is possible that doing that might bias the fire intensity. Anyway, yes, lots to think about re how to do this best.

[rosiealice]

Cool (on the proposal). Maybe we might burn the patches in order or or weighted by their predicted fire intensity? Even if they didn't get over the threshold?

[ekluzek]

This sounds like a cool idea to me too. I'm mainly wondering about implementation though. Would this be something where the HLM provides prescribed fire to FATES? Or where FATES reads the dataset and it happens there?

Both ways have advantages. In general I would like to support a solution that makes it easy to do this type of thing any time it might be wanted. And this is something useful for a ton of si to ferwnt things.

For CTSM I've been supporting doing this sort of things with our stream implementation. Which gets us away from using custom code and having built in flexibility from the get go. E3SM has streams as well, but implemented differently with MCT rather than CDEPS.

So I'm hoping if this is done we'd do a similar solution that doesn't use custom code for only a single purpose. And if there is code in FATES (so it could be shared across HLM's) that it would be done with a general kind of stream reader as well.

Just throwing out some thoughts on design to think about as this is thought about and planned.

[lmkueppers]

Doing this consistent without custom code seems good to me. Do the ignition datasets get read through HLM streams or straight to FATES? When we created the prescribed ignition (not fire area but observed fire) I think it came through the HLM because the CLM ignition climatology was already read and passed to FATES (I think you might have helped with that Erik?). In any case, I was thinking the ignition mode could be used. Right now there are multiple modes, including one that is tied to observed fires. One could just expand that to create a mode that reads the area instead of an ignition probability. One other semantic thing: Xiulin developed a new "prescribed fire" scheme that is intended to represent a dynamic implementation of intentional fire that has parameters controlling fire size (i.e., a prescribed burned area). To avoid confusion, I'd suggest calling this new "prescribed burned area" something else, like "observed burned area" or "data burned area" or ... Lara

On 5/19/26 3:03 PM, Erik Kluzek wrote: *ekluzek* left a comment (NGEET/fates#1570) <#1570 (comment)> This sounds like a cool idea to me too. I'm mainly wondering about implementation though. Would this be something where the HLM provides prescribed fire to FATES? Or where FATES reads the dataset and it happens there? Both ways have advantages. In general I would like to support a solution that makes it easy to do this type of thing any time it might be wanted. And this is something useful for a ton of si to ferwnt things. For CTSM I've been supporting doing this sort of things with our stream implementation. Which gets us away from using custom code and having built in flexibility from the get go. E3SM has streams as well, but implemented differently with MCT rather than CDEPS. So I'm hoping if this is done we'd do a similar solution that doesn't use custom code for only a single purpose. And if there is code in FATES (so it could be shared across HLM's) that it would be done with a general kind of stream reader as well. Just throwing out some thoughts on design to think about as this is thought about and planned. — Reply to this email directly, view it on GitHub <#1570 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEVGJJKDSIS5I7BCGRTPNH343TK27AVCNFSM6AAAAACZCVQO66VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DIOJSGQZDINZWHE>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Lara M. Kueppers Associate Professor, Energy & Resources Group, UC Berkeley Faculty Scientist, Climate and Ecosystem Sciences Division, Berkeley Lab 510.457.6524

[rosiealice]

Thanks @lmkueppers :)

On the naming convention, I agree that the overlap with @XiulinGao 's scheme contains the opssibility for substantial confusion! 'Observed burned area' sounds good. As does using the existing fire switch scheme...