Path types and rejection reasons¶

During a PyRETIS simulation, each Monte Carlo cycle generates (or loads) a path and records two short codes in the output:

a move type (how the path was generated), and
a status code (whether the path was accepted, and if not, why).

Both codes appear in the run log pyretis.log and in the per-ensemble output files: the Mc and Acc columns of pathensemble.txt, the Move and Status columns of moves.txt, and the header of each block of order.txt and energy.txt, whose move starts with the move code, e.g.:

# Cycle: 29, status: ACC, move: ('sh', -0.796865017, 284, 382)

The tables below list every code that PyRETIS can produce.

Move types¶

The move type describes how the new path was generated. For an explanation of what each move actually does – the basic moves, the sub-trajectory moves and infinite swapping – see Monte Carlo moves.

Code	Short name	Description
`sh`	Shoot	Path generated with a shooting move: a phase-space point is selected on the current path, momenta are perturbed, and new forward and backward trajectories are integrated. A path made by biased shooting is written `sh` as well; `moves.txt` records its attempt as `bias`.
`ss`	Stone skipping	Path generated by the Stone Skipping algorithm, a multi-step variant of shooting that reuses short sub-paths.
`wt`	Web Throwing	Path generated by the Web Throwing move.
`wf`	Wire Fencing	Path generated by the Wire Fencing move.
`mw`	Multiresolution Wire Fencing	Path generated by Multiresolution Wire Fencing (`mwf`). The `Mc` column holds two characters, so `pathensemble.txt` writes the move as `mw`; `moves.txt` records it as `mwf`. The move shoots its segments from many points, so its `O-shoot` holds a marker value, not a shooting point.
`ts`	Target swap	Path generated by a target swap move.
`tr`	Time-reversal	Path generated by time-reversal: the current accepted path is reversed in time to produce the trial path.
`s+`	Swap from +	Path produced by the zero swap between `[0^-]` and `[0^+]` (the RETIS one, or the QuanTIS one when `quantis = true`), recorded in `[0^-]`: the incoming path came from the `+` (higher-index) ensemble.
`s-`	Swap from −	The same zero swap, recorded in `[0^+]`: the incoming path came from the `-` (lower-index) ensemble.
`p+`	PPTIS swap from +	Path produced by the PPTIS/REPPTIS swap between adjacent ensembles, recorded in the lower-index partner: the incoming path came from the `+` (higher-index) ensemble.
`p-`	PPTIS swap from −	The same PPTIS/REPPTIS swap, recorded in the higher-index partner: the incoming path came from the `-` (lower-index) ensemble.
`mr`	Mirror	Path generated by a mirror move.
`hc`	Held across rule change	A path an ensemble held at a restart that changed `[tis] high_accept`. It was accepted under the other acceptance rule, so, like an initialisation path, it is left out of the statistics until it is replaced.
`ki`	Kick initiation	Path generated by integrating the equations of motion after kicking (re-drawing) the initial momenta; used during path initiation.
`is`	Initial shoot	Path generated by a shooting move applied during the initial Stone Skipping preparation step, before the actual SS move.
`ld`	Load (unformatted)	Path loaded from unformatted (binary) external file(s). A path-sampling run writes the rows of its initial paths in `pathensemble.txt` with this code, also of one loaded from formatted files or made by a kick, and leaves these rows out of the production statistics.
`rf`	Load (formatted)	Path loaded from formatted (text) external file(s), as the log of the load names it; `pathensemble.txt` records it as `ld`.
`re`	Formatted load (PyRETIS 3)	Written by PyRETIS 3 for a path loaded from formatted (text) external file(s). PyRETIS 4 writes no `re`: a restart keeps the code of every path it continues. PyRETIS 3’s analysis left these rows out of the statistics until the ensemble accepted a shooting move; `pyretis analyse` counts them, so re-analysing a PyRETIS 3 run that started from a formatted load includes the loaded paths from the first cycle on.
`00`	Null move	Path produced by a null move: the current path is kept without any modification; a PyRETIS 4 run attempts none, and the code appears in the output of a PyRETIS 3 run with `nullmoves = True`.

Path status codes¶

The status code explains why the trial path was accepted or, if rejected, what condition was violated.

Acceptance

Code	Meaning
`ACC`	The trial path was accepted and becomes the new current path.

Trajectory-length rejections

These rejections occur when the generated trajectory is too long or too short to satisfy the detailed-balance or max-length conditions.

Code	Meaning
`BTL`	Backward trajectory too long — the backward segment exceeded the limit imposed by the detailed-balance condition.
`BTX`	Backward trajectory too long — the backward segment exceeded the hard `maxlength` cut-off.
`BTS`	Backward trajectory too short — the backward segment ended before reaching a required interface.
`FTL`	Forward trajectory too long — the forward segment exceeded the limit imposed by the detailed-balance condition.
`FTX`	Forward trajectory too long — the forward segment exceeded the hard `maxlength` cut-off.
`FTS`	Forward trajectory too short — the forward segment ended before reaching a required interface.
`XSS`	Stone Skipping sub-path too long — an internal sub-path within the Stone Skipping algorithm exceeded the allowed length.

Interface / crossing rejections

Code	Meaning
`NCR`	No crossing with the middle interface — the trial path did not cross the required central interface of the ensemble.
`BWI`	Backward trajectory ends at wrong interface — the backward segment terminated at an interface other than the one required.
`EWI`	Initial path ends at wrong interface — used during path loading/initiation: the loaded path ends at an interface that is not compatible with the ensemble.
`SWI`	Initial path starts at wrong interface — used during path loading/initiation: the loaded path starts at an interface that is not compatible with the ensemble.
`0-L`	{0−} path ends at left interface — for paths in the `{0-}` ensemble the path ended at the left (A-state) interface instead of crossing to the right.
`NSS`	No one-step crossing in Stone Skipping — the Stone Skipping algorithm could not find a valid one-step interface crossing.

Momentum / energy rejections

Code	Meaning
`MCR`	Momenta change rejection — the new momenta drawn during the shooting move were rejected (e.g. by the Metropolis criterion on the kinetic energy).
`KOB`	Shooting point outside of boundaries — the shooting point lies below the left interface or above the right interface of the ensemble. Both propagation legs start from the shooting point and would stop on it, so the trial is rejected before any propagation. The point tested is the one after the momentum kick, which moves a velocity-dependent order parameter, or the crossing frame that the initial shooting move (`is`) of Stone Skipping shoots from, which in the `{0+}` ensemble lies below the left interface for one frame of every crossing.

Code

Meaning

MCR

Momenta change rejection — the new momenta drawn during the shooting move were rejected (e.g. by the Metropolis criterion on the kinetic energy).

KOB

Shooting point outside of boundaries — the shooting point lies below the left interface or above the right interface of the ensemble. Both propagation legs start from the shooting point and would stop on it, so the trial is rejected before any propagation. The point tested is the one after the momentum kick, which moves a velocity-dependent order parameter, or the crossing frame that the initial shooting move (is) of Stone Skipping shoots from, which in the {0+} ensemble lies below the left interface for one frame of every crossing.

Detailed-balance / super-detailed-balance rejections

These rejections enforce the (super) detailed-balance conditions for advanced moves.

Code	Meaning
`HAS`	High-acceptance swap rejection — the high-acceptance criterion for Stone Skipping / Wire Fencing detailed balance was not satisfied.
`SSA`	Stone Skipping super-detailed-balance rejection — the Stone Skipping move was rejected by the super-detailed-balance acceptance test.
`WFA`	Wire Fencing super-detailed-balance rejection — the Wire Fencing move was rejected by the super-detailed-balance acceptance test.
`WTA`	Web Throwing super-detailed-balance rejection — the Web Throwing move was rejected by the super-detailed-balance acceptance test.
`SAR`	Selection-bias acceptance rejection — a valid biased shooting trial path was rejected by the selection-bias Metropolis test \(\min(1, W_\mathrm{old}/W_\mathrm{new})\).

Target-swap rejections

Code	Meaning
`TSS`	Target swap selection rejection — the target-swap move was rejected at the selection step (no suitable target ensemble was found).
`TSA`	Target swap detailed-balance rejection — the target-swap trial was rejected by the detailed-balance acceptance criterion.

QuanTIS zero-swap rejections

These codes reject the zero swap of a run with [tis] quantis = true.

Code	Meaning
`QNE`	No energies — a shooting point of the `[0^-]` or `[0^+]` path carries no energies, so the energy acceptance rule cannot be evaluated (not raised with `[tis] accept_all = true`).
`QLL`	Shooting point not left of the zero interface — a shooting point of the swap does not lie left of the interface \(\lambda_0\).
`QS0`	No one-step crossing for the new `[0^-]` path — the one-step propagation of the new `[0^-]` path does not end right of \(\lambda_0\).
`QS1`	No one-step crossing for the new `[0^+]` path — the one-step propagation of the new `[0^+]` path does not end right of \(\lambda_0\).
`QEA`	Energy acceptance rejection — the swap was rejected by the energy acceptance rule.
`QR*`	The `[0^-]` phase point moved to the right side of \(\lambda_0\) before the backward propagation.
`QLR`	The `[0^+]` phase point moved to the left side of \(\lambda_0\) before the forward propagation.
`0+R`	{0+} path starts at the right interface — the new `[0^+]` path does not start left of \(\lambda_0\).

REPPTIS-specific rejections

Code	Meaning
`SWD`	REPPTIS swap — wrong propagation direction — in a REPPTIS swap move the trial trajectory propagated in the wrong direction relative to the interface.
`SWH`	REPPTIS swap — first-half extension rejected — the first half of the REPPTIS swap extension was rejected.

Other

Code	Meaning
`NSG`	No suitable segments — the path contains no segments that can be used as shooting points.
`EXP`	Exploration path — the path was generated during an exploration phase and is not counted as a regular MC step.