Merge pull request #154 from dd-harp/dev

menu reorganization

R/adult-bionomics-GeRM.R

@@ -100,7 +100,7 @@ create_MYZpar_GeRM = function(nPatches, MYZopts=list(), eip =12,
 MBionomics.GeRM <- function(t, y, pars, s) {
   with(pars$MYZpar[[s]],{
     pars$MYZpar[[s]]$f_t      <- F_f(t, vars, f_par)
-    pars$MYZpar[[s]]$es_f     <- rep(1, pars$nPatches)
+    pars$MYZpar[[s]]$es_f     < rep(1, p-ars$nPatches)
     pars$MYZpar[[s]]$q_t      <- F_q(t, vars, f_par)
     pars$MYZpar[[s]]$es_q     <- rep(1, pars$nPatches)
     pars$MYZpar[[s]]$g_t      <- F_g(t, vars, f_par)

_pkgdown.yml

@@ -1,8 +1,6 @@
 url: https://dd-harp.github.io/ramp.xds
 navbar:
   left:
-  - text: Functions
-    href: reference/index.html
   - text: Articles
     menu:
     - text: Getting Started with ramp.xds
@@ -57,6 +55,8 @@ navbar:
       href: articles/human_hmoi.html
     - text: SEIS model
       href: articles/human_seis.html
+  - text: Functions
+    href: reference/index.html
   right:
   - icon: fa-github
     href: https://github.com/dd-harp/ramp.xds/

vignettes/AdultMosquitoes.Rmd

@@ -12,25 +12,11 @@ library(ramp.xds)
 library(viridisLite)
 ```
 
-```{r, echo=F}
-#devtools::load_all()
-```
-
-Nimble model building in **`ramp.xds`** proceeds from simple to complex. Some basic concepts used throughout **`ramp.xds`** are:
-
-+ **Model Family** - what is colloquially referred to as a *model* in the code library is more accurately described as a model family. Each model family is defined by a set of *states* and transitions (*i.e.* as defined for one population stratum) that represent the *true* but unobservable state of a population, also known as *latent* states. A model family describing adult mosquitoes has been assigned a unique `MYZname` and that can be setup using `xds_setup(MYZname = 'this').` A model in **`ramp.xds`** is defined by a **`xds`** object -- it can be solved, and it will return values. 
-
-    - Each model can be represented as a directed graph, and two models belong to the same model family if their graphs are identical. 
-
-    - Two models are also identical if one can be derived from another by a change of variables. 
-
-+ **Spatial Dynamics** - in the case of adult mosquitoes, the population is structured spatially: each stratum represents the mosquitoes in a single patch. The states and state transitions are replicated in each patch. 
-
-+ **Forcing** is incorporated through functions that compute the parameters as a function of time. By default, each model is set up as an  **autonomous** system of equations. An autonomous system is then modified by adding exogenous variables and forcing, making it a **non-autonomous** system. 
+Models for adult mosquito ecology, behavior, and infection dynamics pose some problems for their *extensibility.* The models in **`ramp.xds`** were included for several reasons: 
 
-+ **Vector Species** (or types) - basic setup handles a single vector species (or type). Each new species must be added separately. adds to the model.  
++ They serve as an important set of models to test the software; 
 
-+ **Model Skill Set** - a model's skill set is defined as the set of observable quantities that are naturally represented by the latent states such that they can be computed without requiring extraneous information. 
++ They illustrate some important basic features of **`ramp.xds`** design princples (see [Nimble Model Building and Scalable Complexity](Nimble.html)). 
 
 ## Basic Models
 

vignettes/Nimble.Rmd

@@ -0,0 +1,84 @@
+---
+title: "Nimble Model Building and Scalable Complexity"
+output: rmarkdown::html_vignette
+vignette: >
+  %\VignetteIndexEntry{Nimble Model Building and Scalable Complexity}
+  %\VignetteEngine{knitr::rmarkdown}
+  %\VignetteEncoding{UTF-8}
+---
+
+The design of **`ramp.xds`** was based on a mathematical framework, but it was motivated by the ideas of nimble model building and scaling complexity. The software, like the framework, is modular, but it was equally important for the software to be flexible and extensible. Since it is impossible for any software to take on everything all at once, it was necessary to make some important decisions about how the software should handle the space of all possible models. 
+
+## Terminology 
+
+The term *model* is used in so many ways that we have found it necessary to develop a specialized vocabulary to disambiguate some of the possible meanings in context. Two important definitions that we would like to use for mechanistic models are:
+
+1. **Model** - A mechanistic *model* is any abstract, quantitative representation of a process. 
+
+2. **Model** - in **`ramp.xds`,** a model is defined by an **`xds`** object. It has defined all of the parameters, initial values, and possibly a random number seed, and it can be solve solved. 
+
+We must live with this ambiguity, but we would like to define some terms that can help us to make sense of all this complexity in context. 
+
++ **Model Family** - what is colloquially referred to as a *model* in the code library is more accurately described as a model family. Each model family is defined by a set of *states* and transitions (*i.e.* as defined for one population stratum) that represent the *true* but unobservable state of a population, also known as *latent* states. Each model has a defined set of define parameters; the model family includes models with any reasonable parameter values. 
+
+    - Model families are defined for the endogenous variables and for *autonomous* systems with a single stratum 
+
+        - a model family thus includes all of the *non-autonous* systems with unspecified exogenous variables that could modify the parameters
+
+        - a model also includes all related structured models that extend it.
+
+    - Two models are also identical if one can be derived from another by a change of variables. 
+
+    - Each model can be represented as a directed graph with specialized edge types (*e.g.* simple flows; delayed flows): and two models belong to the same model family if their graphs are identical. 
+
++ **State Space Models** - the latent states in a model are associated with a set of observable states, and an important part of a model definition is a set of functions that define an observation process mapping the latent states onto observable states. 
+
++ **Model Skill Set** - a model's skill set is defined as the set of observable quantities that are naturally represented by the latent states such that they can be computed without requiring extraneous information. 
+
++ **Module** - a *module* in **`ramp.xds`** instatiates a model family in **`ramp.xds`** for one of the dynamical components, and each module has been assigned a unique name. For example, the `'macdonald'`model for adult mosquitoes instantiates a non-extensible version of the Ross-Macdonald model. 
+
++ **Trival Module** - for each dynamical component, the trivial module lacks any variables, so it does not respond dynamically to other dynamical components. Each trivial model passes the required outputs to other models as a *trace* function. 
+
+## Model Building
+
+Model building in **`ramp.xds`** was developed with the goal of building complex models by extending simple ones. This proceeds in an orderly way through basic setup: 
+
++ Choose the modules for each dynamical component; 
+
++ Define the basic model structure;  
+
+
+### Modular Dynamics
+
+The first step in building a model is to determine which modules to use for a study. 
+
+### Structural Flexibility  
+
+#### Principled Stratification 
+
+Each human (or vertebrate host) population can be stratified into an arbitrary number of sub-populations or strata. 
+
+#### Spatial Structure
+
+In these models, spatial dynamics are defined by patches representing the locations of adult mosquito sub-populations. 
+
+#### Structured Habitats
+
+#### Malaria Importation 
+
+### Flexibility  
+
+### Extensibility  
+
+#### Forcing
+
+By default, each model is set up as an **autonomous** system of equations. An autonomous system is then modified by adding exogenous variables and forcing, making it a **non-autonomous** system. 
+
+#### Vector Control 
+
+#### Multiple Host Species (or types) 
+
+#### Multiple Vector Species (or types) 
+
+**Vector Species** (or types) - basic setup handles a single vector species (or type). Each new species must be added separately. adds to the model.  
+