activating BLAZE part way through a run sequence

[har917]

The BLAZE fire module (developed with a requirement for POP to be active, so requires multiple spin up sections) operates in two main areas of the code - climate (to calculate fire weather metrics and fire climatologies) and carbon cycle (CNP, POP).

Conceptually, with the current implementation, there is an unwanted potential that either

• if BLAZE is activated during the spin up of any run, we lose all vegetation/prevent creation of vegetation
• if BLAZE is not active during the spin up, BLAZE cannot be subsequently reactivated since the climate metrics aren't available in the associated restart file (climate_rst.nc).

We need to follow this through and determine whether we need to add capability/change existing capability to break this catch-22.

@har917 to discuss with @nierad

[nierad]

In LPJ-GUESS BLAZE is turned off during spinup for the first 200 years. And with "turned off" I mean it is skipped for that exact reason.
I have no idea how long the spinup for CABLE/CASA normally takes but having a few generations of trees (100 yrs) grown without fires and then switch it on seems a reasonable thing to do.

[har917]

@nierad @ccarouge @juergenknauer your opinion/preference on this one.

So to facilitate the coupling of BLAZE to CASA-POP part way through a CABLE-POP/BIOS sequence we need another logical switch - so one to trigger the initialisation of BLAZE variables and, notably, evaluate the running climate vars, and one to trigger the BLAZE module itself (two stages here in fact - i) run BLAZE with no coupling to CASA and ii) run with coupling)

Should we go with

1. convert cable_user%BLAZE to an INTEGER TYPE and have 0 - off entirely, 1 - run the climate part only, 2 - run the BLAZE but no coupling, 3 - run BLAZE with coupling to POP and CASA.
2. create a new LOGICAL switch(es) and change the logic to from IF (cable_user%BLAZE) to IF( ( cable_user%BLAZE) .and. (cable_user%couple_BLAZE) )

I suspect that 1. is more robust to future development needs but is less intuitive to the novice code reader.

[juergenknauer]

I think option 1 would work well, but we'd need to make sure that it's documented well in both the namelist and the code. Probably even every time it occurs in the code.

THinking about it from a user's perspective: option 2 could be confusing if BLAZE is not coupled to CASA despite having cable_user%BLAZE = .true. Might be better to cover all cases in one flag (i.e. go with option 1).

[nierad]

Hi all, yes, I agree, option 1 looks good. Re documentation: Yes, also in blaze.nml. Cheers, Lars

…

________________________________ Von: Juergen Knauer ***@***.***> Gesendet: Dienstag, 4. Februar 2025 06:01 An: CABLE-LSM/CABLE ***@***.***> Cc: Lars Nieradzik ***@***.***>; Mention ***@***.***> Betreff: Re: [CABLE-LSM/CABLE] activating BLAZE part way through a run sequence (Issue #529) I think option 1 would work well, but we'd need to make sure that it's documented well in both the namelist and the code. Probably even every time it occurs in the code. THinking about it from a user's perspective: option 2 could be confusing if BLAZE is not coupled to CASA despite having cable_user%BLAZE = .true. Might be better to cover all cases in one flag (i.e. go with option 1). — Reply to this email directly, view it on GitHub<#529 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJA4D366MPWZ7SXIR5UPDLL2OBCS5AVCNFSM6AAAAABVGDZZUWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMZSHA4DGNZZG4>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[ccarouge]

I agree that option 1 seems better unless there are already existing options in CABLE we could combine with a BLAZE option to cover some of the cases. But that seems unlikely.