Merge pull request #110 from pythonhealthdatascience/dev

Dev

Author: amyheather

.flake8

@@ -1,6 +1,8 @@
 [flake8]
 per-file-ignores =
     docstrings*.py: F811
+    length_warmup*.py: F401,F821
+    logs*.py: F811
     n_reps*.py: E0602,F401,F821,W0611
     outputs*.py: F811
     parallel*.py: F401,F821
@@ -9,5 +11,7 @@ per-file-ignores =
     replications*.py: F401,F811,F821
     scenarios*.py: F401,F821
     tables_figures*.py: F401,F821
+    tests*.py: F821
+    tests_resources/*.py: E0401
     */outputs_resources/*.py:E261,E262,F821
     */replications_resources/*.py:E261,E262,F821

.lintr

@@ -8,13 +8,16 @@ exclusions: list(
     "pages/inputs/parameters_validation.qmd" = list(
         object_usage_linter = 771:772
       ),
+    "pages/output_analysis/length_warmup.qmd" = list(
+        unused_import_linter = Inf
+      ),
     "pages/output_analysis/n_reps.qmd" = list(
         unused_import_linter = Inf,
         object_usage_linter = Inf
       ),
     "pages/output_analysis/outputs.qmd" = list(
-        one_call_pipe_linter = 898,
-        line_length_linter = 2828
+        one_call_pipe_linter = 904,
+        line_length_linter = 2837
       ),
     "pages/output_analysis/parallel.qmd" = list(
         object_usage_linter = Inf,
@@ -30,5 +33,14 @@ exclusions: list(
         object_usage_linter = Inf
       ),
     "pages/style_docs/linting_resources/code.R",
+    "pages/verification_validation/tests_resources/simulation.R" = list(
+        one_call_pipe_linter = 228
+      ),
+    "pages/verification_validation/tests_resources/test_back.R" = list(
+        expect_identical_linter = Inf
+      ),
+    "pages/verification_validation/tests.qmd" = list(
+        library_call_linter = Inf
+      ),
     "renv"
   )

CHANGELOG.md

@@ -5,6 +5,54 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). Dates formatted as YYYY-MM-DD as per [ISO standard](https://www.iso.org/iso-8601-date-and-time-format.html).
 
+## v0.2.0 - 2025-10-14
+
+### Added
+
+* Logging page
+* Output analysis section covering:
+    * Initialisation bias
+    * Performance measures
+    * Replications
+    * Parallel processing
+    * Number of replications
+    * Length of warm-up
+* Experimentation section covering:
+    * Scenario and sensivity analysis
+    * Tables and figures
+    * Full run
+* Verification and validation section covering:
+    * Verification and validation
+    * Tests
+* Style and documentation section covering:
+    * Linting
+    * Docstrings
+    * GitHub actions
+    * Documentation
+* Collaboration and sharing section covering:
+    * Code review
+    * Licensing
+    * Citation
+    * Changelog
+    * Sharing and archiving
+* Add citation to footer.
+* Add pre-commits.
+* Add `all-contributors`.
+* Add `CONTRIBUTING.md`.
+
+### Changed
+
+* Redid the introduction box for each page to be simpler/clearer.
+* Moved giscus `comments` settings to `_quarto.yml` so can have comments on index page.
+* Improvements to existing pages (citations, illustrations, links, `.lightbox`).
+* Switched to consistent modern execution options syntax.
+
+### Fixed
+
+* Parameters from file (don't generate PDF).
+* Input modelling (correct `python-content` to `r-content`).
+* Add padding to bottom of side bar so can see all pages (otherwise cuts off for some reason sometimes).
+
 ## v0.1.0 - 2025-09-10
 
 🌱 Initial release of the website (work in progress). This version introduces the website structure and the first written sections (up to *Output Analysis*).

CITATION.cff

@@ -41,5 +41,5 @@ keywords:
   - simmer
   - rap
 license: MIT
-version: '0.1.0'
-date-released: '2025-09-10'
+version: '0.2.0'
+date-released: '2025-10-14'

DESCRIPTION

@@ -7,10 +7,12 @@ Imports:
     future,
     future.apply,
     ggplot2,
+    gridExtra,
     jsonlite,
     kableExtra,
     lintr,
     lubridate,
+    patrick,
     plotly,
     prettycode,
     readr,

_quarto.yml

@@ -53,15 +53,16 @@ website:
       - pages/output_analysis/replications.qmd
       - pages/output_analysis/parallel.qmd
       - pages/output_analysis/n_reps.qmd
+      - pages/output_analysis/length_warmup.qmd
     - section: "Experimentation"
       contents:
       - pages/experiments/scenarios.qmd
       - pages/experiments/tables_figures.qmd
       - pages/experiments/full_run.qmd
     - section: "Verification & validation"
       contents:
+      - pages/verification_validation/verification_validation.qmd
       - pages/verification_validation/tests.qmd
-      - pages/verification_validation/validation.qmd
     - section: "Style & documentation"
       contents:
       - pages/style_docs/linting.qmd

pages/inputs/input_data.qmd

@@ -126,7 +126,7 @@ Example data dictionary:
 
 #### Obtaining a DOI
 
-If you’re able to openly share the data, you can include it directly in your GitHub repository alongside your code and documentation for convenience and reproducibility. For longer-term access, public citation, or larger datasets, it’s often better to deposit the data in a separate and/or specialised repository, and then simply link from your code to the archive record.
+If you're able to openly share the data, you can include it directly in your GitHub repository alongside your code and documentation for convenience and reproducibility. For longer-term access, public citation, or larger datasets, it's often better to deposit the data in a separate and/or specialised repository, and then simply link from your code to the archive record.
 
 As described in the ["The Research Data Management Workbook"](https://caltechlibrary.github.io/RDMworkbook/), when choosing where to store data, you should consider the available data repository types:
 

pages/inputs/input_modelling.qmd

@@ -85,7 +85,7 @@ When selecting appropriate distributions, if you only have summary statistics (l
 
 However, these standard choices may not always be appropriate. If the actual process differs from your assumptions or has unique features, the chosen distribution might not fit well.
 
-Therefore, if you have enough data, it’s best to analyse it directly to select the most suitable distributions. This analysis generally involves two key steps:
+Therefore, if you have enough data, it's best to analyse it directly to select the most suitable distributions. This analysis generally involves two key steps:
 
 1. **Identify possible distributions**. This is based on knowledge of the process being modelled, and by inspecting the data using time series plots and histograms.
 2. **Fit distributions to your data and compare goodness-of fit**. You can do this using a:

pages/inputs/parameters_validation.qmd

@@ -102,7 +102,7 @@ params = ParamClass()
 print(params.__dict__)
 ```
 
-Now let’s introduce a typo:
+Now let's introduce a typo:
 
 ```{python}
 params.transfer_probs = 0.4

pages/model/distributions.qmd

@@ -46,7 +46,7 @@ When simulating real-world systems (e.g. patients arriving, prescriptions queuei
 
 ![](../inputs/input_data_resources/samples.png)
 
-However, computers can't generate "true" randomness. Instead, they use **pseudorandom number generators (PRNGs)**: algorithms which produce a sequence of numbers that appear random, but are in fact completely determined by an initial starting point called a **seed**. If you use the same seed, you’ll get the same random sequence every time - a crucial feature for reproducibility in research and development.
+However, computers can't generate "true" randomness. Instead, they use **pseudorandom number generators (PRNGs)**: algorithms which produce a sequence of numbers that appear random, but are in fact completely determined by an initial starting point called a **seed**. If you use the same seed, you'll get the same random sequence every time - a crucial feature for reproducibility in research and development.
 
 By default, most software PRNGs initialise the seed based on something that changes rapidly and unpredictably, such as the current system time. This ensures a unique sequence with every fresh run. But for **reproducible experiments**, you should manually set the seed yourself, allowing you and others to exactly recreate simulation results.
 
@@ -317,7 +317,7 @@ We also acknowledge the work of B. Lawson and L. M. Leemis for the `simEd` packa
 
 ### Which package did we use?
 
-We've used R's standard random sampling functions in the example models in this book. This is mainly because they're fast, even though all draws share a single global random stream. If you need independent streams, the `simEd` package allows for that, but it can slow things down—which is why we didn’t use it here.
+We've used R's standard random sampling functions in the example models in this book. This is mainly because they're fast, even though all draws share a single global random stream. If you need independent streams, the `simEd` package allows for that, but it can slow things down—which is why we didn't use it here.
 
 ::::
 
@@ -327,7 +327,7 @@ These quirks with random number streams are **worth understanding**, especially
 
 ::: {.python-content}
 
-With Python, it’s easy to avoid pitfalls from shared random number streams - just use the new Generator API (`np.random.default_rng`) to create separate generators for each process in your simulation, rather than sharing a global one, or packages like `sim-tools`. That said, for most simulations, even if you use a single stream, the impact is usually minor - so it’s not something to stress over.
+With Python, it's easy to avoid pitfalls from shared random number streams - just use the new Generator API (`np.random.default_rng`) to create separate generators for each process in your simulation, rather than sharing a global one, or packages like `sim-tools`. That said, for most simulations, even if you use a single stream, the impact is usually minor - so it's not something to stress over.
 
 :::