Right now we do not calculate the path weight correctly for the WF move if we use interface_cap. There we should fix it asap.

After #23 has been merged: test it by making a release: https://github.com/infretis/infretis/releases/new

The code needs to be tested. Creating a mock random generator class could also be useful.

Currently, whenever we restart an airetis simulation that was stopped due to i.e. HPC job time limit, we start the shooting moves anew instead of continuing from where we left off. This should be fixed.

In some cases, path lengths are incorrectly set to 10'000 in infretis_data.txt and sim.log, when they are longer (as in order.txt, traj.txt, energy.txt)

In the new cp2k engine, the executable is sometimes stopped before a line in the energy file is completed, throwing an error regarding the number of lines in the energy file. This can be solved by e.g. also reading energies on the fly using the ReadAndProcessOnTheFly class in cp2k.py. This lets one also use energies as order parameters.

Currently, the cp2kengine can only be used with fixed volume simulations, as no box information is read.

let the setting delete old old paths, and not the ones that are immediately pushed out.

Check that the shooting point coordinates are not modified when shooting and that the order parameter does not change. There are some rounding-off errors when comparing conf.g96 and genvel.g96 that can result in "KOB" for 001 ensembles. This is not checked in higher ensembles.

Currently, if we want to restart a simulation, but run infretis.toml instead of restart.toml, I think we start a new simulation, erasing info from the previous run. Make a checker for this.

If the load path contains frames from a .gro file and we set the gromacs extension to .g96 in infretis.toml, we can run into format problems because gmx trjconv creates .g96 files with the POSITIONRED entry.

Right now it is very unreadable with different element widths etc.

It seems that in engines cp2k, lammps, and turtlemd the velocities are reversed when calculating the orderparameter if system.vel_rev =True. In gromacs this is also done in _propagate_from(), so they seem to be reversed twice.

It seems that the velocity distribution obtained with gromacs using gen-vel is not the boltzmann distribution. Therefore, the distribution of the old shooting point (which is a boltzmann distribution if equilibrated during path sampling) and the generated velocities (using gmx gen-vel) are different, and they do not cancel in the detailed balance relation (flexible length shooting acceptance criteria)?

cause is likely in line 100 of setup.py

   if curr.get("cstep") == curr.get("restarted_from", -1):

How should we generate random numbers? We can't reproduce results for multiple workers if we can't reproduce the length of jobs.

Not sure why, but the .git folder is pretty large (around 180Mb). Does that folder contain trajectory data from the older version?

Dear developers,

Thanks so much for the development.
I'm very interested in applying this method to my work.

I'd like to ask some questions about the path generated by infretis.
I'm using LAMMPS to propagate the trajectory.

As shown in the example, the LAMMPS input file is specified like this:

# variables to be replaced by infretis
variable 	subcycles index infretis_subcycles
variable	timestep index infretis_timestep
variable	nsteps index infretis_nsteps
variable	initconf index infretis_initconf
variable	name index infretis_name
variable 	lammpsdata index infretis_lammpsdata
variable	temperature index infretis_temperature
variable	seed index infretis_seed

units real
atom_style full

dimension 3
boundary p p p

pair_style lj/cut/coul/cut 12.0 12.0
pair_modify mix arithmetic tail yes

read_data ${lammpsdata} # add
read_dump ${initconf} 0 x y z vx vy vz box yes # add

fix 1 all nve
fix 2 all langevin ${temperature} ${temperature} 500.0 ${seed}

thermo ${subcycles}
thermo_style custom step ke pe etotal temp

dump 1 all custom ${subcycles} ${name}.lammpstrj id type x y z vx vy vz # add
dump_modify 1 pbc yes

timestep ${timestep} # add

run ${nsteps} # ad

The input shows the temperature is controlled by Langevin thermostat.
However, controlling the temperature makes the path is not time-reversible.

My questions are as follows.

1. Should it be better if I use NVE instead? Then what happen to the temperature we specified in the toml file?
2. Is there a difference between infretis temperature for path sampling and the temperature in the propagating trajectory?

I'd very appreciate if you can give some comments..

          Add unit test to check if shooting points are correct

Originally posted by @lukasbaldauf in #32 (comment)

this way we don't have to rely on external scripts.. maybe put this in infretis/tools

high_acceptance = false when using wirefencing is not working/ implemented at the moment

Remove reading parameter settings such as temperature in .toml. This avoids setting properties twice (once in the MD program and once in Infretis). It also avoids the need to create checks for these parameters and keeps the .toml file short.

          To do

Originally posted by @lukasbaldauf in #32 (comment)

Lammps engine does not seem to run atm. Something with "w_folder" in md_items in set_mdrun()

https://citation-file-format.github.io/#/what-is-a-citation-cff-file
https://academia.stackexchange.com/questions/14010/how-do-you-cite-a-github-repository

Current implementation of pbc handling in orderparameter.py is quick and dirty

when printing system. pos during running an turtlemd example, i get this print:

[[-0.59088819]]
[[-0.60531565]]
[[-0.96885362]]
[[-0.89629269 0. 0. ]]
[[-0.9860715]]
[[-0.62093541]]
[[-1.00346005]]
[[-0.63712565]]
[[-0.65330699]]
[[-0.89629269 0. 0. ]]
[[-0.67145479]]
[[-0.69098102]]
[[-0.89629269]]
[[-0.80553152 0. 0. ]]
[[-0.90316301]]
[[-0.71127474]]

It would be nice to have some flexible saving options for phase points or whole paths based on some conditions, e.g., save all reactive trajectories, etc. This saves disk space and is useful when one wants to continue a trajectory from the stable states to see if they actually stay there.

When we perpare_shooting_point() in core/tis.py we don't actually use the tis_settings from the input .toml file.