From c8882950683c58dc0552d2307195479ee828de32 Mon Sep 17 00:00:00 2001 From: amyheather Date: Fri, 13 Mar 2026 15:08:26 +0000 Subject: [PATCH 1/9] feat(index): add link to strategy unit model --- index.qmd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.qmd b/index.qmd index 7483dbe..124203d 100644 --- a/index.qmd +++ b/index.qmd @@ -33,7 +33,7 @@ The material is designed for analysts, researchers, and students in health and o ::: {.pale-blue} -"The DES RAP Book was a valuable resource in our transition to open-source DES modelling. It provided us with a step-by-step structure to follow and guidance on best practice for writing code, tests and documentation for our package. Our model is being using in the Midlands, and beyond, for understanding future demand and capacity within Kidney Replacement Therapy." - **Lucy Morgan, Analytics Manager at The Strategy Unit**. +"The DES RAP Book was a valuable resource in our transition to open-source DES modelling. It provided us with a step-by-step structure to follow and guidance on best practice for writing code, tests and documentation for our package. [Our model](https://www.strategyunitwm.nhs.uk/news/planning-rising-renal-demand-simulating-capacity-across-care-system) is being using in the Midlands, and beyond, for understanding future demand and capacity within Kidney Replacement Therapy." - **Lucy Morgan, Analytics Manager at The Strategy Unit**. ::: From f1224742e813d8e4850875a83d9103ca0c721e87 Mon Sep 17 00:00:00 2001 From: amyheather Date: Tue, 19 May 2026 15:51:08 +0100 Subject: [PATCH 2/9] feat(index/impact): add quote from dan (#199) --- index.qmd | 6 ++++++ pages/impact/impact.qmd | 9 ++++----- 2 files changed, 10 insertions(+), 5 deletions(-) diff --git a/index.qmd b/index.qmd index 124203d..35d5de2 100644 --- a/index.qmd +++ b/index.qmd @@ -50,6 +50,12 @@ After working through this resource, you will be able to: * Improve **style, documentation, and automation** with linting, docstrings, and GitHub Actions. * **Collaborate and share** your work effectively, including code review, licensing, citation, changelogs, and archiving. +::: {.pale-blue} + +"The DES RAP Book is a phenomenal resource that is being used extensively to enhance the training content of the national Health Service Modelling Associates (HSMA) Programme. It provides clear, well-structured instructions and easy to follow examples that will ensure the approaches we teach to the next generation of health data scientists are reproducible, rigorous and transparent. As well as informing the content of the training we will be signposting to this book as an invaluable reference for our students as they take their first steps into the world of Discrete Event Simulation" - **Dr Daniel Chalk, Senior Research Fellow at the University of Exeter**. + +::: + > If you use the DES RAP book in your teaching, research, or training, we'd love to hear about it. Please [get in touch](/pages/guide/further_info/feedback.qmd) to share how you've used the material, suggest improvements, or point us to example models or case studies that others might find helpful. > > Educators and trainers can adopt the book as a complete syllabus for a short course or reuse individual chapters as standalone teaching units (for example, sessions on RAP, testing, packaging, or sharing models), and should cite the resource when they do so in line with the provided citation below. The accompanying code is released under an MIT licence, and the text is available under a CC BY-SA 4.0 licence, allowing reuse and adaptation with appropriate attribution. diff --git a/pages/impact/impact.qmd b/pages/impact/impact.qmd index eb7dcaa..d28aa12 100644 --- a/pages/impact/impact.qmd +++ b/pages/impact/impact.qmd @@ -28,11 +28,10 @@ This page highlights how the DES RAP Book is being used and referenced by the co The DES RAP Book is already being used and adapted in several teaching and training contexts. -* **NHS Somerset workshop (planned)** - It will be used in a workshop with an NHS Somerset team, to support them in improving their simulation model. +* **HSMA "Little Book of DES"** + DES RAP Book is referenced in several places in the [Little Book of DES](https://des.hsma.co.uk/) from the [Health Service Modelling Associates (HSMA) Programme](https://hsma.co.uk/) at the University of Exeter, and is being used to support their curriculum revamp. + +> "The DES RAP Book is a phenomenal resource that is being used extensively to enhance the training content of the national Health Service Modelling Associates (HSMA) Programme. It provides clear, well-structured instructions and easy to follow examples that will ensure the approaches we teach to the next generation of health data scientists are reproducible, rigorous and transparent. As well as informing the content of the training we will be signposting to this book as an invaluable reference for our students as they take their first steps into the world of Discrete Event Simulation" - **Dr Daniel Chalk, Senior Research Fellow at the University of Exeter**. * **Coding for Reproducible Research (R environments)** Material from the DES RAP Book has been adapted for use in the R environments module of the [Coding for Reproducible Research](https://coding-for-reproducible-research.github.io/CfRR_Courses/short_courses/r_environments.html) Training Programme from the University of Exeter. - -* **HSMA "Little Book of DES"** - DES RAP Book is referenced in several places in the [Little Book of DES](https://des.hsma.co.uk/) from the [Health Service Modelling Associates (HSMA) Programme](https://hsma.co.uk/) at the University of Exeter. From 2400d85b7b0bcd510704b85cbceecc1015950c3f Mon Sep 17 00:00:00 2001 From: amyheather Date: Tue, 19 May 2026 15:53:45 +0100 Subject: [PATCH 3/9] feat(environment): add delete instructions (#198) --- pages/guide/setup/environment.qmd | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/pages/guide/setup/environment.qmd b/pages/guide/setup/environment.qmd index 6d9f4f3..a9b49fd 100644 --- a/pages/guide/setup/environment.qmd +++ b/pages/guide/setup/environment.qmd @@ -428,6 +428,20 @@ dependencies: When working on a project from scratch, you will often build up your environment organically and iteratively as you find more packages you want to use. +#### Deleting the environment + +To delete your environment, first deactivate it: + +```{.bash} +conda deactivate envname +``` + +You can then run: + +```{.bash} +conda remove -n envname --all +``` + :::: :::: {.r-content} From b4f65785d7c201fc6f6bbd310e8302aa73ba348d Mon Sep 17 00:00:00 2001 From: amyheather Date: Tue, 19 May 2026 16:05:15 +0100 Subject: [PATCH 4/9] feat(vv): add execution tracing (#196) --- .../verification_validation.qmd | 14 ++++++++++++-- .../verification_validation_checklist.md | 5 ++++- 2 files changed, 16 insertions(+), 3 deletions(-) diff --git a/pages/guide/verification_validation/verification_validation.qmd b/pages/guide/verification_validation/verification_validation.qmd index b9fe4ff..e92e9ca 100644 --- a/pages/guide/verification_validation/verification_validation.qmd +++ b/pages/guide/verification_validation/verification_validation.qmd @@ -103,12 +103,22 @@ You'll probably perform debugging naturally as you code the model - but it is he ✔️ Write tests - they'll help you spot bugs (see [tests](tests.qmd) page). -✔️ As you develop the model, monitor it using logs - this will also help you spot bugs (see [logs](../model/logs.qmd) page). - ✔️ Use GitHub issues to record bugs as they arise, so you don't forget about them and so you have a record for future reference (see section on GitHub issues on the [peer review](../sharing/peer_review.qmd#github-issues) page). ::: +### Execution tracing + +@Balci1998 describes **execution tracing** as watching the model outputs, following the detailed sequence of events, state changes, and decisions as the model runs, and checking them against what you expect. + +::: {.cream} + +**What does this mean in practice?** + +✔️ Add logging or tracing output around key decisions (see [logs](../model/logs.qmd) page). Run the model for a short, controlled period and manually check the trace against your conceptual model. + +::: + ### Assertion checking As defined in @Balci1998, this technique involves making **assertions** - i.e., outlining the expected behaviour of your model. You should then check to ensure these hold true. These assertions can be placed throughout your code, monitoring things like: diff --git a/pages/guide/verification_validation/verification_validation_resources/verification_validation_checklist.md b/pages/guide/verification_validation/verification_validation_resources/verification_validation_checklist.md index 95a7917..1c2eb84 100644 --- a/pages/guide/verification_validation/verification_validation_resources/verification_validation_checklist.md +++ b/pages/guide/verification_validation/verification_validation_resources/verification_validation_checklist.md @@ -15,9 +15,12 @@ Desk checking Debugging * [ ] Write tests - they'll help for spotting bugs. -* [ ] During model development, monitor the model using logs - they'll help with spotting bugs. * [ ] Use GitHub issues to record bugs as they arise, so they aren't forgotten and are recorded for future reference. +Execution tracing + +* [ ] Add logging or tracing output around key decisions. Run the model for a short, controlled period and manually check the trace against your conceptual model. + Assertion checking * [ ] Add checks in the model which cause errors if something doesn't look right. From 276ded3468cf1c4a6af0ef2a2cde055ab58bb2de Mon Sep 17 00:00:00 2001 From: amyheather Date: Tue, 19 May 2026 16:09:06 +0100 Subject: [PATCH 5/9] chore(vv): clarify execution tracing as verification and animation visualisation as validation --- .../guide/verification_validation/verification_validation.qmd | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pages/guide/verification_validation/verification_validation.qmd b/pages/guide/verification_validation/verification_validation.qmd index e92e9ca..d394675 100644 --- a/pages/guide/verification_validation/verification_validation.qmd +++ b/pages/guide/verification_validation/verification_validation.qmd @@ -109,7 +109,7 @@ You'll probably perform debugging naturally as you code the model - but it is he ### Execution tracing -@Balci1998 describes **execution tracing** as watching the model outputs, following the detailed sequence of events, state changes, and decisions as the model runs, and checking them against what you expect. +@Balci1998 describes **execution tracing** as watching the model outputs, following the detailed sequence of events, state changes, and decisions as the model runs, and checking them against what you expect. We are comparing against the conceptual model / expected logic. ::: {.cream} @@ -369,7 +369,7 @@ Predictive validation is a requirement in the DES reporting checklist from @Zhan ### Animation visualisation -If you build an animation that shows your simulation model as it runs, it can help you spot errors by letting you "see" what's happening (@Balci1998). You can watch patients flow, queues grow and shrink, and resources being used - and you maybe be able to spot odd behaviours. +If you build an animation that shows your simulation model as it runs, it can help you spot errors by letting you "see" what's happening (@Balci1998). You can watch patients flow, queues grow and shrink, and resources being used - and you maybe be able to spot odd behaviours. Animation can also support verification by revealing obvious implementation bugs, but here we emphasise its use for assessing whether behaviour 'looks like' the real system. :::: {.cream} From dff93c1957d3709e89542ca317ab1bbbc5b24af3 Mon Sep 17 00:00:00 2001 From: amyheather Date: Tue, 19 May 2026 16:48:00 +0100 Subject: [PATCH 6/9] feat(conceptual): write page (in-progress - need to add section on when des is right approach) (#200) --- _quarto.yml | 1 + pages/guide/setup/conceptual.qmd | 140 ++++++++++++++++++ .../setup/conceptual_resources/references.bib | 9 ++ 3 files changed, 150 insertions(+) create mode 100644 pages/guide/setup/conceptual.qmd create mode 100644 pages/guide/setup/conceptual_resources/references.bib diff --git a/_quarto.yml b/_quarto.yml index 7e259c8..b87e3a4 100644 --- a/_quarto.yml +++ b/_quarto.yml @@ -66,6 +66,7 @@ website: - pages/guide/setup/environment.qmd - pages/guide/setup/package.qmd - pages/guide/setup/code_structure.qmd + - pages/guide/setup/conceptual.qmd - section: "Model inputs" contents: - pages/guide/inputs/input_modelling.qmd diff --git a/pages/guide/setup/conceptual.qmd b/pages/guide/setup/conceptual.qmd new file mode 100644 index 0000000..7c595a7 --- /dev/null +++ b/pages/guide/setup/conceptual.qmd @@ -0,0 +1,140 @@ +--- +title: Conceptual modelling +bibliography: conceptual_resources/references.bib +date: "2026-05-19T10:26:08+00:00" +--- + + + + +::: {.pale-blue} + +**Learning objectives:** + +* Decide when discrete-event simulation is an **appropriate technique** for a problem. +* Understand what a **conceptual model** is and identify the key components of a conceptual model. +* Apply **model simplification** strategies to build the simplest model that meets study objectives. + +**Acknowledgements:** This page was written with reference to the excellent content on conceptual modelling in @Robinson2014. + +::: + +## What is a conceptual model? + +A **conceptual model** is a description of the simulation to be developed. It sits between the real-world problem and the computer implementation, capturing *what* the model needs to do before *how* it will be coded (@Robinson2014). + +Developing a conceptual model involves: + +1. Determining whether simulation is the appropriate modelling approach. +2. Describing the model itself - its purpose, boundaries, data, and assumptions. + +This description serves as a reference point during model development, for [verification](/pages/guide/verification_validation/verification_validation.qmd), and for any future collaborators or users of the model. + +## Is DES the right approach? + +TODO. + +## Components of a conceptual model + +@Robinson2014 break a conceptual model down into five key components: + +* Objectives +* Inputs +* Outputs +* Content +* Assumptions and simplifications + +### Objectives + +State clearly what question the model is being built to answer, and what constraints apply. If you cannot write a one-sentence answer to "what decision will this model inform?", the objective is not ready yet. + +There are two levels of objectives to consider: + +::: {.blue-table} + +| Level | Description | +| - | -- | +| **Modelling objectives** | What do you hope to achieve by the end of the study? What targets are you aiming for? What scenarios are in scope? | +| **Project objectives** | Practical constraints that shape the model including timescale, required flexibility, run speed, visual display requirements, and ease of use for intended users. | + +::: + +### Inputs + +List the **parameters you plan to vary**, and the ranges you'll vary them over. + +Ideally, also decide *how* inputs will be supplied (e.g., within a script, read from a file, entered via a user interface) since this affect how the model code is designed. This will depend on the needs of the intended users. + +### Outputs + +List the **statistics the model needs to produce** (e.g. mean waiting time, resource utilisation, queue length) and decide how they will be reported. + +Outputs should map directly onto the objectives: if a statistic does not help answer the question, it probably does not need to be there. + +### Content + +Model content has two dimensions (@Robinson2014): + +::: {.blue-table} + +| Dimension | Description | +| - | -- | +| **Scope** | Which parts of the system are included in the model. | +| **Level of detail** | How finely to represent each included component. | + +::: + +Content can be represented using: + +- Component lists +- Process flow diagrams +- Activity cycle diagrams +- Logic flow diagrams + +### Assumptions and simplifications + +Document every place where you depart from the real system, distinguishing two types (@Robinson2014): + +::: {.blue-table} + +| Concept | Definition | +| - | -- | +| **Assumption** | Arise from incomplete knowledge - you do not know exactly how something works, so you use the best available information. | +| **Simplification** | Deliberate design choices - you *could* model something in more detail, but you opt for a simpler representation. | + +:::: + +Both need to be recorded. Assumptions may need revisiting if better data become available; simplifications should be justified against their impact on validity. + +## What makes a good model? + +A good model (@Robinson2014): + +- Produces **sufficiently accurate results** for the purpose at hand (*validity*). +- Is **believed** by the clients and stakeholders (*credibility*). +- Is **feasible to build** within constraints of available data, time, and expertise. +- Has **utility** - it is easy enough to use, sufficiently flexible, adequately visual, and quick to run. + +Overarching all four criteria is the requirement to build the **simplest model possible** to meet the objectives of the simulation study. Simpler models are faster to build and run, easier to understand and explain, and require less data. + +Models can be simplified by removing components or by representing components more simply - for example (@Robinson2014): + +* Replace a detailed section of an operation with a simple time delay. +* Rather than modelling a component explicitly, sample its effect from a statistical distribution (e.g. sample a delivery time directly rather than simulating the delivery process). +* Omit rare events from the base model; optionally explore them as separate scenarios. +* Divide a large model into two or more sub-models that can be run independently. This improves run speed but is only successful when there is no feedback between parts. + +A simplification is **good** if it brings the benefits of faster model development and run speed (feasibility and utility) while maintaining sufficient accuracy (validity) and credibility [@Robinson2014]. + +A practical way to calibrate this is to **prototype**: build the simplest plausible model first, then add scope or detail incrementally and check whether outputs change meaningfully. Stop when they stop changing. + +## References + +::: {#refs} +::: + +

\ No newline at end of file diff --git a/pages/guide/setup/conceptual_resources/references.bib b/pages/guide/setup/conceptual_resources/references.bib new file mode 100644 index 0000000..6ca7142 --- /dev/null +++ b/pages/guide/setup/conceptual_resources/references.bib @@ -0,0 +1,9 @@ +@book{Robinson2014, + author = {Robinson, Stewart}, + title = {Simulation: The Practice of Model Development and Use}, + edition = {3}, + year = {2024}, + publisher = {Bloomsbury Academic}, + address = {London}, + isbn = {9781352011401} +} From 7c1e006648254f31fa41e3c873fc6bcc4615f88f Mon Sep 17 00:00:00 2001 From: amyheather Date: Mon, 1 Jun 2026 10:44:19 +0100 Subject: [PATCH 7/9] feat(documentation): add link to STARS quarto-tutorial (fixes #194) --- pages/guide/style_docs/documentation.qmd | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/pages/guide/style_docs/documentation.qmd b/pages/guide/style_docs/documentation.qmd index 3e787e5..5f006e4 100644 --- a/pages/guide/style_docs/documentation.qmd +++ b/pages/guide/style_docs/documentation.qmd @@ -196,7 +196,9 @@ Creating a small website to accompany your repository can be a really clear and ::: {.python-content} -There are many tools available. We would recommend **Quarto** as a modern, versatile tool with support for multiple programming language - we used it to create this website. +There are many tools available. We would recommend **Quarto** as a modern, versatile tool with support for multiple programming language - we used it to create this website. We have a separate tutorial on how to set up a Quarto website - check it out here: + + Some older solutions include Jupyter Book, Sphinx and MkDocs. From c597875a595983e6993b201582fe24b23618d252 Mon Sep 17 00:00:00 2001 From: amyheather Date: Mon, 1 Jun 2026 12:02:24 +0100 Subject: [PATCH 8/9] feat(conceptual): add section on when to use DES (#200) --- pages/guide/setup/conceptual.qmd | 31 +++++++++++++++++-- .../setup/conceptual_resources/references.bib | 15 +++++++++ 2 files changed, 44 insertions(+), 2 deletions(-) diff --git a/pages/guide/setup/conceptual.qmd b/pages/guide/setup/conceptual.qmd index 7c595a7..daffcb6 100644 --- a/pages/guide/setup/conceptual.qmd +++ b/pages/guide/setup/conceptual.qmd @@ -36,7 +36,34 @@ This description serves as a reference point during model development, for [veri ## Is DES the right approach? -TODO. +Before designing your DES, it is worth asking whether it is the right approach. + +The ISPOR Simulation Modeling Emerging Good Practices Task Force developed the **SIMULATE checklist** to assist in deciding whether simulation methods are appropriate to address specific health system problems (@Marshall2015): + +| SIMULATE | Does your problem require: | +| - | --- | +| **S**ystem | Modeling multiple *events, relationships, and stakeholders* representing health care delivery *processes*? | +| **I**nteractions | Including *nonlinear* or *spatial* relationships among stakeholders and their context that influence *behaviors* and make *outcomes* in the system difficult to anticipate? | +| **M**ultilevel | Modeling a health care delivery problem from strategic, tactical, or operational perspectives? | +| **U**nderstanding | Modeling a complex problem to improve patient-centered care that cannot be solved *analytically*? | +| **L**oops | Modeling *feedback* loops that change the behavior of *future interactions* and the consequences for the delivery system? | +| **A**gents | Modeling multiple stakeholders with *behavioral* properties that *interact* and *change* the performance of the system? | +| **T**ime | *Time-dependent* and *dynamic transitions* in a health care delivery system, either between or within health care *system levels* or in *health status* change? | +| **E**mergence | Considering the *intended and unintended* consequences of health system interventions to address *policy resistance* and achieve target outcomes? | + +
+ +If you answer **yes** to several of these, some form of dynamic simulation is likely justified. The checklist doesn't tell you which method to use. There are three main options, and the simplest way to distinguish them is to consider what the unit of interest is... + +| Method | You are modelling... | +| - | -- | +| **Discrete-event simulation** | Individual entities (e.g., patients, calls, vehicles) moving through a process and competing for resources | +| **System dynamics** | Aggregate quantities and how they influence each other over time through feedback loops | +| **Agent-based simulation** | Individuals whose behaviour adapts based on what others around them are doing | + +For most healthcare operational problems (e.g., scheduling, capacity planning, pathway design), DES is the natural starting point. The others become relevant when feedback loops or adaptive behaviour are central to the question, rather than incidental features of it. + +In practice, the boundaries between these methods are blurry. The goal at the conceptual modelling stage is not to pick the "correct" method with certainty, but to make a **justified and reasonable choice** given the question you are asking. ## Components of a conceptual model @@ -137,4 +164,4 @@ A practical way to calibrate this is to **prototype**: build the simplest plausi ::: {#refs} ::: -

\ No newline at end of file +

diff --git a/pages/guide/setup/conceptual_resources/references.bib b/pages/guide/setup/conceptual_resources/references.bib index 6ca7142..0d87944 100644 --- a/pages/guide/setup/conceptual_resources/references.bib +++ b/pages/guide/setup/conceptual_resources/references.bib @@ -7,3 +7,18 @@ @book{Robinson2014 address = {London}, isbn = {9781352011401} } + +@article{Marshall2015, + title = {Applying {Dynamic} {Simulation} {Modeling} {Methods} in {Health} {Care} {Delivery} {Research}—{The} {SIMULATE} {Checklist}: {Report} of the {ISPOR} {Simulation} {Modeling} {Emerging} {Good} {Practices} {Task} {Force}}, + volume = {18}, + issn = {1098-3015}, + url = {https://www.sciencedirect.com/science/article/pii/S1098301514047640}, + doi = {https://doi.org/10.1016/j.jval.2014.12.001}, + abstract = {Health care delivery systems are inherently complex, consisting of multiple tiers of interdependent subsystems and processes that are adaptive to changes in the environment and behave in a nonlinear fashion. Traditional health technology assessment and modeling methods often neglect the wider health system impacts that can be critical for achieving desired health system goals and are often of limited usefulness when applied to complex health systems. Researchers and health care decision makers can either underestimate or fail to consider the interactions among the people, processes, technology, and facility designs. Health care delivery system interventions need to incorporate the dynamics and complexities of the health care system context in which the intervention is delivered. This report provides an overview of common dynamic simulation modeling methods and examples of health care system interventions in which such methods could be useful. Three dynamic simulation modeling methods are presented to evaluate system interventions for health care delivery: system dynamics, discrete event simulation, and agent-based modeling. In contrast to conventional evaluations, a dynamic systems approach incorporates the complexity of the system and anticipates the upstream and downstream consequences of changes in complex health care delivery systems. This report assists researchers and decision makers in deciding whether these simulation methods are appropriate to address specific health system problems through an eight-point checklist referred to as the SIMULATE (System, Interactions, Multilevel, Understanding, Loops, Agents, Time, Emergence) tool. It is a primer for researchers and decision makers working in health care delivery and implementation sciences who face complex challenges in delivering effective and efficient care that can be addressed with system interventions. On reviewing this report, the readers should be able to identify whether these simulation modeling methods are appropriate to answer the problem they are addressing and to recognize the differences of these methods from other modeling approaches used typically in health technology assessment applications.}, + number = {1}, + journal = {Value in Health}, + author = {Marshall, Deborah A. and Burgos-Liz, Lina and IJzerman, Maarten J. and Osgood, Nathaniel D. and Padula, William V. and Higashi, Mitchell K. and Wong, Peter K. and Pasupathy, Kalyan S. and Crown, William}, + year = {2015}, + keywords = {decision making, dynamic simulation modeling, health care delivery, methods}, + pages = {5--16}, +} From 94be2e957e70e5042b001944fb053a5ac6fdfe7b Mon Sep 17 00:00:00 2001 From: amyheather Date: Mon, 1 Jun 2026 12:07:08 +0100 Subject: [PATCH 9/9] chore(conceptual): update mentions on conclusion and patients to now refer to new page (#200) --- pages/guide/further_info/conclusion.qmd | 9 +-------- pages/guide/model/patients.qmd | 6 +----- 2 files changed, 2 insertions(+), 13 deletions(-) diff --git a/pages/guide/further_info/conclusion.qmd b/pages/guide/further_info/conclusion.qmd index 5d1e848..f408b24 100644 --- a/pages/guide/further_info/conclusion.qmd +++ b/pages/guide/further_info/conclusion.qmd @@ -53,14 +53,7 @@ Remember, these are **examples**, not prescriptions. They're not perfect, and th ### Make your own model -The best way to solidify what you've learned is to apply it. When planning your model, remember that a good simulation starts with **conceptual modelling**. As defined in Robinson (2007): - -> "The conceptual model is a non-software specific description of the simulation model that is to be developed, describing the objectives, inputs, outputs, content, assumptions and simplifications of the model." - -Some good resources on conceptual modelling include: - -* Robinson, Stewart. 2007. "Chapter 5: Conceptual Modelling." In Simulation: The Practice of Model Development and Use, 63–75. John Wiley & Sons. -* Robinson, Stewart. 2007. "Chapter 6: Developing the Conceptual Model." In Simulation: The Practice of Model Development and Use, 77–93. John Wiley & Sons. +The best way to solidify what you've learned is to apply it. When planning your model, remember that a good simulation starts with [conceptual modelling](/pages/guide/setup/conceptual.qmd).
diff --git a/pages/guide/model/patients.qmd b/pages/guide/model/patients.qmd index 66b1a54..9a5a114 100644 --- a/pages/guide/model/patients.qmd +++ b/pages/guide/model/patients.qmd @@ -58,11 +58,7 @@ library(simmer) ## Preparation: conceptual modelling -Before writing any code, it's important that you have defined a conceptual model of the process, as this will guide the design of your simulation. You also need to have defined all the necessary parameters. With these essentials in place, the process of building the simulation can start. - -We will not describe how to design conceptual models in this book, but there are lots of resources available online, such as: - -> Chwif, L., Banks, J., de Moura Filho, J. P., & Santini, B. (2013). A framework for specifying a discrete-event simulation conceptual model. Journal of Simulation, 7(1), 50–60. . +Before writing any code, it's important that you have defined a [conceptual model](/pages/guide/setup/conceptual.qmd) of the process, as this will guide the design of your simulation. You also need to have defined all the necessary parameters. With these essentials in place, the process of building the simulation can start. In this book, we will building a simple model where patients arrive, wait to see a doctor, and then leave.