Anatomy of a Simulation

Table of Contents

• 2. Composition in Practice
• 4. Reusable Config Libraries

PICurv runs are composed from modular inputs. This lets you swap physics, numerics, monitoring, and post-analysis independently.

3. Understand File Roles

A single-run workflow uses five logical inputs:

1. case.yml: physics/domain/grid/BC/run control
2. solver.yml: numerical strategy and solver controls
3. monitor.yml: logging, profiling, output cadence, directories
4. post.yml: post-processing pipeline recipe
5. Launch settings: stage selection + MPI process count (-n)

Cluster/sweep extensions add:

1. cluster.yml: Slurm resource/scheduler contract (run --cluster, sweep --cluster)
2. study.yml: parameter matrix + metrics/plot contract (sweep --study)

You can choose any file names. C binaries do not require fixed YAML names.

2. Composition in Practice

Example solve invocation:

./scripts/pic.flow run --solve -n 16 \
  --case my_cases/channel_case.yml \
  --solver config/solvers/Imp-MG-Standard.yml \
  --monitor config/monitors/Standard_Output.yml

Only numerics/monitoring can be swapped without touching case physics.

6. Inspect Generated Artifacts

pic.flow validates inputs, then generates C-facing artifacts under runs/<run_id>/config/:

• <run_id>.control
• bcs.run or bcs_block*.run
• whitelist.run
• profile.run
• post.run

These are the concrete contract consumed by C-side parsers in setup.c, io.c, and BC/profile loaders.

4. Reusable Config Libraries

Project-level shared profiles live in:

config/
|- solvers/
|- monitors/
|- postprocessors/
|- schedulers/
`- studies/

Use these as reusable baselines and keep case-specific physics in study-local files.

9. Next Steps

Proceed to Configuration Reference: Case YAML.

For full contract and ingestion mapping, also see:

• Configuration Contract (YAML -> Generated Artifacts -> Runtime)
• Developer Ingestion Map
• Configuration Extension Playbook
• Methods and Models Overview