scfm's People
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:
- use prerun param estimates so i can run sims on multiple computers w/o shared cache;
- 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
andscfmRegime
would need to be modified.
remove duplicated inputs
with #12
-
inputs/
andinputsLandWeb
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 listscfmRegimeParameters
that containsemfs
,xMax
,xBar
, andlxBar
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)
something in landcoverInit is reprojecting inputs when they are provided
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.
scfmLandCoverInit: 'fireRegimePolys' expected to be sf, not spdf
Metadata say fireRegimePolys
should be a SpatialPolygonsDataFrame
, but checkForIssues()
expects it to be an sf
object.
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.
scfmDriver
expects SPDF (according to metadata and the use ofrgeos::gArea()
;scfmRegime
usessf
functions throughout but metadata says SPDF;scfmLandcoverInit
usessf
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:
- 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"
. - 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.
update email addresses in module metadata
use Eliot's canada.ca email
.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.
Fire size to spread prob calibrations are inadequate
I will explain in detail later.
does scfm require sims to run on calendar years?
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).
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
.
ageMap should be supplied by kNN?
I think this is preferable to something hosted on Eliot's google drive
allow simulating fires only after some time during the simulation
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 infireSense
; - ensure all outputs and other objects are standarized.
split modules to separate repos to improve modularity
- easier to not use certain modules (like we did for AB NRV, where we provided our our regime pars);
- 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.
rename vegMap to rstLCC to match other LAndR Biomass modules?
Current fire modules vastly underestimate variance in annual area burned
See my poster from the JSM August 2018; I should give a lab meeting talk on this. Deets to follow
using comparePredictions_summaryDT() with studyAreaReporting instead of (buffered) studyArea used for sim
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.