set fire event priority to happen after regen

[achubaty]

the current workraound, to start fires at start(sim) + 1, is hacky and non-obvious.

how is this handled in fireSense? if it's not implemented in either, implement and ensure they are consistent.

[achubaty]

from scfm burn event:

sim <- scheduleEvent(sim, time(sim) + P(sim)$returnInterval, "scfmSpread", "burn", eventPriority = 7.5)

Biomass_regen is using:

sim <- scheduleEvent(sim, time(sim) + P(sim)$fireTimestep, "Biomass_regeneration", "fireDisturbance", eventPriority = 3)

and note that:

eventPriority | A numeric specifying the priority of the event. Lower number means higher priority. As a best practice, it is recommended that decimal values are conceptual grouped by their integer values (e.g., 4.0, 4.25, 4.5 are conceptually similar).

so regen is being prioritized before fire in a given year

[SteveCumming]

Perhaps a more general solution to this would be to have some global variables that corresponded to seasons ... e.g. priority = winter, spring summer or fall. That way,developers would need too much to worry about what specific numerical values other modules were using.

…

On Tue, Mar 8, 2022 at 6:55 PM Alex Chubaty ***@***.***> wrote: from scfm burn event: sim <- scheduleEvent(sim, time(sim) + P(sim)$returnInterval, "scfmSpread", "burn", eventPriority = 7.5) Biomass_regen is using: sim <- scheduleEvent(sim, time(sim) + P(sim)$fireTimestep, "Biomass_regeneration", "fireDisturbance", eventPriority = 3) and note that: eventPriority | A numeric specifying the priority of the event. Lower number means higher priority. As a best practice, it is recommended that decimal values are conceptual grouped by their integer values (e.g., 4.0, 4.25, 4.5 are conceptually similar). so regen is being prioritized before fire in a given year — Reply to this email directly, view it on GitHub <#24 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABXH6O4INSKSKINQDYS44DTU67SGJANCNFSM5QHZG4TQ> . 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: ***@***.***>

-- Steve Cumming Professeur agrégé Département des sciences du bois et de la forêt Université Laval (418) 656-2131 poste 2593

[achubaty]

• for an annual module, one can use non-integer start times for event scheduling (e.g. 0.25 might be spring; 0.75 might be fall). to ensure this aligns with other modules, some checking is still needed to confirm the timing of these events.
• event prority is can achieve similar outcome -- though it is intended to help resolve schudeling "ties" when 2 events are scheduled in the same timestep, and FIFO is not desired.