Simulation and Computational Modeling: How Mathematical Models Become Executable

Last Updated June 12, 2026

Simulation and computational modeling use algorithms, code, numerical procedures, and repeated experiments to study mathematical models that are difficult or impossible to solve analytically. Instead of relying only on closed-form equations, computational models approximate behavior through time steps, simulations, state updates, random sampling, numerical solvers, scenario runs, and reproducible workflows.

A simulation is not merely a visualization or animation. It is an executable representation of a model. It specifies states, rules, parameters, update procedures, random processes, stopping conditions, outputs, and diagnostics. In computational modeling, the code becomes part of the model’s formal structure.

This makes simulation powerful and risky. Computational models can explore nonlinear dynamics, stochastic uncertainty, large systems, interacting agents, spatial processes, optimization problems, and scenarios that cannot be solved by hand. But computational choices can also introduce numerical error, hidden assumptions, unstable outputs, and false precision.

Responsible simulation requires more than running code. It requires model specification, algorithmic transparency, verification, validation, sensitivity analysis, uncertainty communication, version control, reproducible data, and disciplined interpretation. A computational model should be treated as an argument that can be inspected, rerun, challenged, and improved.

Why Simulation and Computational Modeling Matter

Simulation matters because many mathematical models cannot be solved exactly, observed directly, or tested safely in the real world. Complex systems often involve nonlinear dynamics, feedback loops, randomness, heterogeneity, spatial structure, interacting agents, resource constraints, and long time horizons. Simulation gives analysts a way to explore these systems under controlled computational conditions.

Computational modeling matters because modern models are often implemented as code, not only as equations. The computational workflow determines how equations are approximated, how data are processed, how parameters are varied, how uncertainty is propagated, and how results are summarized.

Simulation does not remove the need for theory, evidence, or judgment. It gives those elements an executable form. The quality of the simulation depends on the quality of the model, data, assumptions, algorithms, and review process.

Back to top ↑

What Simulation Is

A simulation is a procedure for generating model behavior over time, across scenarios, across random samples, or across computational experiments. It begins with a formal model and produces output by applying rules repeatedly.

This structure appears in many forms. A differential equation may be simulated by small time steps. An agent-based model may update many individual agents. A probabilistic model may be simulated through random draws. An optimization model may be tested across scenarios. A network model may simulate diffusion, flow, or cascading failure.

The simulation output is conditional. It depends on the model structure, assumptions, parameters, numerical method, random seeds, input data, and implementation. A simulation result should therefore be interpreted as “what this model produces under these assumptions,” not as a direct copy of reality.

Back to top ↑

What Computational Modeling Adds

Computational modeling adds executable structure to mathematical modeling. It turns equations, rules, data, algorithms, and assumptions into reproducible workflows. The computational layer determines how a model is initialized, updated, solved, sampled, stored, tested, and communicated.

This matters because computation is not neutral. Choices about precision, data cleaning, time-step size, solver tolerance, stopping criteria, random seeds, file formats, package versions, and output summaries can change results.

Computational modeling therefore requires model governance. A published simulation should include enough information for others to understand what was run, how it was run, what changed, what was tested, and what remains uncertain.

Back to top ↑

From Mathematical Model to Executable Procedure

Turning a mathematical model into code requires translation. Variables become data structures. Equations become functions. Parameters become configuration values. Assumptions become logic. Outputs become files, plots, tables, logs, or decisions.

This translation can introduce errors. A model can be mathematically sound but incorrectly implemented. A code workflow can run successfully while silently violating the intended model. Verification asks whether the computational implementation matches the mathematical specification.

Good computational modeling makes this translation explicit. The code should be readable enough to audit, modular enough to test, and documented enough to connect each computational object back to the model’s conceptual structure.

Back to top ↑

State, Time, and Update Rules

Many simulations are state-based. The model begins with an initial state, applies an update rule, and produces a sequence of states over time.

The update rule may represent growth, depletion, movement, diffusion, interaction, infection, queueing, failure, adaptation, or decision-making. The time step may represent seconds, days, years, generations, policy cycles, or abstract iterations.

State and time choices should match the phenomenon. A yearly time step may be reasonable for slow demographic change but poor for epidemic spread or emergency response. A synchronous update may be reasonable in one model but misleading in another.

Back to top ↑

Deterministic and Stochastic Simulation

A deterministic simulation produces the same output whenever it is run with the same inputs. A stochastic simulation includes randomness, so repeated runs can produce different outcomes even under the same scenario.

Stochastic simulation requires replication. A single run may be misleading. Modelers should run ensembles and summarize distributions, quantiles, ranges, probability of threshold exceedance, and uncertainty bands.

Randomness should not be treated as noise to hide. It is part of the model. Stochastic variation can reveal fragility, rare outcomes, tipping behavior, or decision risk that a deterministic run would miss.

Back to top ↑

Numerical Approximation and Discretization

Computational models often approximate continuous or analytically difficult structures using discrete numerical methods. Differential equations may be approximated by finite time steps. Spatial fields may be represented by grids. Integrals may be approximated by sums. Random processes may be approximated by sampling.

Approximation introduces numerical error. Smaller time steps may improve accuracy but increase computational cost. Some numerical methods are unstable for certain systems or parameter values. Solver choices should therefore be tested.

Numerical approximation is not merely technical implementation. It can change model conclusions. Responsible computational modeling documents approximation choices and tests whether results are robust to them.

Back to top ↑

Computational Experiments and Scenario Runs

A computational experiment is a structured set of model runs designed to answer a question. It may vary parameters, compare policies, test extreme cases, sample uncertainty, or evaluate alternative model forms.

Without experimental design, simulation can become unstructured exploration. A good computational experiment states what is varied, what is held constant, how many runs are performed, which outputs are measured, and how conclusions will be interpreted.

The experiment design should match the decision or research question. Running many simulations does not automatically produce insight. The runs must be organized around a model question, uncertainty structure, and interpretation plan.

Back to top ↑

Verification, Validation, and Debugging

Verification asks whether the model was implemented correctly. Validation asks whether the model is credible for its intended purpose. Debugging supports verification, but it is not the same as validation.

A simulation can run without crashing and still be wrong. It may contain unit errors, indexing mistakes, boundary-condition mistakes, incorrect parameter values, improper random sampling, or an algorithm that does not match the specification.

Verification and validation should be built into the workflow, not added after results are produced. Logs, tests, assertions, schemas, and review notes make computational modeling more accountable.

Back to top ↑

Sensitivity, Uncertainty, and Ensemble Modeling

Simulation is especially valuable when uncertainty matters. A model can test how outputs change when parameters, assumptions, initial conditions, random seeds, policies, or model structures vary.

Sensitivity analysis asks which inputs most influence outputs. Uncertainty analysis asks how uncertain inputs produce uncertain outputs. Robustness analysis asks whether the same conclusion holds across plausible assumptions.

Computational modeling should make uncertainty visible. A point estimate from a simulation is often less useful than a distribution, range, threshold probability, or scenario comparison.

Back to top ↑

Reproducibility, Versioning, and Workflow Design

A computational model should be reproducible. Someone should be able to identify the model version, input data, configuration, code, random seeds, software environment, and commands used to generate outputs.

Reproducibility is not only a scientific ideal. It is a governance requirement when simulations inform decisions. Without reproducibility, results cannot be audited, challenged, updated, or trusted.

A good workflow separates inputs, code, outputs, documentation, and review artifacts. This separation makes the model easier to run, inspect, test, and maintain.

Back to top ↑

Mathematical Lens: Simulation as Iterated State Transformation

A simulation can be understood as an iterated transformation of model state. Let \(S_t\) be the state at time \(t\), \(\theta\) the parameter vector, \(u_t\) external inputs, and \(\varepsilon_t\) stochastic variation.

Repeated application generates a trajectory:

Output metrics are measurement functions applied to states or trajectories:

For stochastic simulations, repeated runs produce a distribution:

This mathematical lens clarifies why simulation is not separate from modeling. The update function, time step, state representation, sampling procedure, and output metric are all model components.

Back to top ↑

Example: Resource Depletion Simulation

Consider a simple resource depletion model. A resource stock \(R_t\) changes over time as natural regeneration adds to the stock and extraction removes from it.

This model may be simple enough to inspect, but simulation allows analysts to compare extraction scenarios, random shocks, policy thresholds, and long-term depletion risk.

The model’s usefulness depends on more than the equation. It depends on parameter values, time step, extraction assumptions, shock distribution, output metrics, sensitivity analysis, validation evidence, and whether the simulation is appropriate for the decision being considered.

Back to top ↑

Interpretation, Communication, and Decision Support

Simulation outputs should be communicated as conditional evidence. They are not direct observations. They are consequences of a model under specified assumptions.

Good simulation communication explains what was modeled, what was assumed, what varied, what was uncertain, what outputs mean, what the model cannot support, and which conclusions are robust.

Decision support should preserve uncertainty rather than compress it into a single confident answer. Simulation is often most valuable when it reveals tradeoffs, fragility, thresholds, and conditions under which decisions may fail.

Back to top ↑

Ethical Stakes of Computational Modeling

Computational models can influence public policy, infrastructure investment, health planning, environmental regulation, financial risk, emergency response, policing, platform governance, and artificial intelligence systems. Their ethical stakes arise because code can make assumptions appear objective.

Responsible computational modeling treats code as accountable reasoning. It makes assumptions visible, preserves uncertainty, enables review, and resists the temptation to present simulation output as automatic authority.

Back to top ↑

Python Workflow: Simulation Register and Scenario Diagnostics

The Python workflow below implements a dependency-light resource simulation. It records model components, runs multiple extraction scenarios, exports trajectory tables, produces scenario summaries, and writes an audit card.

# simulation_computational_modeling_workflow.py
# Dependency-light workflow for simulation registers and scenario diagnostics.

from __future__ import annotations

from dataclasses import asdict, dataclass
from pathlib import Path
import csv
import json
import random
import statistics


ARTICLE_ROOT = Path(__file__).resolve().parents[1]
OUTPUTS = ARTICLE_ROOT / "outputs"
TABLES = OUTPUTS / "tables"
JSON_DIR = OUTPUTS / "json"


@dataclass(frozen=True)
class SimulationRecord:
    key: str
    component_type: str
    computational_structure: str
    interpretation: str
    review_question: str
    status: str


@dataclass(frozen=True)
class Scenario:
    scenario: str
    initial_stock: float
    growth_rate: float
    carrying_capacity: float
    extraction: float
    shock_probability: float
    shock_fraction: float
    steps: int
    replications: int


def simulation_register() -> list[SimulationRecord]:
    return [
        SimulationRecord(
            key="state_variable",
            component_type="state",
            computational_structure="resource_stock",
            interpretation="The model tracks resource stock over time.",
            review_question="Is the stock definition consistent with the modeled system?",
            status="review",
        ),
        SimulationRecord(
            key="update_rule",
            component_type="update_rule",
            computational_structure="R_next = R + growth - extraction - shock",
            interpretation="Stock changes through regeneration, extraction, and stochastic shocks.",
            review_question="Does the update rule match the conceptual model?",
            status="review",
        ),
        SimulationRecord(
            key="time_step",
            component_type="numerical_method",
            computational_structure="discrete annual step",
            interpretation="The model advances in equal time increments.",
            review_question="Is the time step appropriate for the process?",
            status="review",
        ),
        SimulationRecord(
            key="ensemble_protocol",
            component_type="simulation_protocol",
            computational_structure="multiple random seeds per scenario",
            interpretation="Stochastic variation is summarized across replications.",
            review_question="Are enough replications used to characterize uncertainty?",
            status="active",
        ),
    ]


def scenario_set() -> list[Scenario]:
    return [
        Scenario("baseline", 70.0, 0.18, 100.0, 6.0, 0.05, 0.10, 50, 60),
        Scenario("high_extraction", 70.0, 0.18, 100.0, 10.0, 0.05, 0.10, 50, 60),
        Scenario("adaptive_policy", 70.0, 0.18, 100.0, 6.0, 0.05, 0.10, 50, 60),
        Scenario("shock_stress", 70.0, 0.18, 100.0, 6.0, 0.15, 0.22, 50, 60),
    ]


def extraction_for_step(scenario: Scenario, stock: float) -> float:
    if scenario.scenario == "adaptive_policy" and stock < 40.0:
        return scenario.extraction * 0.35
    return scenario.extraction


def simulate(scenario: Scenario, seed: int) -> list[dict[str, object]]:
    rng = random.Random(seed)
    stock = scenario.initial_stock
    rows: list[dict[str, object]] = []

    for step in range(scenario.steps + 1):
        rows.append({
            "scenario": scenario.scenario,
            "seed": seed,
            "step": step,
            "resource_stock": round(stock, 8),
            "depleted": int(stock <= 5.0),
        })

        if step == scenario.steps:
            break

        growth = scenario.growth_rate * stock * (1.0 - stock / scenario.carrying_capacity)
        extraction = extraction_for_step(scenario, stock)
        shock = stock * scenario.shock_fraction if rng.random() < scenario.shock_probability else 0.0
        stock = max(0.0, stock + growth - extraction - shock)

    return rows


def summarize(rows: list[dict[str, object]]) -> list[dict[str, object]]:
    max_step = max(int(row["step"]) for row in rows)
    grouped: dict[str, list[float]] = {}

    for row in rows:
        if int(row["step"]) == max_step:
            grouped.setdefault(str(row["scenario"]), []).append(float(row["resource_stock"]))

    output = []
    for scenario, values in sorted(grouped.items()):
        output.append({
            "scenario": scenario,
            "replications": len(values),
            "mean_final_stock": round(statistics.mean(values), 8),
            "min_final_stock": round(min(values), 8),
            "max_final_stock": round(max(values), 8),
            "stdev_final_stock": round(statistics.pstdev(values), 8),
            "depletion_probability": round(sum(1 for value in values if value <= 5.0) / len(values), 8),
        })

    return output


def simulation_risk_score(record: SimulationRecord) -> float:
    score = {"active": 1.0, "review": 5.0, "revise": 8.0, "archive": 2.0}.get(
        record.status.lower(),
        4.0,
    )
    text = f"{record.component_type} {record.computational_structure} {record.review_question}".lower()
    for term in ["update", "time", "random", "seed", "ensemble", "uncertainty", "numerical"]:
        if term in text:
            score += 1.0
    return round(score, 3)


def write_csv(path: Path, rows: list[dict[str, object]]) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    if not rows:
        raise ValueError(f"No rows supplied for {path}")
    with path.open("w", newline="", encoding="utf-8") as handle:
        writer = csv.DictWriter(handle, fieldnames=list(rows[0].keys()))
        writer.writeheader()
        writer.writerows(rows)


def write_json(path: Path, payload: object) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    with path.open("w", encoding="utf-8") as handle:
        json.dump(payload, handle, indent=2, sort_keys=True)


def main() -> None:
    records = simulation_register()
    scenarios = scenario_set()
    rows: list[dict[str, object]] = []

    for scenario in scenarios:
        for seed in range(1, scenario.replications + 1):
            rows.extend(simulate(scenario, seed))

    summary_rows = summarize(rows)
    register_rows = [
        {**asdict(record), "simulation_risk_score": simulation_risk_score(record)}
        for record in records
    ]

    write_csv(TABLES / "simulation_trajectories.csv", rows)
    write_csv(TABLES / "simulation_scenario_summary.csv", summary_rows)
    write_csv(TABLES / "simulation_model_register.csv", register_rows)

    write_json(JSON_DIR / "simulation_audit_card.json", {
        "article": "Simulation and Computational Modeling",
        "scenarios": [asdict(scenario) for scenario in scenarios],
        "model_register": register_rows,
        "scenario_summary": summary_rows,
        "audit_checks": [
            "state variables are documented",
            "update rules match the mathematical specification",
            "random seeds and replications are recorded",
            "scenario definitions are explicit",
            "uncertainty and sensitivity are summarized",
        ],
    })

    print("Simulation and computational modeling workflow complete.")
    print(f"Wrote outputs to {OUTPUTS}")


if __name__ == "__main__":
    main()

This workflow treats simulation design as a reviewable artifact. The model register, scenario definitions, random seeds, ensemble outputs, and audit card make the computational model easier to inspect and reproduce.

Back to top ↑

R Workflow: Simulation Review and Ensemble Diagnostics

The R workflow below reviews generated trajectories, classifies scenario risk, and creates a base R plot of mean stock trajectories over time.

# simulation_computational_modeling_review.R
# Base R workflow for simulation review and ensemble diagnostics.

args <- commandArgs(trailingOnly = FALSE)
file_arg <- grep("^--file=", args, value = TRUE)

if (length(file_arg) > 0) {
  script_path <- normalizePath(sub("^--file=", "", file_arg[1]), mustWork = TRUE)
  article_root <- normalizePath(file.path(dirname(script_path), ".."), mustWork = TRUE)
} else {
  article_root <- getwd()
}

tables_dir <- file.path(article_root, "outputs", "tables")
figures_dir <- file.path(article_root, "outputs", "figures")
dir.create(tables_dir, recursive = TRUE, showWarnings = FALSE)
dir.create(figures_dir, recursive = TRUE, showWarnings = FALSE)

trajectory_path <- file.path(tables_dir, "simulation_trajectories.csv")
summary_path <- file.path(tables_dir, "simulation_scenario_summary.csv")
register_path <- file.path(tables_dir, "simulation_model_register.csv")

if (!file.exists(trajectory_path) || !file.exists(summary_path)) {
  stop("Missing simulation outputs. Run the Python workflow first.")
}

trajectories <- read.csv(trajectory_path, stringsAsFactors = FALSE)
summary_data <- read.csv(summary_path, stringsAsFactors = FALSE)

trajectories$step <- as.integer(trajectories$step)
trajectories$resource_stock <- as.numeric(trajectories$resource_stock)

mean_trajectories <- aggregate(
  resource_stock ~ scenario + step,
  data = trajectories,
  FUN = mean
)

write.csv(
  mean_trajectories,
  file.path(tables_dir, "r_mean_simulation_trajectories.csv"),
  row.names = FALSE
)

summary_data$review_class <- ifelse(
  summary_data$depletion_probability > 0.25,
  "high depletion risk",
  ifelse(summary_data$stdev_final_stock > 15, "high variability", "routine review")
)

write.csv(
  summary_data,
  file.path(tables_dir, "r_simulation_scenario_review_summary.csv"),
  row.names = FALSE
)

if (file.exists(register_path)) {
  register <- read.csv(register_path, stringsAsFactors = FALSE)
  register$priority <- ifelse(
    register$simulation_risk_score >= 8,
    "high",
    ifelse(register$simulation_risk_score >= 6, "medium", "low")
  )

  write.csv(
    register,
    file.path(tables_dir, "r_simulation_model_review_queue.csv"),
    row.names = FALSE
  )
}

png(file.path(figures_dir, "r_mean_simulation_trajectories.png"), width = 1100, height = 720)

scenarios <- unique(mean_trajectories$scenario)

if (nrow(mean_trajectories) > 0 && all(is.finite(range(mean_trajectories$step))) && all(is.finite(range(mean_trajectories$resource_stock)))) {
  plot(
    range(mean_trajectories$step),
    range(mean_trajectories$resource_stock),
    type = "n",
    xlab = "Simulation step",
    ylab = "Mean resource stock",
    main = "Simulation Scenario Mean Trajectories"
  )

  for (scenario in scenarios) {
    subset_data <- mean_trajectories[mean_trajectories$scenario == scenario, ]
    lines(subset_data$step, subset_data$resource_stock)
  }

  legend("topright", legend = scenarios, lty = 1, bty = "n")
  grid()
} else {
  plot.new()
  title(main = "Simulation Scenario Mean Trajectories")
  text(0.5, 0.5, "No finite simulation values available.")
}

dev.off()

print(summary_data)

The R layer supports model review by separating trajectories, ensemble summaries, risk classification, and register-based governance. It helps prevent a single simulation path from being mistaken for a robust conclusion.

Back to top ↑

Haskell Workflow: Typed Simulation Model Records

Haskell is useful for this article because simulation model components should not collapse into one informal category. A state variable is not an update rule. A numerical method is not a validation diagnostic. A simulation protocol is not an output claim.

{-# OPTIONS_GHC -Wall #-}

module Main where

data SimulationComponent
  = StateDefinition
  | UpdateRule
  | NumericalMethod
  | ScenarioDefinition
  | StochasticProtocol
  | OutputMetric
  | ValidationDiagnostic
  deriving (Eq, Show)

data ReviewStatus
  = Active
  | RequiresReview
  | RequiresValidation
  | RequiresSensitivityTest
  | Revise
  deriving (Eq, Show)

data SimulationRecord = SimulationRecord
  { key :: String
  , component :: SimulationComponent
  , computationalStructure :: String
  , interpretation :: String
  , reviewFocus :: String
  , status :: ReviewStatus
  } deriving (Eq, Show)

simulationRegister :: [SimulationRecord]
simulationRegister =
  [ SimulationRecord
      "state_variable"
      StateDefinition
      "resource_stock"
      "The model tracks resource stock over time."
      "State definition."
      RequiresReview
  , SimulationRecord
      "update_rule"
      UpdateRule
      "R_next = R + growth - extraction - shock"
      "Stock changes through regeneration, extraction, and stochastic shocks."
      "Equation-code alignment."
      RequiresValidation
  , SimulationRecord
      "time_step"
      NumericalMethod
      "discrete annual step"
      "The model advances in equal time increments."
      "Numerical appropriateness."
      RequiresReview
  , SimulationRecord
      "ensemble_protocol"
      StochasticProtocol
      "multiple random seeds per scenario"
      "Stochastic variation is summarized across replications."
      "Replication adequacy."
      Active
  ]

needsReview :: SimulationRecord -> Bool
needsReview item =
  case status item of
    Active -> False
    _ -> True

main :: IO ()
main = do
  putStrLn "Typed simulation model records:"
  mapM_ print simulationRegister

  putStrLn "\nSimulation records requiring review:"
  mapM_ print (filter needsReview simulationRegister)

This typed layer supports computational model governance by making states, update rules, numerical methods, stochastic protocols, and validation diagnostics explicit before simulation outputs are interpreted.

Back to top ↑

GitHub Repository

The companion repository for this article is designed as a reproducible mathematical-modeling workspace. It contains article-specific code, data, documentation, notebooks, schemas, and generated outputs for simulation model registers, resource-depletion scenarios, ensemble diagnostics, typed Haskell simulation records, validation planning, and reproducible computational workflows.

Back to top ↑

A Practical Method for Simulation Design

Simulation design should begin with the model question, not the code. The workflow should connect purpose, structure, implementation, experiments, outputs, and validation.

This method treats simulation as accountable computational reasoning. It keeps the model connected to the question, the code connected to the model, and the output connected to validation and uncertainty.

Back to top ↑

Common Pitfalls

Simulation and computational modeling can fail in subtle ways. Many failures occur even when code runs successfully and outputs look polished.

• Black-box execution: running a model without documenting equations, rules, assumptions, or algorithms.
• Code-model drift: allowing implementation logic to diverge from the mathematical specification.
• Single-run storytelling: presenting one trajectory as if it represents the full model behavior.
• Seed neglect: failing to record random seeds or run sufficient replications.
• Step-size blindness: ignoring numerical artifacts created by time-step or grid choices.
• Solver overconfidence: trusting solver output without checking convergence, stability, or tolerance.
• False precision: reporting many decimal places when uncertainty is large.
• Scenario bias: testing only scenarios that support a preferred conclusion.
• Weak reproducibility: failing to preserve code, data, configuration, package versions, and outputs.
• Decision overreach: using exploratory simulation as if it were validated prediction.

These pitfalls can be reduced through modular code, tests, input schemas, run logs, version control, sensitivity analysis, ensemble reporting, validation evidence, and careful communication of model limits.

Back to top ↑

Conclusion: Computation Must Remain Accountable

Simulation and computational modeling extend mathematical modeling into executable form. They allow analysts to explore dynamic systems, stochastic processes, nonlinear relationships, spatial structures, interacting agents, numerical approximations, scenarios, uncertainty, and decision alternatives that would otherwise be difficult to study.

Their strength is also their danger. Because computational models can produce detailed outputs, they can appear more authoritative than they are. A simulation result is only as credible as its model structure, assumptions, data, numerical method, implementation, validation, and interpretation.

Responsible simulation treats code as part of the model. It documents how equations become procedures, how inputs become outputs, how uncertainty is propagated, how scenarios are tested, how results are verified, and how conclusions are limited.

Used well, simulation and computational modeling make mathematical reasoning more powerful, transparent, and practical. They support exploration, explanation, forecasting, stress testing, policy comparison, engineering design, scientific inference, and decision support. But computation must remain accountable to evidence, assumptions, uncertainty, and human judgment.

Back to top ↑

Related Articles

• What Is Mathematical Modeling?
• The Modeling Process: From World to Formal Representation
• Differential Equations and Dynamic Models
• Discrete Models and Recurrence Relations
• Probabilistic and Stochastic Models
• Optimization Models and Objective Functions
• Agent-Based Models and Emergent Behavior
• Spatial Models and Geometric Representation
• Numerical Methods for Mathematical Models
• Model Repositories, Data, and Reproducible Research

Back to top ↑

Further Reading

• Winsberg, E. (2010) Science in the Age of Computer Simulation. Chicago: University of Chicago Press.
• Humphreys, P. (2004) Extending Ourselves: Computational Science, Empiricism, and Scientific Method. Oxford: Oxford University Press.
• Law, A.M. (2015) Simulation Modeling and Analysis. 5th edn. New York: McGraw-Hill.
• Banks, J., Carson, J.S., Nelson, B.L. and Nicol, D.M. (2010) Discrete-Event System Simulation. 5th edn. Upper Saddle River, NJ: Prentice Hall.
• Fishman, G.S. (2001) Discrete-Event Simulation: Modeling, Programming, and Analysis. New York: Springer.
• Robert, C.P. and Casella, G. (2004) Monte Carlo Statistical Methods. 2nd edn. New York: Springer.
• Saltelli, A., Chan, K. and Scott, E.M. (eds) (2000) Sensitivity Analysis. Chichester: Wiley.
• Oberkampf, W.L. and Roy, C.J. (2010) Verification and Validation in Scientific Computing. Cambridge: Cambridge University Press.
• Wilson, G. et al. (2014) ‘Best practices for scientific computing’, PLoS Biology, 12(1), e1001745.
• National Academies of Sciences, Engineering, and Medicine (2019) Reproducibility and Replicability in Science. Washington, DC: National Academies Press.

Back to top ↑

References

• Banks, J., Carson, J.S., Nelson, B.L. and Nicol, D.M. (2010) Discrete-Event System Simulation. 5th edn. Upper Saddle River, NJ: Prentice Hall.
• Fishman, G.S. (2001) Discrete-Event Simulation: Modeling, Programming, and Analysis. New York: Springer.
• Humphreys, P. (2004) Extending Ourselves: Computational Science, Empiricism, and Scientific Method. Oxford: Oxford University Press.
• Law, A.M. (2015) Simulation Modeling and Analysis. 5th edn. New York: McGraw-Hill.
• National Academies of Sciences, Engineering, and Medicine (2019) Reproducibility and Replicability in Science. Washington, DC: National Academies Press.
• Oberkampf, W.L. and Roy, C.J. (2010) Verification and Validation in Scientific Computing. Cambridge: Cambridge University Press.
• Robert, C.P. and Casella, G. (2004) Monte Carlo Statistical Methods. 2nd edn. New York: Springer.
• Saltelli, A., Chan, K. and Scott, E.M. (eds) (2000) Sensitivity Analysis. Chichester: Wiley.
• Sargent, R.G. (2013) ‘Verification and validation of simulation models’, Journal of Simulation, 7(1), pp. 12–24.
• Winsberg, E. (2010) Science in the Age of Computer Simulation. Chicago: University of Chicago Press.
• Wilson, G. et al. (2014) ‘Best practices for scientific computing’, PLoS Biology, 12(1), e1001745.
• Zeigler, B.P., Muzy, A. and Kofman, E. (2018) Theory of Modeling and Simulation: Discrete Event and Iterative System Computational Foundations. 3rd edn. London: Academic Press.

Back to top ↑