Code Monkey home page Code Monkey logo

scfm's People

Contributors

achubaty avatar eliotmcintire avatar ianmseddy avatar stevecumming avatar tati-micheletti avatar

Stargazers

 avatar

Watchers

 avatar  avatar  avatar  avatar  avatar

scfm's Issues

deprecated modules

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

  • classifyAge
  • patchMetrics
  • scfmCrop
  • scfmPoly

obsolete files and directories

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

  • inputMaps.R
  • scfmPoly.Rmd

pass a precomputed scfmRegimePars object?

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.

remove duplicated inputs

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?

scfmDriver fails if every cell is flammable

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)

use of studyArea needs a review

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.

need to improve documentation

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

dPath not correctly specified in modules

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

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

implement a driver for Dave's regimes

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.

fireRegimePolys: is it a list, an SPDF, sf, or quosure???

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?

module 'andisonDriver_dataPrep' needs updating

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

formalize 'scfmDriverPars', 'scfmRegimePars', 'landscapeAttr' objects

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.

.inputObjects need review

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.

set fire event priority to happen after regen

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.

implement studyAreaLarge

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.

model diagnostics

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 (scfmDiagnostecs) that gets scheduled to run and the end of the simulation.

Currently produced

  • map showing the fire regime polygons used
  • estimated vs simulated fire return interval
  • estimated vs simulated ignitions
  • estimated vs simulated mean fire size

What other plots (or other objects) would be useful to produce here?

  • estimated vs simulated mean annual area burned
  • add confidence intervals to plots? i.e., pool simulated fires from many reps of a set of simulations

Retrofit prepInputs

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.

split modules to separate repos to improve modularity

  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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.