The initial-path section¶

The initial-path section specifies how the initial path for a TIS/RETIS simulation should be generated.

The whole section is optional: an input that leaves it out generates its initial paths with kick, which needs nothing beyond the starting configuration the input already supplies. The chosen initiation is always written to the log, so a run records how its first paths were made. Give the section when you want load or restart instead, or to tune the kick.

Example initial-path section:

[initial-path]
method = "kick"
kick-from = "previous"

The different methods may require different keywords and this is described below for the following supported methods:

Table 38 Supported initiation methods in PyRETIS¶
Method name	Description
kick	For initiating new trajectories from given initial configuration(s).
load	For loading previously generated frames/trajectories
restart	For restarting PyRETIS simulations.

Choosing a method. Use restart whenever a pyretis.restart file is available — it is the most faithful continuation and requires no extra setup. Use load when you have a molecular dynamics trajectory or a previous run whose restart files are unavailable or whose settings need to change beyond what a restart allows; PyRETIS handles the distribution of frames across ensembles automatically. Use kick when no prior trajectory exists and paths must be generated from scratch.

The kick method¶

The kick method generates initial paths for all path ensembles from scratch, requiring only a single starting configuration from the user. It is recommended when no prior trajectory is available.

For each ensemble, the method searches for a crossing of the ensemble’s middle interface \(\lambda_i\) starting from a given phase point \(x\):

Velocities are randomised (e.g. drawn from a Maxwell–Boltzmann distribution).
The equations of motion are integrated one step forward. This gives a new phase point \(y\).
If \(y\) is closer to \(\lambda_i\) than \(x\), the update \(x \leftarrow y\) is accepted and the steps are repeated. Otherwise, the steps are repeated from \(x\) unchanged.

When a crossing is found, two phase points are available: one immediately before the interface and one immediately after. A full path is then generated by integrating forward from the point after the interface and backward from the point before it.

Efficient ensemble population with kick-from = previous. With kick-from = initial every ensemble is kicked from the same user-provided configuration, which may require many iterations for ensembles whose interface lies far from the starting point. With kick-from = previous (recommended for RETIS) only the first ensemble is kicked from the provided configuration. For each subsequent ensemble PyRETIS automatically selects the frame from the just-generated path that lies closest to the next interface and is still to the left of it, then kicks from that frame. This propagates the starting point progressively through interface space so that the kicking algorithm is always seeded close to the target interface, greatly reducing the number of iterations needed per ensemble and requiring no additional input from the user.

Keywords for the kick method¶

For the kick method, the following keywords can be set:

Table 39 Keywords for the kick method.¶
Keyword	Description
method	Selects the kick method.
kick-from	Modify how the initial point for the kick method is picked.
kick-parallel	Kick every ensemble in parallel, one job per worker, instead of sequentially in one process.

Keyword method¶

method = kick

The method keyword selects the kick initialization.

Keyword kick-from¶

kick-from = string

The kick-from keyword specifies what initial point we use for the kick method. This setting is used when several path ensembles are initiated at the same time. It can be set to:

kick-from = initial: In which we will kick from the initial configuration provided. That is, all path ensembles are initiated from the same starting point.
kick-from = previous: In which we kick from the point on the previous path which is closest to the next interface and still left of this interface. The first path ensemble will be initiated using the provided initial configuration for the particles.

Default:: The default value is kick-from = initial.

Keyword kick-parallel¶

kick-parallel = boolean

When kick-parallel = True (and kick-from = initial, the default), every ensemble is kicked in parallel — one job per ensemble, dispatched across the simulation’s worker pool — instead of sequentially in a single process. This only changes how the kick search is run, not the search itself or the resulting paths’ validity.

kick-from = previous always seeds each ensemble from the previous ensemble’s just-kicked path, so it is inherently sequential; kick-parallel is ignored when combined with it.

Engine coverage for the kick search itself (independent of kick-parallel): every engine can now generate a kick-initiated path, including ones without a usable single MD step (CP2K, LAMMPS streaming, ASE, TurtleMD) — they search for the middle-interface crossing by advancing one step of propagate() at a time rather than calling step() directly. kick-parallel itself has been validated for TurtleMD; internal engines (Langevin, Verlet, velocity-Verlet, …) still kick correctly, but only on the sequential route, so kick-parallel = True is not yet recommended for them.

Default:: The default value is kick-parallel = False.

The load method¶

The load method initialises path ensembles from existing trajectory data, avoiding the need to generate paths from scratch via kicking. It is the recommended starting point whenever a prior molecular dynamics trajectory or a previous (P)RETIS run is available.

How ensembles are populated¶

PyRETIS maps each path ensemble to a numbered subfolder inside load_folder (000, 001, 002, …, the names of the ensemble directories of the run, see What a run writes). A pptis run without zero_left or flux numbers only the windows it builds, so it reads its first window, the [0^+] or the [1^+], from 000. The load folder is input and is only read: its files are linked or copied into a directory pyretis-load-* in the directory PyRETIS runs in, the files a load prepares (traj.txt, order.txt and the frames of each ensemble in NNN/accepted/) are written there, and the paths are read from there. The directory is removed when the load ends. A run that stops during the load leaves it in the run directory; remove that pyretis-load-* directory by hand. In pyretis-load-* the .txt files of the load folder are copies, and its other files, the frames, are hard links where the filesystem allows, which take no disk space of their own, and copies elsewhere. A scheduler run that reads initial paths staged flat, in <load_dir>/<path number>, keeps a copy of their files that takes as much disk space as the staged files (see load_dir). Messages about the files of the load name them in the load folder, and pyretis tools clean leaves the load folder a TOML input names in place. For each ensemble in turn the following steps are applied:

Collect frames. Trajectory or configuration files are read from the load folder (see Load folder layouts below for the two supported layouts).
Recompute the order parameter. The order parameter is always recomputed from atomic positions using the order parameter function defined in the simulation input. If an order.txt file is present it is used as-is; if it is absent it is generated. This design means users can change the order parameter definition without regenerating their trajectory files.
Validate and clean the path. Only frames relevant to the ensemble are kept; the rest are discarded (see Path validation and cleaning below).
Fall back to kick if needed. If no valid path can be assembled from the loaded data and load_and_kick = True, PyRETIS automatically kicks from the frame nearest to the ensemble’s middle interface.

Path validation and cleaning¶

After collecting frames PyRETIS checks whether the assembled sequence constitutes a formally valid path for the target ensemble. In the [0^-] of a rate calculation with zero_left, a valid path starts and ends at the first interface, so a loaded path that reaches zero_left is recovered like any other. A recovered path is a seed: its interior frames are the shooting points of the first moves, and the analysis leaves it out. If the sequence is not a valid path, the following recovery steps are attempted in order:

Frames are sorted by order parameter and the validation is repeated.
If sorting alone is insufficient, the sequence is mirrored to produce an L-to-L or R-to-R path — a valid bookkeeping form that satisfies the ensemble definition.
Frames outside the ensemble’s relevant region are discarded, keeping:
- the two frames immediately before and after the first interface, and
- all frames between the interface defining the ensemble and the last interface.
If this second group is empty, the frame with the highest order parameter is retained so that the load_and_kick fallback has a useful seed.

If all three steps fail and load_and_kick = False, PyRETIS raises an error.

Load folder layouts¶

Two layouts are supported.

Layout 1 — unformatted (single shared trajectory). Place one or more trajectory or configuration files directly in load_folder (accepted formats: .xyz, .gro, .trr, .g96, plain-text .txt). PyRETIS will, in the directory where it prepares the load:

distribute the files to each ensemble subfolder,
generate traj.txt (frame index list) automatically,
recompute and write order.txt using the order parameter function.

Only the frames relevant to each ensemble survive path cleaning. Use this layout when you have a single long trajectory and want PyRETIS to handle the per-ensemble distribution automatically with minimal user effort.

Layout 2 — formatted (per-ensemble subfolders). Create subfolders 000, 001, 002, … inside load_folder and place the relevant files for each ensemble there. If traj.txt or order.txt are absent they are regenerated automatically.

For internal engines (positions and velocities stored in PyRETIS format):

File	Notes
`traj.txt`	Required. Full path (positions and velocities).
`order.txt`	Optional. Recomputed from atomic positions if absent.
`energy.txt`	Optional. Energies are silently ignored if absent.

For external engines (GROMACS, CP2K, …):

File / folder	Notes
`traj.txt`	Required. Frame index file referencing MD files.
`accepted/`	Required. Actual MD trajectory files (`.trr`, `.gro`, `.xtc`, `.g96`, `.xyz`, …) referenced in `traj.txt`.
`order.txt`	Optional. Recomputed from atomic positions if absent.
`energy.txt`	Optional. Energies are silently ignored if absent.

Use Layout 2 when different ensembles should start from different trajectories, or when you want to resume from formatted output of a previous (P)RETIS run with changed settings (and no restart file is available).

Note

Order parameters are always recomputed from atomic positions using the order parameter function defined in the simulation input. Placing an order.txt file in the load folder is a performance shortcut, not a requirement. If it is absent or outdated, PyRETIS regenerates it automatically. This allows users to change the order parameter definition without regenerating trajectory files.

Keywords for the load method¶

For the load method, the following keywords can be set:

Table 40 Keywords for the load method.¶
Keyword	Description
method	Selects the load method.
load_and_kick	Fall back to kick initialisation when loaded data cannot form a valid path.
load_folder	Directory containing the trajectory data to load.

Keyword method¶

method = load

The method keyword selects the load initialization.

Keyword load_and_kick¶

load_and_kick = boolean

When load_and_kick = True, the loaded trajectory data is used as a pool of candidate frames rather than as a ready-made path. If the loaded frames cannot be assembled into a valid path for the target ensemble — even after sorting and mirroring — PyRETIS:

Selects the frame from the loaded data that is closest to the ensemble’s middle interface.
Uses this frame as the starting configuration for a standard kick initialisation (two-way shooting).
The resulting kicked path fully replaces the loaded frames; no loaded frames are retained in the final path.

This option is particularly useful when the available trajectory does not cross the relevant interface, or when you want a freshly generated, unbiased initial path seeded from a physically relevant region of phase space.

If load_and_kick = False (the default) and no valid path can be assembled from the loaded data, PyRETIS raises an error.

Default:: The default value is load_and_kick = False.

Keyword load_folder¶

load_folder = string

The load_folder keyword specifies the directory containing trajectory data for load initialisation. See Load folder layouts for the two supported layouts (unformatted single trajectory or formatted per-ensemble subfolders).

Default:: The default value is load_folder = load.

The restart method¶

The restart method is used to continue an existing simulation. It is not a vehicle for changing the simulation itself — for that, use load.

A path-sampling run (tis, retis, explore, pptis, repptis) started with pyretis run keeps its state in the run directory’s output.toml, and a restart continues from there. The settings of the continuation are taken from the new input file; only the running state — the cycle counter, the random-generator state, the occupancy weights and the paths each ensemble holds — comes from output.toml.

output.toml records the input of the run: its sections under the names of the input, with every default the run takes resolved (the zero-swap probability as [retis] swapfreq), and the [current] state. It holds none of the settings the input parse derives (the engine type, the input_files the GROMACS and CP2K checkers find, the exe_path of the run directory, the per-ensemble copies of the sections), and none of the keys and sections that take no effect on the run (the keywords that take no effect): the input of a path-sampling run gives none, as the settings parse refuses each one, and the record leaves out the value the parse gives such a key, such as the [simulation] restart it derives from method = "restart", the [engine0] of a run that runs no [engine0] engine, [simulation] rgen, and the rgen of [tis], [engine] and [system] for a run whose initiation kicks no path in process, a continuation among them. It records [output] screen, the cycles between two progress reports of the scheduler. pyretis run -i output.toml resumes the run with the settings it records, and pyretis analyse -i output.toml analyses it as its input would.

An output.toml written by an earlier PyRETIS can hold keys that took no effect on its run, such as [retis] nullmoves or [output] trajectory-file. The run file still continues and analyses: such a key is left out when the file is read, silently when its value is the one the settings parse gives, and named in a warning otherwise. A value that earlier PyRETIS took as another input key is read under that key: [simulation] zeroswap as [retis] swapfreq, which it won over, and [tis] relative_shoots as [retis] relative_shoots when the file sets none there. pyretis run -i output.toml then writes the record of this version, with the defaults the file does not hold, such as [output] screen.

An output.toml or restart.toml written by an earlier PyRETIS holds the configuration of the scheduler instead, with its [simulation.tis_set] table. A restart continues from it as from the output.toml of this version: the continuation compares its settings with the ones that state file records, reading each where the scheduler of that version read it, and names each setting by its input key. pyretis run -i refuses such a state file, and the message names this route: set method = "restart" in the input of the run and run it in the run directory. pyretis analyse -i reads the settings of such a state file under the names of the input, through the key table, except for the state file of a tis run of one ensemble, whose analysis counts a crossing at [tis] detect when its input gives [tis] ensemble_number, which the state file does not say (see Calculating the rate). The continuation writes output.toml in the form of this version.

kick and load start a new simulation, which writes the output files of its ensemble directories afresh. When one of those directories holds a pathensemble.txt with data rows, the record of cycles a simulation has sampled, pyretis run stops with a ValueError before initiation and leaves the ensemble directories and output.toml as they were. This holds for every value of [output] backup. To add cycles to that simulation, set method = "restart" and raise [simulation] steps to the new total. To start a new simulation, use a new directory, or first clean the run directory with pyretis tools clean or remove the ensemble directories the message names. A scheduler run that starts a new simulation from initial paths already in the run directory, such as a run of a legacy-runner input, stops before its load in the same case, and when a pathensemble.txt holds the header alone, with a FileExistsError that names the ensemble directories. A run of a legacy-runner input stops before it writes anything, with a ValueError, when the run directory holds the state file of a simulation, an output.toml or the legacy restart.toml with a [current] section. pyretis run -i output.toml continues the simulation of an output.toml that records the input of the run; a state file of an earlier PyRETIS is continued by the input converted to the canonical schema (python -m pyretis.tools.convert_legacy_schema) with method = "restart" (see load_dir).

The legacy-runner schema ([runner], [simulation.tis_set], no [simulation] task) is deprecated: PyRETIS 4 converts such an input to its canonical form when it reads it, with a deprecation notice, and PyRETIS 5 will not read it (see the migration guide). The schema has no [initial-path] section: a run of a legacy-runner input starts from the initial paths staged in the run directory, and records its canonical form, every default resolved, in output.toml, as a run of a canonical input does, the pool of ensemble_engines and the engine sections it names among them. pyretis run -i output.toml resumes that run, and the canonical form with method = "restart" continues it. The canonical form takes the initiation of the canonical input, method = "kick", which the record names: a new run of the canonical form generates its initial paths, and stops before it writes a file when the run directory holds initial paths staged flat.

Before continuing, the restart compares the new input with the one that wrote output.toml and refuses, with a ValueError and without touching the saved state, when:

the number of ensembles differs;
any interface position differs;
the ensemble layout differs: the ensembles [simulation] task builds, the [0^-] window that zero_left bounds, a permeability run, for task = "pptis", whether zero_left or flux adds a [0^-] window and zero_ensemble a [0^+] window, and, for task = "pptis" and "repptis", the ensemble windows that [pptis] memory and [repptis] memory set;
any of these settings differs: [tis] maxlength, [tis] allowmaxlength, [tis] enforce_must_cross_m, [system] temperature, the engine temperature, timestep and subcycles, any setting of the orderparameter section (its class, every setting the class reads, the module it is read from and its name), and the GROMACS exchange format gmx_format;
the continuation draws the shooting velocities from another distribution (see below).

The refusal names each setting by its input key, e.g. [simulation] zero_left, and says what it fixes and the value of each run.

maxlength and allowmaxlength enter the acceptance probability of the shooting move, and enforce_must_cross_m decides which paths are members of an ensemble, so changing one of them would continue the chain under a different acceptance rule. The ensemble layout decides which ensembles exist and which paths each of them accepts, so the paths the ensembles hold were accepted in the recorded layout. flux and zero_ensemble change the ensembles of a pptis run only, so the restart compares them for that task. The memory sets the window [lambda_{i-memory}, lambda_i, lambda_{i+memory}] of each ensemble of a pptis or repptis run. The time grid and the order parameter fix what the saved paths mean: a particle index, a dimension or a periodicity that differs defines another reaction coordinate, as a different class does.

The temperature sets the distribution the ensembles sample. [system] temperature is compared for every run, and the internal integrators run at it. The engine temperature is compared for the engines that take one: TurtleMD and ASE run at it; GROMACS, CP2K and LAMMPS draw Maxwell velocities at it, and GROMACS also couples at it, through the ref-t it writes into the mdp. Where no engine temperature is given, these three thermostat at the temperature of their own input files, which the resume leaves to be compared by hand.

The engine timestep and subcycles apply to every engine: each engine stores a frame every subcycles integration steps. The gmx_format applies to the GROMACS engines and to a module-provided engine, whose class is imported only when the run starts. A setting that applies to neither run’s engine is skipped. The internal integrators (Langevin, VelocityVerlet, Verlet) and OpenMM run with subcycles = 1 when the input leaves it out, and the restart compares it as 1; the GROMACS, LAMMPS, CP2K, AMS, ASE and TurtleMD engines require it. A setting that applies and cannot be compared is reported as UNKNOWN in a WARNING, with the reason, and the restart proceeds: the previous run did not record it (an archive written before the setting was persisted, or a value its engine took from its own input), the continuation does not record it, neither run records it, or it applies to the engine of one run only. LAMMPS and OpenMM take the time step from their own input (the LAMMPS input file, the OpenMM integrator); it is recorded, and cross-checked by the engine, when [engine] timestep states it as well, and the warning about a continuation that leaves it out says so. For any other setting that neither run records, the warning asks for the two inputs to be compared by hand.

[tis] zero_momentum and [tis] rescale_energy select the distribution of the shooting velocities, and the paths the ensembles hold were shot with the draws of the run that wrote output.toml. The restart compares those draws with the draws of the continuation: whether every draw has zero total linear momentum, and the energy the drawn velocities are re-scaled to. The continuation draws as its input selects, and so does the run that wrote an output.toml whose [current.provenance] holds velocity_draw_rule = 1. An output.toml without that key records the draws of the engine the run used:

the internal integrators, OpenMM and cp2k_steps keep the linear momentum of every draw;
GROMACS and lammps_steps with velocity_generation = "engine" (gen_vel, and velocity create with the LAMMPS default mom yes) draw with zero total linear momentum;
the streaming cp2k engine draws with zero total linear momentum unless the recorded zero_momentum is false;
AMS draws with zero total linear momentum (GenerateVelocities removes the net linear momentum with RandomVelocitiesMethod Gromacs and Exact, the AMS default; Boltzmann is not checked);
TurtleMD, ASE, the streaming LAMMPS engines, and GROMACS and lammps_steps with velocity_generation = "maxwell" follow the recorded zero_momentum, a missing key being false;
no engine of PyRETIS re-scales the energy of a shooting draw;
for an engine imported from a module, the momentum reset, and a positive recorded rescale_energy, are reported as UNKNOWN in a WARNING and the restart proceeds: a module engine can inherit the modify_velocities of an engine of PyRETIS, whose momentum reset depends on the PyRETIS version that wrote the output.toml.

A continuation that draws differently is refused with a ValueError that names the engine, how each of the two runs draws, and, where one exists, the zero_momentum and rescale_energy that draw as the run being continued did. For example, the output.toml of a GROMACS run with velocity_generation = "engine" without the key continues with zero_momentum = true, the draw of gen_vel, and is refused with zero_momentum = false.

pyretis run -i output.toml resumes with the settings output.toml records. For an output.toml without velocity_draw_rule it compares the draws those settings select with the draws of the engine the run used, as listed above, and refuses a resume that draws differently with a ValueError that names the [tis] zero_momentum and rescale_energy that draw as that run did; setting them in the [tis] section of output.toml lets the resume proceed. Every run records velocity_draw_rule in the output.toml it writes.

Every other setting is taken from the new input file as written, and applies from the resumed cycle on.

[tis] high_accept may change on a restart too, but it selects the acceptance rule of stone skipping, and the paths the ensembles hold at that point were accepted under the other rule. They are therefore left out of the statistics: each is marked with the initialisation code hc, the change is recorded under [current] high_accept_changes in output.toml, and each ensemble counts again from its first path accepted after the restart. A WARNING reports how many paths were set aside.

A restart also records, as [current] ss_weight_from_cycle in output.toml, the first cycle it writes, unless the state already holds one, and with it, under [current] ss_weight_before, the move list and layout of the run being continued and the paths it holds. The analysis reads them to tell which rows carry the stone-skipping weight of the rule each path was sampled with; see the analysis guide.

[simulation] priority_shooting may change on a restart as well. While it is on, the moves submitted to each ensemble are recorded as [current] moves_submitted in output.toml and continue over the restart; a restart that turns it on without that record starts from the attempted moves in each ensemble’s moves.txt. See priority_shooting.

To continue although one of the checked settings changed, or the draws differ, set allow_setting_change = true in the [simulation] section (of the input, or of output.toml for pyretis run -i output.toml). The check is then skipped and a WARNING says that the samples before and after the restart were not drawn under the same settings. It does not lift the ensemble and interface checks: to move, add or remove interfaces, start a new simulation from the saved paths with load.

Keywords for the restart method¶

For the restart method, the following keywords can be set:

Table 41 Keywords for the restart method.¶
Keyword	Description
method	Selects the restart method.
flexible-restart	Read by create_simulation only; `pyretis run` ignores it.

Keyword method¶

method = restart

The method keyword selects the restart initialization. The continuation reads the run directory’s output.toml (or the legacy restart.toml), whichever PyRETIS version wrote it, so run it in the directory of the run it continues.

The restart lists of create_simulation¶

pyretis.setup.create_simulation() reads a pyretis.restart file when restart is set in its simulation settings, takes the settings from that file, and compares the new input against the two lists below while it builds the simulation object. A path-sampling simulation object built this way cannot be run: its cycles belong to the scheduler, so for a path-sampling run the checks in the restart method are the ones that apply.

Implicit parameter overrides¶

For create_simulation, a curated set of parameters can be changed in the new input file. Whenever a value differs from the one stored in the restart file, PyRETIS logs a WARNING and applies the new value; all other settings from the restart file are preserved unchanged.

The parameters that can be overridden in this way are (also exposed in code as pyretis.inout.settings.RESTART_OVERRIDE_KEYWORDS):

simulation: steps, seed, priority_shooting
output: screen, backup, trajectory-file, energy-file, order-file, cross-file, restart-file, pathensemble-file, log_file, log_mode, engine_log
tis: freq, sigma_v, shooting_move, shooting_moves, high_accept, n_jumps, mirror_freq, target_freq, target_indices
retis: swapfreq

These cover parameter tuning (step count, random seed, move frequencies, output paths) that does not alter the statistical validity of the accumulated data. For anything beyond this list — including changing interface positions or the number of interfaces — see Forbidden keywords (topology lock) and Keyword flexible_restart.

Forbidden keywords (topology lock)¶

The following keywords describe the topology of the simulation — what is being sampled and how — and changing them would silently reinterpret the already-saved paths against a different state space. In create_simulation, a restart that finds any disagreement on one of these keys between the new input and the restart file aborts with a ValueError:

simulation: interfaces, task, zero_left, zero_ensemble, flux, permeability
tis: maxlength, allowmaxlength, enforce_must_cross_m

maxlength and allowmaxlength enter the acceptance probability of the shooting move, and enforce_must_cross_m decides which paths count as members of an ensemble. A restart that changed one of them would continue the same chain under a different acceptance rule, so the saved paths and the new ones would not be samples of one distribution.

The full list is exposed in code as pyretis.inout.settings.RESTART_FORBIDDEN_KEYWORDS.

To change any of these you have two correct options:

Start a new simulation from saved trajectories — use load. This is the safest route whenever the new topology means the saved paths must be re-validated against fresh ensemble definitions.
Reuse the saved paths but rewrite the topology — set flexible_restart = True. This bypasses the topology lock and takes the entire new input file as the settings; the user is then responsible for keeping detailed balance. See Keyword flexible_restart.

Practical examples that require one of these two routes (a plain restart will refuse):

changing one or more interface positions,
adding or removing interfaces (and the corresponding ensembles),
changing zero_ensemble, zero_left or flux (which of the [0^-] and [0^+] a run builds follows its task; only pptis reads zero_left, flux and zero_ensemble for that, and zero_left bounds the [0^-] of every task that builds one),
switching task between tis / retis / repptis / explore,
enabling or disabling permeability.

Keyword flexible_restart¶

flexible_restart = boolean

Read only by create_simulation, as described above; a restart through pyretis run ignores it. If True, all settings are taken from the new input file instead of from the restart file. Use this when structural changes to the simulation are needed, for example:

changing interface positions or their number,
adding or removing path ensembles.

In this mode no WARNING is emitted for changed values, and no whitelist is enforced — the new input is used as-is.

Warning

When settings are changed under flexible_restart, the user is responsible for ensuring that the new setup is consistent with detailed balance. If it is not, the pathensemble.txt files should be discarded before continuing.

If some interfaces are removed, the ensemble folders must be relabeled manually. PyRETIS expects a continuous numbering scheme, e.g. 000/, 001/, 002/, …

Default:: The default value is flexible_restart = False.