Getting started

• 1: Motivation
• 2: Concepts
• 2.1: Model
• 2.2: Module
• 2.3: Modelling project
• 2.4: Reproducible research
• 2.5: Transferability
• 3: Users
• 3.1: Coders
• 3.2: Modellers
• 3.3: Planners
• 4: Stakeholders
• 4.1: Funders
• 4.2: Researchers
• 4.3: Young people
• 5: Software
• 5.1: System requirements
• 5.2: Code repositories
• 5.3: Release statuses
• 5.3.1: Unreleased code
• 5.3.2: Development releases
• 5.3.3: Production releases
• 5.3.4: Archived releases
• 5.4: Code libraries
• 5.4.1: Current libraries
• 5.4.1.1: Framework libraries
• 5.4.1.2: Model module libraries
• 5.4.2: Code library documentation
• 5.4.3: Dependencies
• 5.4.4: Installation and set-up
• 5.4.4.1: Installing the ready4 framework foundation library
• 5.4.4.2: Installing authoring tools
• 5.4.4.2.1: Installing tools for authoring model modules
• 5.4.4.2.2: Installing tools for authoring and managing model datasets
• 5.4.4.2.3: Installing tools for authoring reproducible analyses
• 5.4.4.3: Installing ready4 computational model modules
• 5.5: Executables
• 5.5.1: Programs
• 5.5.2: Subroutines
• 5.6: User interfaces
• 5.7: Terms of use
• 5.7.1: Open source licensing
• 5.7.2: Citing ready4
• 5.7.3: Disclaimer

1 - Motivation

Problem

Improving the mental health and wellbeing of young people is a global public health priority. However, identifying the optimal policy and system design choices to meet this challenge is not straightforward. Models are a potentially useful tool to help decision makers navigate complexity, but can have significant limitations such as:

• Mistakes: Errors, common in even relatively simple health economic models, become both more likely to occur and more difficult to detect as model complexity grows;

• Poor transparency: the validity of model analyses can be difficult to adequately ascertain if it is not clear who contributed to the model, what assumptions they made, how model algorithms were implemented, how those algorithms were tested and what data they were applied to;

• Contested legitimacy: the value judgments of the model development team (e.g. what types of question are most important for a model to address, what parts of the workings of the system of interest to represent and in what detail, what outcome variables to include, which stakeholders to consult, etc) may differ from those using or affected by model outputs;

• Narrow applicability: a model might be too simple to adequately explore some problems and too complex to reliably address others and be hard to transfer beyond a very specific decision context (e.g. within a specific jurisdiction);

• Limited interoperability: different approaches to model implementation, dissemination, ownership and reporting makes it more difficult for multiple models to be efficiently and safely combined;

• Ease of misuse: in the absence of clear documentation and prominent caveats, a model can easily be applied to decision problems to which it is poorly suited (potentially supporting decisions with serious negative consequences);

• Restricted access: a potential overcompensation for fear of model misuse is constructing high barriers to accessing model code and data - thus limiting model testing, reuse and refinement; and

• Growing stale: health economic models are rarely updated, meaning they can lose validity with time (e.g. input data becomes less relevant, new better performing algorithms are not incorporated, sudden major changes in environment / epidemiology / policy / service system are not accounted for).

Reponse

To help address these issues, ready4 is being implemented as a modular and open source computational model of youth mental health that aims to be accountable, reusable and updatable.

Accountable

Model code and data are publicly available in online code repositories and data collections. Algorithms are documented and transparently and regularly tested. Model development occurs in the open and invites community participation, with each individual’s contribution publicly identifiable. Analyses are reproducible and replicable.

Reusable

Model modules and datasets originally developed in one modelling project can be independently reused in other projects. As they share a common framework, model modules can be combined in other models and analyses to address multiple topics. Due to ready4’s code implementation paradigms, model modules are easier to transfer for use in other decision contexts.

Updatable

Model code, data and analyses are versioned, with an ongoing program of making new and updated releases. Software is maintained, with opportunities for users and contributors to flag issues, request features and supply code contributions.

2 - Concepts

2.1 - Model

A model is a simplified representation of a system of interest. In the way we use the term, we also mean that a model is:

• abstract and general (i.e. largely free of non-modifiable data, including numeric values, that are assumption- or context- specific) and
• a tool (i.e. a model can be used to help undertake an analysis, it is not the analysis itself).

If a model is developed primarily to inform a decision or set of decisions (e.g. relating to youth mental health policy and system design) it can be called a decision model.

Ideally, a model should have three inter-related representations - conceptual, mathematical and computational.

Conceptual Model

A conceptual model refers to underlying theory and beliefs about a system of interest that can be described in words and pictures.

Mathematical Model

A mathematical model formalises a conceptual model as a set of equations.

Computational Model

A computational model implements the conceptual and mathematical models of a system of interest as computer code.

ready4 is a computational model of youth mental health. More specifically, the ready4 computational model is the complete set of ready4 modules.

2.2 - Module

A modular computational model is one that constructed from multiple self-contained components, called modules. Each ready4 module describes a data structure and the set of algorithms that can be applied to it.

The advantages of developing ready4 as a modular model include:

• each module can be independently re-used in other computational models of the people, places, platforms and programs important to the mental health of young people;

• a complex model can be developed iteratively, beginning with a simple representation that is easier to validate and then progressively expanding in scope and functionality through the addition of new modules, to be validated independently and jointly; and

• long term and resource intensive model development is more feasible through combining multiple independently managed and financed modelling projects.

To ensure that all ready4 modules can be safely and flexibly combined, each module is created from a template using authoring tools that support standardisation.

2.3 - Modelling project

As a complex, collaborative and long-term undertaking, it is not feasible for ready4 to be financed by a single funder or progressed as a single project. Instead, our mode of development is via multiple independent modelling projects, each with their own project governance and funding, but which adopt a common framework.

A ready4 modelling project will involve the three steps of:

• Developing and validating a computational model;

• Adding context-specific data to that computational model; and

• Applying the computational model to the supplied data to undertake analyses.

The key components of each step are summarised here.

2.4 - Reproducible research

Although there is widespread support from the scientific community on the importance of reproducible research, the definition of key terms such as reproducibility and replicability can vary across disciplines and methodologies (e.g. the extent to which computational modelling is used). In some cases, entirely different terms (e.g. repeatability) are preferred. The meanings we intend when using these terms are described below.

Reproduction and Replication

The distinctions we make between reproduction and replication have been guided by the approach outlined in a report by the National Academies of Sciences, Engineering and Medicine. However, we have adapted their definitions slightly as the meanings in that report were framed in terms of study findings / outcomes, whereas our usage relates more to intended objectives when deploying tools.

Meanings

Reproduction

Applying the same analysis code to the same input data with the expectation of generating identical outputs (with the exception of trivial artefacts like datestamps for when analysis reports were produced).

Replication

Applying analysis code used in a study to new input data. The analysis code is reused with only minimal edits that are necessary to account for differences in input data paths and variable names and to study metadata (e.g. investigator names, sample descriptions). The new data can be real or fake, but will include the same structure and concepts / measures as those found in the original study’s dataset. If the new data is a sample from the same population as the original study, then the expectation when undertaking replications is for results across studies to be broadly similar.

Examples

Examples of both reproduction and replication code are available. When publishing analysis code we try to adopt (there are exceptions) the following rules of thumb:

1. If the data required to re-run a study analysis are publicly available (or declared by the analysis program itself), then we publish the code as a reproduction program (e.g. this program for creating a synthetic population).

2. If the data required to re-run a study analysis are not publicly available, we publish the replication version of the code. The replication version of the code may be configured to ingest a synthetic (fake) representation of the study dataset as with this utility mapping replication program. Details of the (minimal) steps required to revert the replication code to a version that can be used for reproduction purposes are typically embedded within the program itself.

2.5 - Transferability

It is common for discussions of scientific studies to consider the extent to which findings can be generalised (e.g. if a well conducted study concludes with high confidence that an intervention is cost-effective in Australia, is it valid to infer that it is likely to be cost-effective in the United Kingdom?). However, we are more interested in the transferability of computational models (e.g. the extent to which the data-structures and algorithms from a computational model developed for an Australian context can be used to explore similar topics in the United Kingdom). Our usage of the term “transferring” (and by extension “transferability”, “transferable”, “transfers”) reflects this motivation.

Transferring - our meaning

Adapting a computational model, in whole or in part, to extend the types of data and/or research questions to which it can be applied. The new types of data will possess some differences in structure and / or concepts from that to which the computational model had previously been applied and these differences may be why research questions need to be reformulated.

When we use the term transferring, we are typically referring to either (a) authoring or (b) using on of the following:

1. An analysis program (or sub-routine) that has been adapted from an executable from another study to account for differences in the input data / research question.

2. Inheriting data-structures and algorithms that selectively re-use, discard and replace elements of a study’s computational model based on an alternative use-case.

3. (Multi-purpose) function libraries that have been created by decomposing a study’s (single purpose) analysis program.

Examples

The scorz module library was originally developed to provide an R implementation of algorithms in other languages for scoring adolescent AQoL-6D health utility as part of a utility mapping study (which also used the analysis program mentioned above). Examples of all three approaches mentioned in the previous section can be seen by examining the documentation and source code of the scorz library:

1. Two vignette programs from the scorz library website score different utility instruments. The first program scores adolescent AQoL-6D health utility and acts as a template for the second, which has been modified to score EQ-5D health utility.

2. Inspecting those example programs shows that one of the key adaptations in the EQ-5D program is to use the ScorzEuroQol5 module instead of the ScorzAqol6Adol module. Both of these modules inherit from ScorzProfile. This arrangement means that all three modules share some features (in terms of both structure and algorithms) but selectively differ (e.g. aspects that are necessarily different for scoring different instruments).

3. The algorithms attached to each module from the scorz library are principally implemented by functions (the source code for which can be viewed here) that were created when decomposing an early draft of the above mentioned study algorithm. These functions are called by module methods (source code viewable here).

3 - Users

3.1 - Coders

If you are a coder, you may be a data scientist or software engineer by training or are perhaps a quantitative researcher who spends a high proportion of their time writing code to undertake their work.

Role

The primary role of coders in ready4 modelling projects is to author modules that implement computational models.

Benefits of using ready4

ready4 provides an opportunity to write software that matters! Our aim is to help improve the lives of young people through empowering decision makers with better models. If you already write code for youth mental health modelling projects, ready4 may also be helpful to you by enhancing your impact (providing a framework for modular models that facilitate re-use by others) and efficiency (through partial automation of code development and quality-assurance workflows).

Contributing to ready4

The types of contribution you can make to ready4 include:

• testing, improving and authoring code;
• enhancing technical documentation and help; and
• providing advice and feedback.

3.2 - Modellers

If you are a modeller, you are responsible for the overall implementation of a modelling study from initial conceptualisation through to analysis and reporting. You are likely to be an economist, epidemiologist or statistician and are probably reasonably comfortable with writing analysis scripts in statistical software (potentially including R), without necessarily being a coding wizard.

Role

The primary role of modellers in ready4 modelling projects is to use modules to undertake analyse as part of modelling projects.

Benefits of using ready4

We hope that ready4 can be of benefit to you by helping you to efficiently build on work by other modellers, to implement more reproducible workflows, and to share your work so that it can be reused.

Contributing to ready4

The types of contribution you can make to ready4 include:

• leading or participating in a modelling project;
• enhancing technical documentation and help; and
• providing advice and feedback.

3.3 - Planners

If you are an planner, you contribute to policy development or service planning to help immprove the mental health of young people. You probably value the role of modelling to inform your work, but are likely to rely on others to provide much of the technical expertise to implement computational models.

Role

The primary role of planners in ready4 modelling projects is co-design of decision aids that provide user-interfaces for allow easy configuration of models to run bespoke analyses.

Benefits of using ready4

We hope that ready4 can provide you with accountable, reusable and updatable decision support.

Contributing to ready4

The types of contribution you can make to ready4 include:

• leading or participating in a modelling project;
• providing advice and feedback; and
• funding a project.

4 - Stakeholders

4.1 - Funders

There are six main types of funder that can provide cash and/or in kind support to ready4:

1. Grant making research bodies can support modelling project proposals submitted to their existing funding schemes. These types of funder could also consider making a number of changes to how they work including the assessment weightings and levels of financial support given to the reproducibility, replicability and transferability components of research proposals and initiating targeted calls for proposals to improve the accountability, flexibility and maintenance of models to inform policy.

2. Government departments can support the development of ready4 as part of programs to enhance data analysis and modelling capability in youth mental health by providing support to develop core ready4 infrastructure (e.g. our software maintenance and community development priorities). When commissioning new modelling projects, governments could make providing open access to code and (to the greatest extent feasible, balancing confidentiality considerations) data a requirement of all applicants.

3. Youth mental health service commissioners can commission data analysis and modelling projects that develop novel decision aids and to apply existing ready4 modules to undertake new analyses.

4. Philanthropic donors can help accelerate our development and enhance our impact by supporting us to bring our existing in-development software to launch and to further extend the ready4 model.

5. Corporate sponsors can provide cash, expertise and free product licenses to support both our core open-source infrastructure and individual modelling projects.

6. Individual givers can provide support by donating to Orygen (please remember to specify www.ready4-dev.com as the reference for the project you would like to support!).

4.2 - Researchers

Researchers in multiple discipline enhance prior, current or planned future projects related to how economic, environmental, service, social and technical systems shape young people’s mental health by using ready4 to:

• label and share non-confidential data (e.g. tables of summary statistics / parameter values) from prior and current work to extend access and impact;
• working with modellers to undertake modelling analyses;
• working with coders to redevelop study analysis scripts by authoring modules that are transferable to other contexts;
• supervising student projects to assist with ready4’s current priorities; and/or
• develop research proposals that incorporate a modelling project.

Researchers considering using ready4 should ensure they understand the development status of the tools they wish to use. If the required software is not yet a production release (a process we are working on!) we’d suggest only using it for testing or exploratory work that is not designed to inform decision making. All our software is free and open source so you don’t need to ask our permission to use it. We are however, very happy to discuss ideas for potential collaborations - contact the project lead to arrage a chat.

We also welcome advice from researchers about how we can make ready4 more relevant and useful.

4.3 - Young people

Young people have an important role to play in both the development of the overarching ready4 model and the applicability of ready4 to specific decision problems.

One of the main contributions that young people can make is to provide advice. To date, the advice we have elicited from young people has related to shaping the design and conduct of individual modelling projects. The process we have previously used to engage young people in modelling projects normally begins with the advertisement for expressions of interest via a range of social media platforms (always including those maintained by Orygen). We plan to supplement these opportunities to shape individual project with opportunities to shape the overall development of the ready4 model though growing a ready4 support community.

5 - Software

5.1 - System requirements

Currently, all ready4 software is written in R (for libraries), R Markdown (for programs and sub-routines) and JavaScript (for the user interface component of Shiny applications). Therefore:

• to use ready4 libraries and programs / subroutines you must have an up to date version of R installed on your machine and it is recommended that you install the RStudio IDE; and

• the requirements for using ready4 user interfaces depend on whether you are running a version we have deployed to the web (in which case you just need a supported browser) or whether you are running the app on your local machine (in which case you will need both R and RStudio).

5.2 - Code repositories

Currently:

• the most up to date development releases for all ready4 software is available in the ready4-dev GitHub organisation;

• citable and uniquely identified (with a DOI) archived releases of ready4 software are available in the ready4 Zenodo community and are indexed in OpenAire Explore; and

• ready4 user interfaces that have web-based deployments are hosted on Shinyapps.io.

We have yet to issue production releases of any of our R packages, but once these are finalised we will be submitting them to the Comprehensive R Archive Network.

5.3 - Release statuses

5.3.1 - Unreleased code

Currently, a new ready4 software project initiated by the ready4 core team will by default be made public as a pre-release version in the ready4 GitHub organisation. However, there are some important exceptions. Principally, these exceptions relate to code that we authored in the initial phase of ready4’s development to which some or all of the following apply:

• the code is highly unstable because it has not been (fully) updated to account to major changes implemented in core dependencies;
• the code uses outdated naming conventions and is potentially confusing when used in conjunction with other elements of the ready4 suite; and/or
• the code repository has yet to be cleansed of artefacts that are not yet appropriate for public dissemination (e.g. renders of draft scientific manuscripts).

Depending on which of the above issues apply to a code repository, that repository will either be:

• a private repository (not accessible to anyone outside the core development team); or
• a public repository stored in a location other than the ready4 GitHub organisation.

5.3.2 - Development releases

A complete record of all publicly available versions of a ready4 software project’s code over its entire development history (including the most up to date version) is stored in the ready4 GitHub organisation. We refer to these comprehensive publicly available source code resources as “development releases” (even though these records will include versions of our code that we have not formally labelled as “releases”).

Public access to development releases allows individuals to install, test and preview code in advance of production versions being released. Development releases also provide transparency as to who contributed what to a software project and when these contributions were made. Accessing the latest development version of the code is particularly useful to people who wish to contribute bug fixes or new features to our code.

Limitations of development releases include the likelihood that some or all of this code may be inadequately documented or tested. In peer reviewed publications, it is generally considered preferable to avoid citing the copies of code stored in GitHub repositories as these repositories are impermanent (they can be moved, renamed or deleted at any time).

5.3.3 - Production releases

Production releases of our code are intended for end-users and signal that they have undergone a number of quality assurance checks and have some supporting documentation.

We have yet to make any production releases of ready4 software, but plan to do this in 2023. Production releases of ready4 R packages will be submitted to CRAN. Unless and until a software item is submitted to a production code repository like CRAN, the recommended platform from which to install our software is that software’s GitHub repository.

5.3.4 - Archived releases

Software items that we have formally issued as “releases” are archived as permanent, uniquely identified (with DOI) and citable records within the ready4 Zenodo community. Archived releases of ready4 software are useful as they are snapshots of a project at key milestones in its development (e.g. at the time an analysis was undertaken). As these milestones are purposely selected, archived releases are more likely to have undergone some testing and documenting prior to being released than code not selected for release.

A limitation of archived code libraries is that a greater knowledge of R is required to appropriately install R packages from Zenodo compared to the simpler installation process for the versions of code libraries stored on either GitHub or CRAN.

5.4 - Code libraries

5.4.1 - Current libraries

5.4.1.1 - Framework libraries

The two types of framework library are:

• - the foundational ready4 module and syntax; and

• - tools to implement standardised, semi-automated workflows for authoring and documenting computational models.

Currently available framework libraries are summarised below.

Type	Package	Purpose	Documentation	Code	Examples
		Implement a Modular, Open Source Computational Model of Youth	Citation , Website , Manual - Short (PDF) , Manual - Full (PDF)	Dev , Archive	1, 2, 3, 4
		Retrieve, Label and Share Ready4 Datasets	Citation , Website , Manual - Short (PDF) , Manual - Full (PDF)	Dev , Archive	5, 6, 7
		Author Literate Programs to Implement and Report Ready4 Analyses	Citation , Website , Manual - Short (PDF) , Manual - Full (PDF)	Dev , Archive	8
		Author R Packages of Ready4 Model Modules	Citation , Website , Manual - Short (PDF) , Manual - Full (PDF)	Dev , Archive	9
		Author and Document Functions to Implement Ready4 Algorithms	Citation , Website , Manual - Short (PDF) , Manual - Full (PDF)	Dev , Archive	10
		Author Ready4 Model Modules	Citation , Website , Manual - Short (PDF) , Manual - Full (PDF)	Dev, Archive	11

5.4.1.2 - Model module libraries

Computational models developed with ready4 are intended to be both transferable (they are tools that can be used in multiple decision contexts) and modular (they are comprised of self-contained components, each of which performs a narrow sub-set of tasks). For these reasons, ready4 computational models are developed and distributed as libraries of modules.

The three types of computational module libraries are:

• - modules for describing and quality assuring model data;

• - modules to specify, assess and report statisitical models; and

• - modules for making predictions.

Currently available libraries of computational model modules are summarised below.

Type	Package	Purpose	Documentation	Code	Examples
		Describe and Validate Ready4 Person Record Datasets	Citation , Website , Manual - Short (PDF) , Manual - Full (PDF)	Dev , Archive	1, 2
		Score Ready4 Model Datasets	Citation , Website , Manual - Short (PDF) , Manual - Full (PDF)	Dev , Archive	3, 4
		Model Youth Choice Behaviours with Ready4	Citation , Website , Citation	Dev , Archive
		Implement Transfer to Utility Mapping Algorithms	Citation , Website , Manual - Short (PDF) , Manual - Full (PDF)	Dev , Archive	5
		Explore and Characterise Heterogeneity in Quality of Life Data	Citation , Website , Manual - Short (PDF) , Manual - Full (PDF)	Dev , Archive
		Specify Inverse Problems to Solve with Ready4	Citation , Website , Manual - Short (PDF) , Manual - Full (PDF)	Dev , Archive	6
		Transform Youth Outcomes to Health Utility Predictions with Ready4	Citation , Website , Manual - Short (PDF) , Manual - Full (PDF)	Dev , Archive	7

5.4.2 - Code library documentation

All ready4 code libraries have:

• a website, the URL of which typically takes the form of "https://ready4-dev.github.io/PACKAGE_NAME" (for example the website for the foundational ready4 R package is https://ready4-dev.github.io/ready4 );

• a brief PDF manual itemising the subset of classes, methods and functions that will be of interest to most end users, the URL of which takes the form of "https://github.com/ready4-dev/PACKAGE_NAME/releases/download/Documentation_0.0/PACKAGE_NAME_User.pdf" (for example, https://github.com/ready4-dev/ready4/releases/download/Documentation_0.0/ready4_User.pdf);

• a more comprehensive PDF manual itemising all included classes, methods and functions, including those that may only be of interest to developers of ready4 libraries, the URL of which takes the form of "https://github.com/ready4-dev/PACKAGE_NAME/releases/download/Documentation_0.0/PACKAGE_NAME_Developer.pdf" (for example, https://github.com/ready4-dev/ready4/releases/download/Documentation_0.0/ready4_Developer.pdf); and

• a publicly accessible record of the results of all continuous integration checks performed on each version of the source code, the url of which takes the form of "https://github.com/ready4-dev/PACKAGE_NAME/actions" (for example, https://github.com/ready4-dev/ready4/actions).

All ready4 code libraries include interactive help. Once you have installed and loaded a library, you can view its contents by using the command library(help="PACKAGE_NAME") (for example, library(help="ready4")).

Note that the manuals and files used by the interactive help are currently all automatically authored by tools from our ready4fun package and are therefore quite basic (and in some cases use clumsy English). In the future we hope to augment this machine generated documentation with human-authored documentation.

Most ready4 libraries (the exceptions are those at very early stages of development) have one or more vignette articles that provide examples of how to use it. These are available from the “Articles” section of each library’s website.

5.4.3 - Dependencies

As an open-source project, ready4 depends on the software created and shared by others. Using the DependenciesGraphs R package, we have created the Shiny app below to:

• explore the inter-dependencies between ready4 libraries;
• highlight how our software depends on other R packages;
• itemise the contents each ready4 library;
• display function help files; and
• map function inter-dependencies across multiple ready4 libraries.

To use the app, choose one of the two potential pathways:

• For Pathway 1, start at Step 1 (choose the libraries you wish to profile from the drop down menu and click on the Go button), before proceeding to Step 2 (click on one library that you wish to view the contents of), then Step 3 (click on the view functions button) and finally Step 4 (click on the function for which you would like to view documentation);
• For Pathway 2, start at Step 1 (choose libraries from the drop down menu), then Step 2 (click on the Find functions button), then Step 3 (select functions from the drop down menu) and finally Step 4 (click on the Make graph button).

Note, as the app is displayed on this page via an iFrame, it may be difficult to view on a phone. If so, you can try the following link: https://orygen.shinyapps.io/dependencies/

5.4.4 - Installation and set-up

ready4 libraries are currently only available as development releases, so you will need to use a tool like devtools to assist with installing ready4 R packages directly from our GitHub organisation. If you do not have devtools on your machine you can install it with the following command.

utils::install.packages("devtools")

5.4.4.1 - Installing the ready4 framework foundation library

Before you install

If you plan to use ready4 for any purpose, you will need to install the ready4 foundation library.

However, please note that the ready4 library is not yet available as a production release. You should therefore understand the limitations of using ready4 software development releases before you make the decision to install this software.

As all software in the ready4 suite depends on the ready4 library, so in most cases you do not need to install this library directly (it will come bundled with whatever other ready4 suite software you install).

If you can run the following command without producing an error message, then you already have it.

find.package("ready4")

Installation

You can install the ready4 library directly from its GitHub repository.

devtools::install_github("ready4-dev/ready4")

Try it out!

Before you apply ready4 tools to your own project, you should make sure you can run some or all of the example code included in the package vignettes.

5.4.4.2 - Installing authoring tools

5.4.4.2.1 - Installing tools for authoring model modules

Before you install

If you are a coder planning on using ready4 to author model modules, then you may wish to install the ready4class, ready4fun and ready4pack libraries.

However, please note that none of these libraries are yet available as a production release. You should therefore understand the limitations of using ready4 software development releases before you make the decision to install this software. We use these authoring tools intensively to help us write highly standardised model modules. However, we feel that these tools are most likely to be helpful to you once much more comprehensive documentation and training resources become available. Without this training and support, the requirements for complying with our house-style, file-naming, directory structure and workflow standards are unlikely to be sufficiently clear. We will be making these improvements, but for the mean time we recommend that, if you wish to use these authoring tools, you first get in touch with the project lead.

Installation

As ready4class and ready4fun are bundled as dependencies of ready4pack, you can install all three from our GitHub organisation using one command.

devtools::install_github("ready4-dev/ready4pack")

Configuration

To use these computational model authoring tools, you will need to have set-up and appropriately configured your own accounts in:

• GitHub (you will need write permissions to a GitHub organisation and to then enable GitHub actions and GitHub pages support for the repositories you create in that organisation);
• Zenodo (you will need to have linked each GitHub repository used for your ready4 projects to your Zenodo account); and
• Codecov (linked to your GitHub organisation).

The machine onto which you install ready4pack will also need to be securely storing your GitHub credentials (i.e. the value for the GITHUB_PAT token).

Try it out!

It should be noted that the development workflow supported by our computational model authoring tools is not yet well documented. We don’t recommend undertaking R package development with these tools until this has been rectified. However, if you still want to try these tools out, the best place to start is review the examples in the ready4class, ready4fun and ready4pack vignettes.

5.4.4.2.2 - Installing tools for authoring and managing model datasets

Before you install

If you are a coder or modeller planning to create, share and access model datasets with ready4, then you will need the ready4use library.

However, please note that ready4use is not yet available as a production release. You should therefore understand the limitations of using ready4 software development releases before you make the decision to install this software.

You may already have ready4use installed on your machine (e.g. if you have previously installed other ready4 framework and module libraries that include ready4use as a dependency). If you can run the following command without producing an error message, then you already have it.

find.package("ready4use")

Installation

You can install ready4use directly from its GitHub repository.

devtools::install_github("ready4-dev/ready4use")

Configuration

If one of your intended uses of ready4use is to share outputs in online datasets, you will need to have set up an account on a Dataverse installation (we recommend using the Harvard Dataverse). Some of the key terms and concepts relating to using a Dataverse installation in conjunction with ready4use are described in this tutorial.

You need to ensure that you have write permissions to any Dataverse Datasets that you plan to use to post files to. Furthermore, the machine on which you install ready4use should also securely store your Dataverse account credentials (specifically, values for the DATAVERSE_KEY and DATAVERSE_SERVER tokens). Details of how to do this are described in documentation for the dataverse R package, an important third party dependency package for ready4use.

Try it out

You should now be able to run the example code included in the package vignettes. To run all of this code you will need to replace the details of the Dataverse Dataset to which files are being written to those of your own Dataverse Dataset.

5.4.4.2.3 - Installing tools for authoring reproducible analyses

Before you install

If you are a coder or modeller planning to implement a reproducible analysis with ready4, you will need to install the ready4show library.

However, please note that ready4show is not yet available as a production release. You should therefore understand the limitations of using ready4 software development releases before you make the decision to install this software.

If you have installed other ready4 libraries, then ready4show may have already been installed as a dependency. If you can run the following command without producing an error message, then you already have it.

find.package("ready4show")

Installation

The ready4show library can be installed directly from its GitHub repository.

devtools::install_github("ready4-dev/ready4show")

Try it out!

Before you apply ready4show tools to your own project, you should make sure you can run some or all of the example code included in the package vignettes.

5.4.4.3 - Installing ready4 computational model modules

Before you install

If you plan on using existing ready4 modules for a modelling project, you can review currently available module libraries, to identify which libraries are relevant to your project.

However, please note that no ready4 module library is yet available as a [production release](/docs/getting-started/software/status/production-releases/. You should therefore understand the limitations of using ready4 software development releases before you make the decision to install this software.

Installation

The command to install each ready4 module takes the following format.

devtools::install_github("ready4-dev/PACKAGE_NAME")

For example, if you are planning to predict health utility using some of the mapping algorithms that we have previously developed, you can install the youthu library with the following command.

devtools::install_github("ready4-dev/youthu")

Configuration

A small number of ready4 modules require that you configure some of the dependencies installed with them before they can be used. In particular:

• if you are using modules from the TTU package to undertake a utility mapping study, you will need to have both installed and configured the cmdstanr R package as per the instructions on that package’s documentation website; and

• if you are using the mychoice package to undertake a discrete choice experiment study and are using a Mac, you need to ensure that you have a Fortran compiler installed. Some relevant advice on this: https://mac.r-project.org/tools/ .

Try it out!

Before you apply ready4 modules to your own project, you should make sure you can run some or all of the example code included in relevant library vignette articles. The package website URL takes the form of https://ready4-dev.github.io/PACKAGE_NAME/articles/ (e.g. the vignettes for the youthvars package are available at https://ready4-dev.github.io/youthvars/articles/).

5.5 - Executables

Currently all ready4 programs and subroutines are written in R Markdown. Each ready4 program and subroutine depends on at least one ready4 framework library as well as one or more ready4 module libraries. The required libraries will vary based on the purpose of the program. ready4 programs and subroutines typically generate reporting documents in file formats such as PDF, Word and HTML.

5.5.1 - Programs

What are ready4 programs?

Programs can be executed in their current form without the need for additional input data and, unless modified or run interactively (prompting a user for inputs during execution), will always generate the exact same output. They are typically deployed for configuring the run specifications of a computational model, specifying the data to which it will be applied and reporting analysis results.

Why are they useful?

ready4 programs can be used for the following purposes:

• to reproduce a study analysis, in which case you will need access to the original study data, and may also need to modify the program to specify the path to this data from your machine;
• to replicate a study analysis (ie to apply the study algorithm to similar but different input data [this can be a new sample from the same population or, if used for demonstration purposes, fake data representative of the original study dataset]), in which case you will need to modify the program to specify the path to this data; and
• to transfer a study analysis, in which case you use the program as a template to be modified to reflect key differences between the original study and your study.

Current ready4 programs

Currently available ready4 programs are summarised in the below table.

Documentation

ready4 programs are typically self-documenting, meaning that each section of code is integrated with plain English descriptions of the purpose it fulfills. The only programs that are not self-documenting are those whose primary purpose is to produce a document (normally an analysis report). Self-documenting programs and sub-routines will be typically documented as a PDF or HTML render of the RMarkdown source file. This rendered document will be bundled with the program, but in some cases may also be shared in online data repositories.

5.5.2 - Subroutines

What are ready4 subroutines?

Sub-routines need to be called by parent programs that supply them with input data. Sub-routines can be called by multiple programs and will produce output that varies based on the input values they are supplied with. They are typically deployed to implement parts of a model’s analysis and reporting algorithm.

Why are they useful?

ready4 subroutines can be used for the following purposes:

• to help execute a program or function written by a third party (in which case you probably won’t need to modify the subroutine and may not even be aware that it is being used);
• to help execute a program or function that you write (in which case, you shouldn’t have to modify the subroutine, but may find it useful to customise it to your purposes); and
• to serve as a template for subroutines you write yourself that perform similar tasks (in which case you will be rewriting the subroutine’s code).

Current ready4 subroutines

Currently available ready4 subroutines are summarised in the below table.

Documentation

ready4 programs are currently minimally documented, typically in the form as notes contained in a README file in the source code bundle.

5.6 - User interfaces

ready4 user-interfaces (UIs) enable individuals, especially planners, to explore, configure and use ready4 tools without needing to enter any computer code. Our UIs are typically deployed as Shiny apps an may have deployments via the web (accessed through your browser) or to your desktop (installed as part of a ready4 library).

The main purposes of ready4 user-interfaces are:

• to make it easy for non-technical users to configure a computational model and apply it to selected input data; and

• as an accessible and interactive means of demonstrating key concepts relating to ready4.

The user interface for exploring the dependencies of ready4 libraries is an example of the latter use.

We do not have any current releases of ready4 user interfaces for running models. However, an old and deprecated user interface for running the Springtides model is available for purely illustrative purposes.

5.7 - Terms of use

5.7.1 - Open source licensing

To help ensure the models we develop are as transparent as possible and to make their algorithms as useful to others as possible, all ready4 software is free and open-source. You are encouraged to make as widespread use of our software, including the creation of derivative works, as you see fit, so long as it is consistent with each item’s license. Our software is typically licensed under GPL-3, a copy-left open-source licensing regime.

5.7.2 - Citing ready4

To make it easier to cite our software, each software item bundle includes a CITATION.cff file. Inclusion of this file means that the repositories storing our software can generate appropriate citations in the format of most relevance to you.

Currently:

• Zenodo provides a free text field under the heading “Cite as” which enables you to generate a wide range of citation manager and journal specific citation outputs. There is also an “Export” tool that will generate citation metadata in multiple output formats;
• OpenAire Explore has a “Cite this software” button that allows you to generate a citation in multiple journal formats or to download BibTeX or RIS files;
• Github repositories have a “Cite this repository” button that can generate both BibTeX and APA output as well as link to the Citation.cff file.

Additionally, we have included a CITATION file in each of our R libraries so that you can generate a citation from within an R session using the citation function (for example: citation("ready4").

5.7.3 - Disclaimer

All ready4 software is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Furthermore, no ready4 software is yet sufficiently well documented and tested to be given a production release. All ready4 software should therefore viewed as experimental development releases.