Sharing and archiving

Learning objectives:

  • Identify suitable methods for sharing your simulation code.
  • Learn about reporting and sharing guidelines.
  • Understand how to archive repository on Zenodo via GitHub releases.

Relevant reproducibility guidelines:

  • NHS Levels of RAP (🥉): Code is published in the open and linked to & from accompanying publication (if relevant).

Sharing your simulation model

In our recent review, we explored whether and how healthcare discrete-event simulation (DES) models have been shared over the last few years:

Monks, T., & Harper, A. (2023). Computer model and code sharing practices in healthcare discrete-event simulation: a systematic scoping review. Journal of Simulation, 19(1), 108–123. https://doi.org/10.1080/17477778.2023.2260772.

Here are some key take-homes from that study…


1. Share your model

Any sharing is better than nothing.

Our review found only 8.3% (n=47/564) of healthcare DES studies shared their model.

You may consider including a data availability statement such as “the materials used within this study are available from the corresponding author on reasonable request”. However, we do not recommend relying on this approach. Studies show these statements are rarely upheld, even if well intentioned to begin with - often because projects and staff move on, and code gets lost. For example, a large review by Janssen et al. (2020) found that less than 1% of authors responded - and of those, fewer still shared code.

Instead, you should aim to share as much as possible directly - ideally, providing complete materials, from input data (see Input data management page for details), through to the code needed to generate figures and tables.


2. Use effective sharing platforms

How you share matters. Better platforms make it easier for others to access, review, and reuse your work.

Although it is possible to share code files as journal/report supplementary materials, we do not recommend this as a primary method. Supplementary files are often converted into awkward formats (such as PDF or Word), which strips away features like syntax highlighting and makes it difficult to run or modify the code. These files also lack support for collaborative tools like version control, issue tracking, and automated testing.

A better approach is to use dedicated code-sharing platforms like GitHub (the most popular for DES models in our review). These platforms are specifically designed for open sharing, allow version control, and make it easy for others to follow changes, contribute or raise issues.

Tip

For a tutorial on setting up GitHub, see the Version control page.

For even better long-term access, you should also deposit your code and materials in a digital archive. This ensures your code is preserved and citable over time. See the archiving section below for mode details.


3. Don’t leave sharing to the end of your project

In our review, we found DES GitHub repositories with only one or a few commits, indicating that model code was uploaded only at the very end of the project. When sharing is left until the end, there’s often less time to ensure quality: important elements like documentation, licenses, and usage instructions are frequently missing or rushed.

It’s much better to plan for sharing from the outset - ideally by using version control from the start of your project. This makes it easier to keep track of changes, gradually improve documentation, and make sure everything is ready for when you’re ready to publish.


4. Follow guidelines

Reporting guidelines can help make sure you document your model clearly. Only 12.8% of the models in our review mentioned using a simulation reporting guideline or general checklist. For DES, relevant guidelines include:

Reporting guideline Citation Focus
Strengthening the reporting of empirical simulation studies-DES (STRESS-DES) Monks et al. (2019) Reporting all necessary information for replication of DES models
Generic reporting checklist Zhang et al. (2020) DES model quality
International Society for Pharmacoeconomics and Outcomes Research - Society for Medical Decision Making (ISPOR-SMDM) Good Research Practices Task Force reports Various Health economic and decision modelling best practices
TRAnsparent and Comprehensive model Evaluation (TRACE) Grimm et al. (2014) Transparent documentation and evaluation of models
The Overview, Design concepts and Details (ODD) protocol for describing Individual- and Agent-Based Models (ABMs) Grimm et al. (2020) Protocol for describing agent-based models (not designed for DES)


Sharing guidelines focus on how you share your code, data and supporting materials - and what you share!

Sharing guideline Citation Focus
STARS framework Monks et al. (2024) DES model sharing and reuse
STARS reproducibility recommendations Heather et al. (2025) DES model reproducibility
NHS “Levels of RAP” Maturity Framework NHS RAP Community of Practice Developing reproducible analytical pipelines in NHS analyses
Open Modelling Foundation (OMF) Standards OMF Community Model accessibility, documentation and reusability (in future, plan to include interoperability standards)

Journal sharing requirements

If you are publishing a paper about your model, you many come across journal sharing requirements. These policies are becoming more common, and may affect how you prepare your code and data for submission.

Requirements can include:

  • Badges or recognition: Many journals award open science badges to articles with shared code or data.
  • Mandatory code sharing: Some journals require that you publicly share your code.

Some journals go further by reviewing the code your submit, with requirements like:

  • Open licenses
  • Clear documentation
  • Complete materials
  • Details on the environment used
  • Runnable materials

Archives

Whilst platforms like GitHub are great for sharing code, they provide no guarantees on how long the code will be stored. For this reason, we recommend also depositing your code in an open science archive.

Open science archives will provide long-term storage guarantees ensuring future access to your work. They and will create a digital object identifier (DOI) (a persistent identifier for your code).

Archives should adhere to recognised principles like TRUST (Transparency, Responsibility, User focus, Sustainability, and Technology) and the FORCE11 standards

Archives can be generalist (for any research discipline), subject-specific, or institutional (hosted by a particular university or research institute). Examples include:

If choosing between generalist repositories, the Generalist Repository Ecosystem Initiative (GREI) has resources to support you in choosing an appropriate repository summarised here, with examples including:

How to archive your repository on Zenodo

We will provide a tutorial on how to use one example, Zenodo, it’s what we’ve chose, as easy to use, integration with GitHub. so this shows how to use with github… here is github poage with turotial - https://docs.github.com/en/repositories/archiving-a-github-repository/referencing-and-citing-content


1. Login to Zenodo. Go to https://zenodo.org/login/, and login or sign-up to Zenodo with your GitHub account.


2. Go to Zenodo GitHub page. Click on the arrow in the top right corner, and select “GitHub”.


3. Sync your repository. On this page, you should see a list of your repositories. For the repository you want to archive on Zenodo, toggle the switch from “OFF” to “ON”.

Tip

Can’t find your repository?

  • Click the “Sync now” button to update your repository list.

  • Make sure your repository is public, else Zenodo cannot access it.

  • If your repository is part of a GitHub organisation, you may need to approve access for the Zenodo application in the organisation settings.


4. Prepare your GitHub repository. Before archiving, ensure your repository contains:

  • A licence.
  • A CITATION.cff file (this supplies key metadata like title, authors, and version for Zenodo’s record).


5. Create a GitHub release. To trigger Zenodo archiving, create a new release in your repository. For details on how to do this, see the Changelog page.


6. View your Zenodo entry. Click the repository name in Zenodo to view its releases, metadata, and related issues. If all goes well, you should see a new release and DOI listed - for example:


Clicking the DOI (for example: 10.5281/zenodo.17094156) opens the permanent archived version of our repository in Zenodo:

Zenodo communities

The “Communities” feature in Zenodo is useful for grouping related archived repositories in one place (e.g., those from the same project or research group). It’s also valuable for collaborative work, as community members can be granted edit access to manage and update shared records.

To set-up a community, visit https://zenodo.org/communities and select  + New community 

Once your community is set up, go to your Zenodo record/s and scroll down to “Communities”, then click “+ Submit to community”.


Search for your community, give appropriate permissions, and submit.


From the “Requests” tab of your community dashboard, you can then accept this submission to add it to the community.

Explore the example models

GitHub Click to visit pydesrap_mms repository

GitHub Click to visit pydesrap_stroke repository

GitHub Click to visit rdesrap_mms repository

GitHub Click to visit rdesrap_stroke repository

These repositories are shared on GitHub (since the start of development) and are archived on Zenodo.

Test yourself

NoteWhy is it risky to rely only on “code available on request” statements when sharing a simulation model?
NoteWhen is the best time to start using version control and planning for sharing in a simulation project?
NoteWhat do open science archives provide that GitHub does not?


Ready to put this into practice? Try archiving your simulation repository - even if it’s just an early version or draft!