/
SEIRS.Rmd
108 lines (85 loc) · 3.45 KB
/
SEIRS.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
---
title: "SEIRS Model Example"
output: rmarkdown::html_vignette
vignette: >
%\VignetteIndexEntry{SEIRS Model Example}
%\VignetteEngine{knitr::rmarkdown}
%\VignetteEncoding{UTF-8}
---
```{r, include = FALSE}
knitr::opts_chunk$set(
collapse = TRUE,
comment = "#>"
)
```
```{r setup, include = FALSE}
library(rSimpleModel)
library(rDataPipeline)
library(here)
library(magick)
library(pdftools)
i_am(path = "vignettes/SEIRS.Rmd")
knitr::opts_knit$set(root.dir = here())
```
## *config.yaml* file
The user should write a *config.yaml* file containing information pertaining to
the data products used in the code run. The example *config.yaml* file below
describes a code run with inputs:
* `disease/sars_cov2/SEIRS_model/parameters/static_params`
These inputs are listed in the `register` block, meaning that they should be
downloaded to the local data store from an external source, with associated
metadata stored in the local registry. These inputs are automatically converted
into a `read` block by `fair run` (when data products are already present in
the data registry, inputs should be listed in the `read` block).
A code run usually also has outputs, which are listed in the `write` block. In
the example below, our outputs are:
* disease/sars_cov2/SEIRS_model/results/model_output
* disease/sars_cov2/SEIRS_model/results/figure
*SEIRSconfig.yaml*:
```{r config, echo=FALSE, comment=''}
cat(readLines(file.path(here(), 'inst/extdata/SEIRSconfig.yaml')), sep = '\n')
```
The submission script should call `initialise()` to set up the code run,
then perhaps read in some data using one of the `read_*()` functions (for
internal file formats) or `link_read()` (for external file formats such as
csvs). The data might now be processed in some way, or a model / analysis might
bw carried out, after which the results should be saved in the local data store
via one of the `write_*()` functions or `link_write()`. When the code run is
complete, `finalise()` should be called to register the all metadata with the
local registry.
## `fair pull`
Using the CLI tool, `fair pull` identifies any data products listed in the
`register` field of the *config.yaml*. These data products are downloaded to
the local data store whilst associated metadata is registered in the local
registry.
```{bash}
fair init --ci
fair pull inst/extdata/SEIRSconfig.yaml
```
The local registry should now contain three data products:
1. `disease/sars_cov2/SEIRS_model/parameters/static_params`,
2. `disease/sars_cov2/SEIRS_model/parameters/rts`, and
3. `disease/sars_cov2/SEIRS_model/parameters/efoi`.
## `fair run`
Again using the CLI tool, `fair run` performs the code run, as written in the.
submission script. In preparation for this, it translates the user-written
*config.yaml* file for use by the Data Pipeline API. Any variables / wildcards
specified by the user in the config file are cross referenced with the registry,
and any data products registered by `fair pull` are made available to read by
the current code run.
```{bash}
fair run inst/extdata/SEIRSconfig.yaml
```
## Outputs
```{r, echo=FALSE, fig.width=20}
path <- get_dataproduct(data_product = "SEIRS_model/results/figure/R",
version = "0.0.1",
namespace = "testing")
image_read_pdf(path)
```
## Provenance report
```{r, echo=FALSE, fig.width=20}
get_provenance(data_product = "SEIRS_model/results/model_output/R",
version = "0.0.1",
namespace = "testing")
```