P3 work

.gitignore

@@ -42,3 +42,6 @@ qr_acr*dat
 # CM1 processes the .F files into .f90 during the build process so we should ignore
 # these too
 *.f90
+
+# Claude Code machine-specific settings (netCDF/HDF5 paths differ per machine)
+.claude/settings.local.json

CLAUDE.md

@@ -0,0 +1,90 @@
+# CM1 r21.0 — P3 microphysics working copy
+
+CM1 (Bryan cloud model) with heavy local modifications to the P3 (Predicted
+Particle Properties) microphysics scheme. Working branch `P3_work`; main branch
+is `master`. Several sibling worktrees of the same repo exist under
+`~/Projects/cm1r21.0*` — check `git worktree list` before assuming a path.
+
+## Building
+
+```bash
+cd src && make
+```
+
+Links the executable to `run/cm1.exe`.
+
+- `src/Makefile` is the **active** build config — a copy of one of the
+  `Makefile_<machine>` variants with the hardware section uncommented. Current
+  settings: `mpif90` (gfortran), `-ffree-form -ffree-line-length-none -O2
+  -finline-functions`, `-DMPI`. Variants in the tree: `Makefile_laptop_mpi`,
+  `Makefile_laptop_single`, `Makefile_bell`, `Makefile_derecho`.
+- The laptop Makefiles need `NETCDFC_DIR`, `NETCDF4_DIR` and `HDF5_DIR` in the
+  environment. These are Homebrew prefixes on this machine and are supplied to
+  Claude Code via `.claude/settings.local.json` (gitignored, machine-specific).
+  Without them the netCDF-using files fail with `Cannot open module file
+  'netcdf.mod'`. `Makefile_bell` uses different variable names
+  (`NETCDF_FORTRAN_HOME` etc.); `Makefile_derecho` uses `NETCDF`.
+- Debug builds (used for FP-trap hunts) swap `OPTS` for
+  `-O0 -g -ffpe-trap=invalid -fcheck=bounds` and require a full rebuild.
+
+### Generated files — never edit these
+
+- `src/*.f90` — cpp output from the corresponding `.F`. Edit only the `.F`.
+- `run/onefile.F` — a concatenation of all sources, regenerated by every `make`.
+  Gitignored. Grep hits here are duplicates of `src/`; ignore them.
+
+## P3 configurations (`ptype` in `&param2`)
+
+All are 2-moment cloud water and rain. Ice-category count, moment count and
+liquid-fraction prediction are baked into the ptype:
+
+| ptype | ice cats | ice moments | liqFrac |
+|-------|----------|-------------|---------|
+| 50–53 | 1–2      | 1–3 mom     | no      |
+| 54, 56, 57 | 2, 3, 4 | 3-mom  | no      |
+| 60–63 | 1, 2, 3, 4 | 3-mom     | yes     |
+| 64, 65 | 5, 6    | 3-mom       | no      |
+| 66, 67 | 5, 6    | 3-mom       | yes     |
+
+Adding or changing a P3 configuration touches, at minimum: `src/param.F`
+(ptype range tests, `param_mp` name, the `p3_init` dispatch, and the
+`numq`/`qname`/`qunit`/`qmag`/`cloudvar`/`np3a`/`np3o` block), `src/mp_driver.F`
+(the per-ptype `p3a` pack/unpack and `mp_p3_wrapper_wrf` call),
+`src/writeout.F` (per-category diagnostic output), and
+`src/radiation_driver.F` (effective-radius ptype list).
+
+Scheme options live in the `&p3_params` namelist group (declared and broadcast
+in `param.F`, applied in `p3_init`). With `p3_cat_init_new = .true.` the
+destination category for each of the six ice-initiation mechanisms is set by
+`p3_catdest_<mechanism>_n<N>`, where `N` is the number of ice categories in the
+active configuration — so ptype 57 reads the `_n4` values, 64/66 the `_n5`
+values, and 65/67 the `_n6` values.
+
+## Running
+
+`run/` needs the P3 lookup tables (`p3_lookupTable_1.dat-v6.7-{2,3}momI`,
+`p3_lookupTable_2.dat-v6.1`) alongside `cm1.exe` and `namelist.input`.
+`run/namelist.input` is a default/reference copy — it does **not** track the
+configuration of any particular production run.
+
+Note that older executables will refuse a namelist containing `&p3_params`
+keys they were not compiled with (`Cannot match namelist object name ...`), so
+A/B runs against an older binary need the newer keys stripped.
+
+## Category-swap / bit-reproducibility investigation
+
+`NOTES.md` and `p3_category_swap_audit.md` are the running record of a long
+investigation into why permuting P3 ice-category destination assignments broke
+bit-identity. Read `NOTES.md` before touching category reductions or the
+tendency-application code — several fixes there are load-bearing. In-tree
+tooling kept from that work:
+
+- `p3_chksum` / `p3_chkpts` in `&p3_params` — per-timestep field checksums and
+  per-point raw dumps, written PRE and POST each `p3_main` call.
+- `compare_p3_chksum.py` and `decode_point.sh` in the repo root.
+- `qsum_invariant` in `&p3_params` — permutation-invariant host-side moisture
+  sums; needed for swap/invariance runs, default off.
+
+The general fix pattern for a category-order dependence is: replace a
+fixed-slot-order category sum with a double-precision accumulate-then-round, or
+a value-sorted `sortsumq` on the host side.