simjecture 0.1.0__py3-none-any.whl

conjecture_solver/builtin_skills/warpx/manifest.json

@@ -0,0 +1,11 @@
+{
+  "capability_names": [
+    "warpx-cpu-26.07",
+    "warpx-cuda-openpmd-26.07"
+  ],
+  "description": "General guidance for authoring, commissioning, and diagnosing WarpX PICMI simulations",
+  "entrypoint": "SKILL.md",
+  "name": "warpx",
+  "schema_version": "0.1.0",
+  "version": "26.07.26"
+}

conjecture_solver/builtin_skills/warpx/references/2d-xz-commissioning.md

@@ -0,0 +1,145 @@
+# Cartesian 2D XZ commissioning
+
+Read this resource before authoring any two-dimensional Cartesian WarpX run.
+It records instrument semantics and generic validity checks; it does not choose
+an equilibrium, experiment, or conclusion.
+
+## Coordinate contract
+
+- Treat `Cartesian2DGrid` vectors as `[x, z]`: `number_of_cells=[Nx,Nz]`,
+  `lower_bound=[xmin,zmin]`, and `upper_bound=[xmax,zmax]`. The second physical
+  axis is `z`, even though some inherited PICMI signatures and internal WarpX
+  controls call their second array entry `y`.
+- Use physical parser variables `x` and `z` in 2D analytic distributions and
+  fields. Retain three velocity and vector components `x,y,z`; `y` is the
+  ignorable spatial direction, not the second grid coordinate.
+- Never infer the physical location of a feature from an array index alone.
+  Obtain coordinate meshes with `mf.mesh("x")` and `mf.mesh("z")`, inspect
+  centering and ghost cells for each component, and test the extraction on an
+  asymmetric analytic field whose expected axis dependence is known.
+- MultiFab vector directions remain physical component directions `x=0`,
+  `y=1`, `z=2`; they are not array-axis numbers. Use the runtime's `Direction`
+  enum when available.
+- `MultiFabWrapper.to_numpy()` returns a list, one array per local box, and can
+  include guard cells and singleton component dimensions. Do not assume a
+  global contiguous array, silently select box zero, or reuse one component's
+  slice for another staggered component. Record box bounds, meshes, shapes,
+  centering, and the interior slice used by every estimator.
+
+## Preflight the represented object
+
+Derive checks from the active claim and emit them in a small JSON summary.
+Evaluate the analytic initialization independently before stepping, then
+confirm the realized WarpX state after initialization. Include the checks that
+can invalidate the proposed observable, such as:
+
+- every required zero, reversal, extremum, interface, resonance, or source lies
+  strictly inside the intended domain with stated boundary clearance;
+- all required regions exist on both sides of an interior structure;
+- sampled signs and extrema have the intended ordering, rather than merely
+  matching a plotted shape;
+- discrete divergence, charge neutrality, current balance, force or pressure
+  balance, and boundary compatibility meet prospectively chosen tolerances;
+- component orientation and current/drift signs satisfy the governing
+  equations under the chosen coordinate convention;
+- every density is reported in SI units and labeled as electron, ion,
+  per-species, or total density. Convert a supplied density in `cm^-3` to
+  `m^-3` exactly once by multiplying by `1e6`; do not silently reinterpret its
+  population meaning;
+- every parser-function argument is dimensionless where required. Independently
+  check the dimensions of every expression and the physical scale represented
+  by any normalized coordinate or wave number;
+- every field assigned a periodic boundary has matching values and required
+  derivatives on paired faces. A profile with unequal limiting values cannot
+  be made periodic merely by moving its transition away from the seam. Select
+  a compatible topology or nonperiodic boundary and independently check paired
+  faces, interior structures, and applicable integral constraints;
+- the realized species proper velocities reproduce both the sign and magnitude
+  of any required current. Evaluate `curl(B)/mu0` under the declared coordinate
+  and sign convention and compare it with `sum_s(q_s n_s v_s)`. Remember that
+  PICMI analytic momentum expressions are `gamma*v`, not `m*gamma*v`. First
+  derive the physical drift `v` required by the represented state and reject it
+  if `abs(v) >= c`; only then convert it to proper velocity `gamma*v` for a
+  relativistic distribution;
+- pressure or force balance sums the pressure of every represented species.
+  Do not use a one-species pressure coefficient for a pair or electron-ion
+  population without showing why;
+- temperature, energy, velocity, and field conversions are dimensionally
+  checked and preserved as metrics. Do not divide a temperature in kelvin by
+  elementary charge and label the result electron-volts; convert its energy
+  `k_B*T` to eV, or compute the kinetic-energy convention directly in joules
+  before dividing by `e`;
+- the smallest relevant scale spans a prospectively chosen number of cells and
+  particles, with the diagnostic estimator operating above its grid and noise
+  floors; and
+- the realized native input contains the intended geometry, boundary strings,
+  distributions, fields, collisions, diagnostics, timestep, and seed policy.
+
+When collisions, drive, injection, external forcing, or another physical
+mechanism is essential to the claim, register at least one
+`physics_controls` validation check. Verify both the realized native control
+and a quantitative consequence when feasible (for example measured collision
+rate, momentum relaxation, injected flux, or maintained field). A collision
+object in source code, an arbitrary `CoulombLog`, an initial perturbation, or a
+periodic/open boundary label is not by itself evidence that the required
+collisional or driven regime exists.
+
+For threshold rules, write both the metric and a named boolean, for example
+`{"metrics":{"boundary_clearance_cells":8.0},"checks":{"interior":true}}`.
+Register an exact validation check on `checks.interior`. The harness checks the
+JSON value; preserve the code that computed it so the calculation remains
+auditable.
+
+Do not qualify an experiment when a required structure touches a lossy
+boundary, a one-sided profile substitutes for a two-sided object, a width is at
+the grid floor, or the diagnostic selects an unconstrained global noise
+maximum. Close commissioning as unresolved or instrument-limited and redesign.
+
+## Field-source distinctions
+
+- `AnalyticInitialField` initializes grid fields through WarpX external-grid
+  initialization controls. Use it for an initial mesh field and inspect the
+  realized native input. Pass component strings as `Ex_expression`,
+  `Ey_expression`, `Ez_expression`, `Bx_expression`, `By_expression`, and
+  `Bz_expression` only. In the pinned runtime this path invokes initial
+  divergence cleaning; the observed MLMG projection rejects `open` field
+  boundaries, and the PICMI `AnalyticInitialField` constructor does not expose
+  a `do_initial_div_cleaning` keyword (use `warpx_do_initial_div_cleaning` when
+  needed). Do not respond by silently switching to periodic boundaries. Select
+  a boundary-compatible field topology or another supported initialization
+  path, then recommission the changed model under a new prospective evidence
+  contract.
+- `ConstantAppliedField` and `AnalyticAppliedField` configure external fields
+  gathered by particles (`E_ext_particle_*` and `B_ext_particle_*`). Use numeric
+  `Ex`/`Ey`/`Ez`/`Bx`/`By`/`Bz` for constants and `*_expression` strings for
+  analytic applied fields. Their bounds are ignored by this WarpX
+  implementation. They are not automatically part of the self-consistent mesh
+  field and are not equivalent to a boundary inflow or boundary electromotive
+  force.
+- A particle-applied field may directly drive the current being measured. If
+  it is used, define whether the observable requires the self-consistent field,
+  applied field, or their total, and obtain both contributions consistently.
+- Do not describe periodic, reflecting, absorbing, open, or Silver-Mueller
+  boundaries as a physical drive. Demonstrate the actual flux, source, or
+  boundary mechanism that maintains the proposed state.
+- Do not describe an initial seed perturbation as continuing drive. If the
+  hypothesis requires a driven state, commission an actual sustained source or
+  bound the tested claim to freely evolving initial-value dynamics.
+
+## Diagnostic triangulation
+
+For an evidentiary multidimensional run, derive the primary observable by two
+independent paths when feasible. Examples include a local field estimator and
+a time derivative of an integral or flux. Commission their sign, units,
+normalization, coordinates, time alignment, and agreement before interpreting
+the physics. Track a structure continuously from its commissioned location;
+do not redefine its position independently at every output by a global maximum.
+
+## Numerical comparisons
+
+Change one fidelity axis at a time. A resolution comparison is not a convergence
+test if physical parameters, forcing, perturbation, particle count, collision
+strength, estimator, or runtime also change. Measure realized collisionality,
+resistivity, temperature, density, and characteristic times when they enter the
+hypothesis; input labels such as a nominal dimensionless number are not measured
+controls.

conjecture_solver/builtin_skills/warpx/references/cpu-launch-tuning.md

@@ -0,0 +1,54 @@
+# Local CPU launch tuning
+
+Use this resource only to tune execution of an already authored program. It
+must not supply physical parameters, expected outcomes, acceptance thresholds,
+or a benchmark problem. Benchmark the exact frozen program and argument list
+selected within the active campaign.
+
+## Guard MPI first
+
+Query the loaded AMReX library:
+
+```bash
+python -c "import amrex.space2d as a; print(a.Config.have_mpi, a.Config.have_omp)"
+```
+
+Use `mpiexec` only when `have_mpi` is true. The presence of an MPI launcher or
+MPI environment variables is insufficient. With a non-MPI AMReX wheel,
+`mpiexec -n N python run.py` starts independent simulations that can waste
+resources and overwrite the same files.
+
+## Benchmark contract
+
+- Pass the candidate program's complete argument list after `--`. The harness
+  forwards it unchanged and varies only the OpenMP environment.
+- Require at least one nonempty, program-produced completion or validation
+  artifact with `--required-path`. Choose that artifact in the active campaign;
+  the tuning harness does not define scientific success.
+- Use enough work to make initialization a small fraction of elapsed time.
+- Hold program source, arguments, random-seed policy, output cadence, and input
+  data fixed across thread cases.
+- Set math-library threads to one to prevent nested oversubscription.
+- Treat a zero exit status as necessary but not sufficient; inspect the
+  required validation artifacts before adopting a launch configuration.
+
+Run from the repository root with a fresh output directory:
+
+```bash
+.runtime/warpx-cpu/bin/python skills/warpx/scripts/benchmark_cpu_threads.py \
+  --python .runtime/warpx-cpu/bin/python \
+  --program /absolute/path/to/candidate.py \
+  --output artifacts/warpx-cpu-scaling-YYYYMMDD \
+  --threads 1,4,8 --repeats 2 --affinity close --places cores \
+  --required-path relative/program/completion.json \
+  -- <exact candidate-program arguments>
+```
+
+Everything after `--` belongs to the candidate program. The harness writes
+per-run logs, `runs.csv`, and `summary.json`, including the exact argv and
+required-path checks.
+
+There is no portable default thread count, affinity, or AMReX block size.
+Rebenchmark after changing the executable, program, arguments, grid,
+distributions, interactions, diagnostics, host, or runtime build. Prefer the
+fastest case that preserves the candidate program's own validation results.

conjecture_solver/builtin_skills/warpx/references/diagnostics.md

@@ -0,0 +1,139 @@
+# Diagnostics and analysis
+
+WarpX PICMI supplies several output routes:
+
+- `FieldDiagnostic` for selected mesh quantities such as electric and magnetic
+  fields, current, and charge density;
+- `ParticleDiagnostic` for selected particle position, momentum, and weighting
+  records;
+- `ReducedDiagnostic` for compact time series such as field or particle
+  energy; and
+- checkpoint diagnostics for restart rather than scientific interpretation.
+
+For the pinned runtime, select mesh records with the PICMI keyword
+`data_list`, for example `FieldDiagnostic(..., data_list=["E", "B", "J",
+"rho"])`. `field_data` is not accepted by the installed PICMI standard.
+
+Field and particle diagnostics can use openPMD output. The installed WarpX
+runtime includes `openpmd_api`; analysis programs executed with the capability
+can read those records. Ordinary sandbox Python may be used for portable array
+analysis if data are first exported to formats available there.
+
+The exact pinned PICMI keywords are WarpX-prefixed. For file-based HDF5 output
+use, for example:
+
+```python
+picmi.FieldDiagnostic(
+    name="fields",
+    grid=grid,
+    period=diagnostic_period,
+    data_list=["E", "B", "J", "rho"],
+    write_dir="openpmd_diags",
+    warpx_format="openpmd",
+    warpx_openpmd_backend="h5",
+    warpx_openpmd_encoding="f",
+)
+```
+
+The generic keyword `format="openpmd"` is rejected by the installed
+`picmistandard` constructor, while omitting `warpx_format` silently selects the
+default AMReX plotfile format. Inspect the used-inputs record for
+`<name>.format = "openpmd"` and `<name>.openpmd_backend = "h5"`, and verify
+that nonempty `.h5` records can actually be opened before qualifying the
+diagnostic path. Read `examples/openpmd_field_smoke.py` for a bounded wiring
+and readback example.
+
+Iterate records with `for index in series.iterations` and use that `index` as
+the iteration number. The installed `openpmd_api` `Iteration` object has
+`time` and `meshes` but **no** `.iteration` attribute; `int(it.iteration)`
+raises `AttributeError` after a successful WarpX write. See
+`examples/openpmd_field_smoke.py`.
+
+openPMD Python reads are deferred. Materialize each requested array before
+closing its series:
+
+```python
+pending = component.load_chunk()
+series.flush()
+array = np.asarray(pending).copy()
+series.close()
+```
+
+Do not close the series before `flush()`. Converting an unflushed pending read
+can yield uninitialized values without a useful exception.
+
+Choose outputs prospectively from the observable and falsifier. Record units,
+component names, spatial selection, mode projection, time window, filtering,
+normalization, and uncertainty calculation. A visually plausible plot is not a
+defined estimator. When practical, derive the same physical quantity through
+two genuinely different diagnostic paths and test their agreement.
+
+Output completeness, finite values, expected iteration indices, and nonempty
+particle/mesh records are execution-health checks. Conservation, convergence,
+statistical reproducibility, and agreement with an analytic limit are
+scientific commissioning checks. Neither category should be inferred from a
+zero process exit code.
+
+## Reduced energy accounting
+
+Read and preserve the header of every reduced-diagnostic text file before
+selecting columns. In the pinned single-level runtime, `FieldEnergy` writes the
+total grid-field energy in column 2 (`total_lev0(J)`), while `ParticleEnergy`
+writes total particle kinetic energy in column 2 (`total(J)`), followed by
+per-species totals and then mean-energy columns. Do not sum the species totals
+again with `total(J)`, and do not mistake a decline in field energy alone for
+loss of total energy.
+
+For the pinned single-level schema, materialize
+`scripts/reduced_energy_budget.py` and run it with the field and particle files
+instead of reimplementing column selection. The script selects totals by exact
+realized header labels, verifies aligned step/time rows and finite values, and
+fails on an unknown schema. Never replace its selection with slices such as
+`field[:, 2:].sum(...)` or `particle[:, 2:].sum(...)`; those silently add total
+columns to the components they already contain.
+
+For a closed, source-free calculation, first assert that the field and particle
+rows have identical step/time coordinates, then form the budget explicitly:
+
+```python
+field = np.atleast_2d(np.loadtxt("reduced/field_energy.txt"))
+particle = np.atleast_2d(np.loadtxt("reduced/particle_energy.txt"))
+assert np.array_equal(field[:, 0], particle[:, 0])
+assert np.allclose(field[:, 1], particle[:, 1], rtol=0.0, atol=1.0e-30)
+total = field[:, 2] + particle[:, 2]
+relative_drift = (total[-1] - total[0]) / abs(total[0])
+```
+
+Report the field, particle, and combined histories together so energy transfer
+cannot be confused with non-conservation. If the model has absorbing or open
+boundaries, external fields or sources, collisions, radiation, particle
+injection/removal, or another energy channel, add the corresponding boundary
+flux/work/source terms before calling the result a total-energy balance. For
+AMR or a different diagnostic schema, derive the non-overlapping total from the
+realized headers and documented semantics instead of assuming column 2 has the
+same meaning. The bundled script intentionally rejects those schemas until their
+non-overlap semantics are explicit. Preserve the analysis program and its
+component table; a prose claim of conservation is not a commissioning check.
+
+For in-situ access in the pinned runtime, `simulation.fields` exposes the
+MultiFab registry. Fetch vector fields by registry name, physical component
+direction, and level; the physical component direction is distinct from the
+2D array axes. In a 2D build use, for example,
+`from pywarpx.warpx_pybind_2d import Direction` followed by
+`simulation.fields.get("Efield_fp", dir=Direction.y, level=0)`. Registry names
+include `Efield_fp`, `Bfield_fp`, `current_fp`, and `rho_fp`. A returned
+MultiFab provides coordinate meshes with `mesh("x")` and `mesh("z")`; its
+staggering makes component shapes differ. Record centering, box layout, valid
+slices, and guard-cell handling before combining arrays. Read
+`2d-xz-commissioning.md` before using in-situ arrays in any 2D estimator.
+
+Do not delay an experiment to reverse-engineer in-situ particle containers.
+Use `ParticleDiagnostic` plus openPMD for portable particle positions,
+momenta, and weights unless the observable truly requires an in-step callback.
+The legacy `pywarpx.particle_containers.ParticleContainerWrapper` and
+`pywarpx.fields.*Wrapper` helpers are deprecated in this runtime.
+
+When imposed particle fields coexist with self-consistent fields, a diagnostic
+of `Efield_fp` alone need not be the total field gathered by particles. Preserve
+and analyze the external contribution separately, and define the observable's
+field source prospectively.

conjecture_solver/builtin_skills/warpx/references/gpu-launch-tuning.md

@@ -0,0 +1,79 @@
+# Local CUDA launch and tuning
+
+Use this resource only to deploy and tune an already authored program. It must
+not supply physical parameters, expected outcomes, acceptance thresholds, or a
+benchmark problem.
+
+## Prove the whole stack
+
+The repository has a local, non-MPI, 2D CUDA WarpX 26.07 runtime with HDF5
+openPMD diagnostics for the WSL host's NVIDIA RTX 4000 Ada Generation. Inside
+the autonomous sandbox, invoke it through the
+`warpx-cuda-openpmd-26.07` capability.
+
+Do not infer GPU execution from `nvidia-smi` alone. Verify all three layers:
+
+1. `nvidia-smi` reports a device and usable driver.
+2. A real CUDA allocation and kernel complete.
+3. The loaded AMReX binding reports `have_gpu=true` and `gpu_backend=CUDA`.
+
+On this WSL host, `/usr/lib/wsl/lib` must be first in `LD_LIBRARY_PATH`.
+Otherwise an incompatible `libcuda` can be selected even though `nvidia-smi`
+works.
+
+Set `warpx_amrex_the_arena_init_size` explicitly on every GPU
+`picmi.Simulation`. A 256 MiB initial arena is a safe commissioning allocation
+for this host; it is an allocator setting, not a scientific memory cap. Measure
+peak use and retain headroom before increasing the workload.
+
+The reusable host launcher repairs the source-built wheel's nested Python path:
+
+```bash
+skills/warpx/scripts/run_local_cuda.sh -c \
+  "import amrex.space2d as a; print(a.Config.have_gpu, a.Config.gpu_backend)"
+```
+
+Expected output is `True CUDA`. See `local-cuda-deployment.md` to install or
+repair the runtime and `examples/openpmd_field_smoke.py` to verify the producer
+and reader path. These checks establish instrument availability only.
+
+## Benchmark contract
+
+GPU performance depends strongly on the exact program and decomposition. Build
+a campaign-local JSON file whose cases contain complete candidate-program
+argument lists. Change only the launch parameter being tuned; keep all
+scientific inputs and diagnostics fixed.
+
+```json
+{
+  "cases": [
+    {"label": "case-a", "argv": ["--max-grid-size", "64"]},
+    {"label": "case-b", "argv": ["--max-grid-size", "0"]}
+  ]
+}
+```
+
+The example values illustrate argument passthrough only; they are not defaults.
+Include the complete real argv for each case in the campaign-local file.
+
+Run a fresh sweep from the repository root:
+
+```bash
+skills/warpx/scripts/run_local_cuda.sh \
+  skills/warpx/scripts/benchmark_gpu.py \
+  --python .runtime/warpx-cuda-openpmd/bin/python \
+  --program /absolute/path/to/candidate.py \
+  --cases /absolute/path/to/campaign-cases.json \
+  --output artifacts/warpx-gpu-scaling-YYYYMMDD \
+  --repeats 2 \
+  --required-path relative/program/completion.json
+```
+
+The harness refuses a non-CUDA AMReX build, runs every case in an isolated
+directory, checks required nonempty artifacts, and records exact argv,
+end-to-end wall time, optional WarpX evolve time, GPU identity, and summaries.
+It does not decide whether a scientific result is valid.
+
+Do not assume the GPU is faster than the CPU, and do not transfer a launch
+choice between workloads. Rebenchmark after changing the program, arguments,
+diagnostics, runtime, or device.

conjecture_solver/builtin_skills/warpx/references/local-cuda-deployment.md

@@ -0,0 +1,87 @@
+# Deploy the local CUDA instrument
+
+Use this procedure to reproduce the WarpX 26.07 non-MPI, 2D CUDA instrument
+with HDF5 openPMD diagnostics on a Linux or WSL machine.
+
+## Preconditions
+
+- Pin an audited WarpX source checkout. The tested release is 26.07 at commit
+  `312d507407a1bf6f01ae43fb41b5c3a3700d053c`.
+- Install an NVIDIA driver visible to Linux or WSL, `nvidia-smi`, Miniforge or
+  Mambaforge, `mamba`, Python 3.12 development headers, Git, and build tools.
+- On WSL, confirm `/dev/dxg` and `/usr/lib/wsl/lib/libcuda.so` exist.
+- Budget roughly 15 GB of RAM, several GB of disk, network access for source
+  dependencies, and 10--30 minutes for compilation.
+
+Run the bootstrap from the repository root:
+
+```bash
+skills/warpx/scripts/bootstrap_local_cuda.sh \
+  --source /absolute/path/to/pinned/warpx-26.07 --jobs 8
+```
+
+The script detects the GPU compute capability unless `--arch` is supplied. It
+creates project-local environments under `.runtime/`, builds only the 2D CUDA
+Python binding, installs openPMD/HDF5 support, and runs a post-install probe.
+It does not mutate the supplied WarpX source.
+
+## Why the bootstrap is strict
+
+- WarpX 26.07 rejects CUDA 12.0; use CUDA 12.2 or newer. The pinned toolkit is
+  CUDA 12.4.
+- A minimal `cuda-nvcc` package is insufficient. AMReX/WarpX also requires the
+  development packages for CUDA runtime, cuBLAS, cuRAND, cuSPARSE, profiler
+  API, and NVTX.
+- On WSL, put `/usr/lib/wsl/lib` before Ubuntu CUDA stubs in
+  `LD_LIBRARY_PATH`; otherwise a CUDA allocation can report no device even
+  when `nvidia-smi` succeeds.
+- Restrict the build `PATH` and set `HDF5_ROOT`/`CMAKE_PREFIX_PATH` to the
+  project-local non-MPI Linux HDF5 prefix. A Windows Miniconda
+  `hdf5-config.cmake` can otherwise be discovered through WSL and incorrectly
+  require MPI.
+- Set `CPATH=/usr/include` during compilation. With the conda host compiler,
+  `nvcc` otherwise fails to resolve Ubuntu's multiarch Python `pyconfig.h`.
+- Compile for the actual device architecture. This host's RTX 4000 Ada is
+  compute capability 8.9, expressed to CMake as `89`.
+
+## Validate after deployment
+
+Run the reusable launcher and require both CUDA and openPMD HDF5:
+
+```bash
+skills/warpx/scripts/run_local_cuda.sh \
+  skills/warpx/scripts/probe_local_cuda.py --require-openpmd
+```
+
+The probe must report `cuda_warpx`, `openpmd_hdf5_reader`, and
+`openpmd_hdf5_roundtrip` as true. This proves GPU-aware AMReX was loaded and
+that openPMD can create and read an HDF5 series. It does not replace the WarpX
+field-diagnostic smoke test, which proves the producer path.
+
+Then execute `examples/openpmd_field_smoke.py` in a fresh directory and verify
+every boolean in `openpmd_capability_smoke.json`. Finally run a representative
+scientific program and inspect both its realized input and openPMD records.
+
+Set `WARPX_CUDA_RUNTIME` to select an alternate installed runtime while keeping
+the same launcher:
+
+```bash
+WARPX_CUDA_RUNTIME=/absolute/path/to/runtime \
+  skills/warpx/scripts/run_local_cuda.sh program.py
+```
+
+## Failure signatures
+
+| Failure | Meaning and remedy |
+|---|---|
+| WarpX/AMReX requires CUDA 12.2+ | System `nvcc` is too old; use the pinned project-local toolkit. |
+| `cudaErrorNoDevice` while `nvidia-smi` works | Wrong `libcuda` was loaded; put the WSL driver directory first. |
+| Missing `CUDA::curand` or `CUDA::cusparse` | Install their development packages, not runtime libraries alone. |
+| Missing `cuda_profiler_api.h` | Install `cuda-profiler-api`. |
+| Missing `nvToolsExt.h` | Install `cuda-nvtx-dev`. |
+| HDF5 config under `/mnt/c/...` requests MPI | Windows CMake contamination; restrict `PATH` and point HDF5 discovery to the Linux non-MPI prefix. |
+| Missing `x86_64-linux-gnu/python*/pyconfig.h` | Add `/usr/include` to `CPATH`; do not add only the multiarch leaf because that mixes libc sysroots. |
+| C++20 filesystem test fails after adding the multiarch leaf | Remove that leaf from `CPATH` and use `/usr/include`. |
+
+Preserve the build log and package lists with deployment artifacts. Re-run the
+probe after driver, CUDA, Python, WarpX, HDF5, or openPMD changes.

conjecture_solver/builtin_skills/warpx/references/numerical-risks.md

@@ -0,0 +1,32 @@
+# Numerical risks to challenge
+
+The relevant risks depend on the proposed experiment. Consider at least those
+that could change its discriminating observable:
+
+- grid resolution relative to Debye, skin-depth, gyroradius, wavelength,
+  gradient, sheath, or interface scales;
+- timestep relative to plasma, cyclotron, collision, crossing, bounce, growth,
+  and diagnostic timescales;
+- finite-particle noise, loading correlations, random-seed sensitivity, and
+  the noise floor of fitted rates;
+- particle shape, deposition, field gathering, filtering, smoothing, and
+  numerical heating;
+- finite box size, periodic recurrences, boundary reflections, and unavailable
+  wavelengths;
+- velocity or momentum convention errors and incorrectly realized thermal or
+  drift distributions;
+- inconsistent dimensional normalization or species charge/mass;
+- diagnostic aliasing, phase cancellation, post-selected fit windows, and an
+  estimator that changes meaning between cases;
+- a completed run whose conservation, charge balance, or solver residual is
+  unacceptable;
+- a nominal control parameter inferred only from input values when collisions,
+  transport, temperature, density, or effective coefficients evolve;
+- a claimed convergence comparison that changes physical parameters or the
+  estimator together with resolution; and
+- too little evolution in the relevant crossing, bounce, growth, collision, or
+  transport time to establish the regime assumed by the claim.
+
+Use a small number of targeted challenges tied to explicit auxiliary
+subhypotheses. Do not scan every numerical knob without a reason, and do not
+promote a failed numerical attempt as physical evidence.