predictiveecology / scfm Goto Github PK

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.

i.e., to pre-generate fire regimes to run on a given area.

Use cases:

1. use prerun param estimates so i can run sims on multiple computers w/o shared cache;
2. look at doing "future range of variation" (FRV) passing modified fire regimes that approximate future fire conditions.

From Ian:

the mechanism now in place (with target FRIs) was somewhat designed to do this ... scfmLandcoverInit and scfmRegime would need to be modified.

See my poster from the JSM August 2018; I should give a lab meeting talk on this. Deets to follow

Decided to get rid of studyArea0 and only use studyArea. Previously AndisonDriver_dataPrep would create studyArea with AndisonFRI polygon. This is not desirable when studyArea is supplied by other modules. If we want to keep AndisonFRI we should instead have all objects that relied upon the AndisonFRI layer use an object called AndisonFRI. This may require creating more modules that are Andison-specific, like AndisonDriver. Not a priority at the moment.

see 155ef1a

use Eliot's canada.ca email

Would allow use of static fire perimeter maps to be fed to the simulation to allow using historic fire data for years where we have data instead of simulating those fires (e.g., via https://github.com/PredictiveEcology/historicFires).

• implement .runInitialTime following approach in fireSense;
• ensure all outputs and other objects are standarized.

related: CeresBarros/FavierFireSpread#1 (comment)

I haven't been able to track this down fully, but the LCC and/or flammable raster maps are being reporjected even when the user passes prebuilt objects.

If passing non-integer non-flamm classes to LandR::defineFlammable, it is returning a double/float raster (PredictiveEcology/LandR#72), which in turn is using bilinear when the aforementioned reprojection happens, resulting in non-int LCC values.

Dave's regimes are FRIs. To a poor approximation (see Reed 2006) , these can be simulated as annual area burned = (1/FRI) * flammableArea

We are going to use historical fire igntition frequencies as estimated by scfmRegime

We are going to use escape probabilities as per scfmRegime (or maybe apply odds ratios from Cumming (2005) to estimate pre-suppression era escape probs.

We then obtain the mean fire size by dividing MAAB by expected number of escaped fires.

Finally, we use the crappy calibration function to get spread probability from target mean fire size.

I will explain in detail later.

scfmDriver, scfmRegime and scfmLandcoverInit disagree about what typo of object this should be.

1. scfmDriver expects SPDF (according to metadata and the use of rgeos::gArea();
2. scfmRegime uses sf functions throughout but metadata says SPDF;
3. scfmLandcoverInit uses sf functions (and I recently updated te metadat accordingly).

@ianmseddy do you have any unpushed changes?

The example in the Rmd suggest no (t_start = 0), but some simulation components (a few objects in .inputObjects blocks, like ageMap) require calendar years (e.g., 2011 start time).

Metadata say fireRegimePolys should be a SpatialPolygonsDataFrame, but checkForIssues() expects it to be an sf object.

I've pulled Ian's diagnostic plot functions from the scfm.Rmd file, adatped them for use in scfmutils, and have impelmented a simple module for diagnotic plotting (scfmDiagnostics) that gets scheduled to run and the end of the simulation and can also be run in postprocessing to summarize multiple runs.

• map showing the fire regime polygons used
• estimated vs simulated fire return interval
• estimated vs simulated ignitions
• estimated vs simulated mean fire size
• estimated vs simulated escapes
• cumulative burn map (also showing flammability)
• pSpread (add to fire regime poly map)

Currently, scfm requires fairly large study areas in order to ensure enough fire data for model fitting. This limits the use of the modules more generally. Can we implement a notion of studyAreaLarge that can be used for fitting etc., while allowing the user to pass a smaller studyArea for fire simulation?

From Ian:

it might be possible to run scfmRegime/scfmDriver on a much larger area, and then supply those objects for a run with a small area. There are some hiccups you would inevitably have to solve though.

This approach would limit scfm to being run as a pre-processing step, i.e., not part of the main simulation.

1. easier to not use certain modules (like we did for AB NRV, where we provided our our regime pars);
2. finer-grain control over module updates (currently unable to pull updates for specific modules; all-or-none), which reduces merge conflicts introduced when scfm being used in multiple projects.

@SteveCumming I understand that we had previously discussed this and agreed to hold off because you were actively developing and encountered issues using git submodules, but now that scfm is primarily being maintained by Ian (with support from me), this will vastly simplify scfm integration across multiple projects. Additionally, Eliot's recent creation of SpaDES.install::getModule() allows users to get modules without needing to use git.

@ianmseddy this is high on my TODO list and I'd like to discuss further, as it will have implications for existing/ongoing projects using scfm.

The obsolete directory inputsLandWeb/ can also be removed, along with the following obsolete files:

• inputMaps.R
• scfmPoly.Rmd

rasterToMatch must be added and some of the modules with more complicated objects do not currently have defaults. For example scfmIgnition requires the parameters in scfmDriverPars, created by scfmDriver, as well as the landscapeAttr output by scfmLandcoverInit.

Per Chris Mellon, this is an issue mainly for simulated landscapes, but the following line in driverFunctions.R will error if there are no non-flammable pixels.

    res <- optimise(escapeProbDelta,
                    interval = c(hatP0(hatPE, neighbours),
                                 hatP0(hatPE, floor(sum(w * 0:8)))),
                    tol = 1e-4,
                    w = w,
                    hatPE = hatPE)

Replace archaic code snippets in scfmPoly.Rmd that load data.
Tati has done this work on a previous version of scfmModules which is on some git repo somewhere.

Eliot further pointed out that module scfmCrop can go: it's jobs will be done by prepInputs calls in .inputObjects events in scfmLandCoverInit and scfmRegime.

There are objects that output lists of parameters derived from the fire data that need more documentation.

• scfmRegime outputs the list scfmRegimeParameters that contains emfs, xMax, xBar, and lxBar

with #12

• inputs/ and inputsLandWeb appear to share some data. Check whether we can remove these duplicates;
• it probably also makes sense to put LandWeb-specific data in a subdir of inputs/ (i.e., inputs/LandWeb/);
• large files shouldn't be git-controlled -- can we have these downloaded as needed?

The current structure of each of these objects is a named list, whose names are expected to match exactly for each of these objects. Currently, the names are taken to be character representations of fireRegimePoly$PolyID (i.e., as.character(int)).

This current implementation makes caching these objects problematic:

1. without extreme care the attributes list for polygon "6" may be incorrectly retrieved from the cache for another study area that happens to also have a polygon "6".
2. recent diagnoses of bugs have revealed situations where the list names sometimes differ among each of these objects (typically because of caching issues), but the additonal assertions added to check these labels/names are likely not sufficient to ensure consistent [correct] behaviour.

To deal with the first issue, if we tied the names (labels) of these list elements to specific polygon i.e. sp/sf objects, e.g., by using digest hashes of the polygons themselves, this would ensure caching is handled more reliably. However, using hashes as labels is not user-friendly.

If we were to formally implement each of these objects as classes within the scfmutils package, we could ensure they behave consistently and can more easily test caching etc. as part of package unit tests.

The following modules can be removed as they are now defunct:

• classifyAge
• patchMetrics
• scfmCrop
• scfmPoly

The 'study Area' expected input is studyArea0, and scfmLandcoverInit will create studyArea if it is not supplied. This gets really annoying because inputObjects need to use studyArea0, but other functions use studyArea. This was all because AndisonLandcoverInit created its own studyArea from clipping AndisonFRI to studyArea0. It is better to remove all references to studyArea0, and just use studyArea, because it is the 'canonical object'. The only issue is we modify studyArea with the PolyID field (not sure if we want to allow modification of objects like studyArea that are critical to other modules, as a matter of 'best practices').

Note this may break scfmAndison modules until we come up with a better approach.

I think this is preferable to something hosted on Eliot's google drive

scfm modules don't respect reproducible.destinationPath option. dPath in `.inputObjects should be using the following:

dPath <- asPath(getOption("reproducible.destinationPath", dataPath(sim)), 1)