casino-mcp 0.4.0

The server can now read a calculation and write one, at both ends of a chain. Reading: a DMC
run takes hours, and until this release the only two moments it could be spoken about were
before it started and after it ended. Writing: the input for the next run, and — for the
first run, the one whose directory holds an orbital file and nothing else — the
correlation.data that no CASINO utility writes.

pip install casino-mcp

On PyPI: https://pypi.org/project/casino-mcp/0.4.0/

Added

• casino_results(job_id) (casino-mcp results): the physics of one job as data —
  phases, energies, error bars, variance, per-block numbers, every value carrying the file
  and the line it was read from. result points at the number that is the run's answer.
• A running DMC calculation can be read, and this is the only way to read one. CASINO
  writes the mixed estimators into out once, at the very end; until then the current
  estimate lives in dmc.status, which it rewrites after every statistics block and
  deletes when the run finishes — copying the same text into out at that moment, so
  nothing is lost, but nothing is available either while it matters most. parse_out now
  reads that file when it is there (parse_dmc_status, one parser shared with the out
  section, because write_dmc_status in dmc.f90 writes both), and points result at it.
  A run stopped by casino_stop keeps its dmc.status, so the last estimate it reached
  survives the stop.
• While a DMC run is still equilibrating there is no DMC energy anywhere yet, and result
  now says so instead of answering with the VMC phase — whose energy is the trial wave
  function's, not the calculation's.
• The reblock dump is parsed: the summary rows and the block-length table, with the row
  CASINO marked *** BEST *** — which is where the quoted error bar comes from, and whether
  the rows above it have flattened out is the whole question of whether it means anything.
• casino_prepare(source, dest, runtype, overrides) (casino-mcp prepare): copy a
  calculation into a new directory and write the input the next run needs. runtype fills
  in what that runtype requires and the source does not set — switching vmc to vmc_dmc is
  one keyword in the file and several more that CASINO then demands — while everything the
  source already says survives. Only what a calculation is given is copied: input, the
  orbital file, correlation.data, parameters.casl, the pseudopotentials and config.in;
  never out, the .hist files or config.out.
• input_file, the module under it: ESDF reading, an apply that edits rather than
  regenerates (hand comments, %blocks and expert keywords all survive a rewrite), recipes
  for nine runtypes, and check for the combinations CASINO only rejects at run time — an
  optimisation sample smaller than the DMC population or larger than the number of steps that
  would write it, opt_backflow without backflow, the floor opt_dtvmc puts under
  vmc_equil_nstep, a missing mandatory keyword. Nothing is written unless the result would
  run; a refusal names the problems and creates no directory. What is legal but probably
  unintended comes back as warnings.
• The reblock dump is not an always-present field: vmc.f90 prints it only inside the
  derr > 0.1*err branch, so a VMC phase has one exactly when its reblocking failed, while a
  DMC phase always does. tools/refresh_examples.py skips it in the field comparison for the
  same reason it skips efficiency — whether CASINO prints it is a property of the run, not of
  the output format.
• tests/integration/test_recipes_check_only.py: every recipe put to runqmc --check-only,
  which is the only oracle worth having for this — a recipe is right when CASINO says so, not
  when our own check does. It earned its place immediately: both dmc_*_nstep keywords are
  mandatory for any DMC runtype, including an equilibration-only one, and dtdmc and the
  *_nblocks are not mandatory at all. The tables now come from runqmc's own.
• A blank Jastrow factor and a blank backflow function, for the calculation at the start of
  a chain: one that has an orbital file and nothing else, where use_jastrow : T and
  backflow : T need a correlation.data that does not exist yet. No CASINO utility writes one
  — nothing in utils/ does, and the manual's own instruction is to copy an example and delete
  its parameter lines by hand — so
  casino_prepare(source, dest, jastrow=['u', 'chi', 'f'], backflow=['eta', 'mu', 'phi'])
  writes it, both blocks in the one file, each only if the input turns its keyword on.
• The backflow half is the Jastrow half twice over — a mu set is a chi set, phi is f
  with two more flags — with two differences that are not cosmetic. eta has a cutoff per
  spin-pair channel, and read_cutoff_eta errstops if the first line is missing. And the
  electron-nucleus cusp type of every mu and phi set is not a preference but a fact about
  the atom, 1 for a bare nucleus and 0 behind a pseudopotential — which CASINO reads and
  believes, checking it against nothing, so a wrong value there is not an errstop but a wrong
  wave function. It is derived from the *_pp.data files rather than defaulted.
• The one rule that could not be read off the CASINO source, and was found by putting orders to
  a testrun : T CASINO one at a time: an all-electron phi set with N_eN = 1 has no free
  parameters once the cusp conditions are imposed, whatever N_ee is, while a pseudo-atom set
  at the same order is fine. Refused before the file is written, with the fix named.
• No AE CUTOFFS block is written: it is optional, and init_pbackflow gives every
  all-electron nucleus a set of its own with the length it would have defaulted to.
• correlation_data, the module under it: the geometry out of the orbital file's own header
  (input says how many electrons there are and never how many nuclei), one chi and f set per
  element with every atom labelled, and no parameter value anywhere — CASINO fills alpha,
  beta and gamma with zeros before it reads a line, and says "Not all coefficients supplied"
  when there are none. Which atoms are pseudo-atoms is read out of the *_pp.data files, each
  of which states its own atomic number, so the chi cusp is refused exactly where
  read_chi_term would errstop on it — on a pseudo-atom, and on a Slater-type basis.
• Cutoffs are written as zero, which CASINO reads as use the default and answers with
  default_L_u, default_L_chi, default_L_f. Writing a number instead would be
  reimplementing a choice that depends on the geometry; warnings says which values CASINO will
  take, and jastrow_settings sets one where the default is not wanted.
• casino-mcp prepare --jastrow u,chi,f --backflow eta,mu,phi -j n_u=4, the same for a shell.
• tests/integration/test_blank_correlation.py: every generated file put to a real CASINO with
  testrun : T, which reads the input files, imposes the cusp, no-duplication and no-cusp
  constraints, counts what is left free, checks that they hold, and stops — in a fraction of a
  second. runqmc --check-only is no oracle for this one: it never opens correlation.data.

Changed

• The tool surface is six, where it was four. casino_run, casino_status, casino_stop,
  casino_list_jobs, and now casino_results and casino_prepare.
• A DMC recipe sets popstats : T. It is not CASINO's default, and it is what puts the
  statistical-efficiency section into dmc.status — the difference between a running
  calculation that can be read and one that cannot, for no cost.
• input_file.check_files takes writing, the files the caller is about to write. A blank
  correlation.data is prepared alongside the input it goes with, and refusing the input
  because the file is not there yet would refuse the pair.

Fixed

• casino_run(restart=true) now deletes dmc.status along with the rest of what an earlier
  run left. Only an orderly end deletes it, so a killed DMC run leaves one behind, and a stale
  one next to a fresh out would have been read as the current estimate of a calculation that
  no longer exists.