v2.3.2

DOI Publication registration through Zenodo.

v2.3.1

Overview

This release addresses some basic bugs and adds the initial state to the histories. It also shifts the default history creation to the model instead of the simulation. Now, all histories contain a 0 state corresponding to the model just before the first transition. Any deaths and movements should be 0 during this state.

Next Focus

Future work will focus on bug fixes as we move into a calibration focus.

v2.3.0

What's New?

This release focuses on changes in how transitions function. Instead of operating through functions defined in the top level respond.hpp file, there is a new Transition abstract class that is intended to be subclassed. This now allows us to create transitions as needed. They can be created through the TransitionFactory and via the name specification.

Along with the Transition class all other classes received a quality of life improvement. All that are created through factory pattern design now follow the Rule of Five and have corresponding clone methods to handle the unique pointer nature. This ensures we no longer have memory slicing like we saw in previous iterations.

Testing

Testing was completely overhauled in this release. Now, tests are split into unit and integration tests. Unit tests focus on the individual function testing where the integration verifies the interplay between the classes. All tests should pass and currently provide a nearly 80% coverage of the code base. They also form the basis of testing in the respondpy and respond-calibration smoke tests.

Next Steps

The next steps will involve cleaner creation of default histories. At the moment it is a static method part of the Simulation but as histories exist with a one to many relationship with models, it might be more applicable to move them there. This is still up for discussion.

v2.2.1

Transition Functions and the History Stamp

This patch addresses the accessibility of the HistoryStamp. Previously, the stamp only recorded all overdoses, state, and intervention admissions. This made accessing the fatal overdoses and the background mortality metrics difficult to obtain. Thus, we added some new trackers to the HistoryStamp and broke out the stamper behavior. Instead of having unique stamper functions to record the history stamp we instead applied the HistoryStamp as a parameter to each transition function so it can be adjusted there.

Additionally, all transition functions saw their state parameter turned into a const variable to prevent accidental mutation. Instead, we now expect the pattern to be a const state, const transition, and mutable history stamp passed in to the transition and a resultant state vector returned. This required some changes to the overdose transition model.

Finally, we also addressed some bugs in the model around calculating the background mortality. Previously we were returning the people that died rather than the people that survived.

v2.2.0

Release 2.2.0

This is an overhaul of the model from previous versions. Now we are completely within a Markov framework and have focused now on removing confounding components/making it easier to add/remove nodes in the network.

Changes:

• Removed build init effects
• Reworked CMake and CPack
• Added Docker image builds
• Added shared and static library builds
• Removed the base RESPOND executable
• Added a windows static build
• Updated the CMakePresets
• Added an example sim.conf file and database schema
• Code cleaning

v0.3.0

Version of RESPOND used for calibration for DPA, Kentucky, and DCEA preliminary results. This version specifically incorporates DataLoaders, file writers, the DataManagement repository, and python bindings for it all. It also expects demographics in the input files and behaviors/interventions in the sim.conf.

v0.2.0-alpha

The core update here focuses on bringing RESPOND into a more modern approach design wise. It breaks out the includes into a public folder and makes CMake behaviors easier to understand. In addition, there is a basic level of workflow breakdown that accompanies the release. This release is targeted to allow users to make use of the sim.conf file with the ouds section rather than the future named behaviors section.