fix: use correct distances.dat when starting from existing traj

[jmbuhr]

and fix a warning that warned in exactly the wrong case.

[KRiedmiller]

This was already working, it's implemented in get_existing_files. What broke it was the moving of the plumed input file in #484. Why was that necessary again? The plumed output can be quite big, so I would not copy it just for tidiness, only if there is a risk of us modifying it (which would be probably wrong anyway?).

[jmbuhr]

No, we that's what we talked about. When you run kimmdy over an existing trajectory it needs to interpret the filepath for distances.dat that it get's from a plumed.dat file relative to said trajectory. This is what this change does and it only does so when required (i.e. there is an xtc/trr/tpr input). get_existing_files interprets the filename from the plumed input relative to the plumed input file, which would be wrong for those cases.

[jmbuhr]

No plumed output is moved, only the input file.

[jmbuhr]

One could argue that the other change, copying the plumed input file, is not necessary, though it increases reproducibility, but this one definitely is.

[KRiedmiller]

atm KIMMDY does look for the plumed output relative to the plumed input, not relative to old trajectories.
The latest change moved the input, without moving the output; your change now reroutes the path to the correct output. I don't see the need of moving the input and thereby separating the in- and output.
New output from new runs will be relative to new trajectories, so there should be no risk of overwriting something.

[jmbuhr]

atm KIMMDY does look for the plumed output relative to the plumed input, not relative to old trajectories.

Exactly. And that's wrong, because that's not where gromacs put the output. Say I'm analyzing an existing trajectory with the following kimmdy.yml:

gro: 'old_run/eq.gro'
xtc: 'old_run/md.xtc' 
trr: 'old_run/md.trr'
tpr: 'old_run/md.tpr'
plumed: 'assets/plumed.dat'

[jmbuhr]

What behavior would you expect from the above case?

[KRiedmiller]

KIMMDY looks for this output in different places if starting up and after a md run. When starting it looks (correctly) next to the plumed input file. After an MD, it looks for the output in the run directory of this MD (also correct).

In your example, the distances.dat should be next to the plumed.dat, or on the main branch in the 0_setup dir

[jmbuhr]

distances.dat should be next to the plumed.dat

That's not where gromacs (and gromacs run via kimmdy) puts it. It's relative to gromac's working directory. This is turn can reasonably be assumed to the the parent directory of the trajectory.

[jmbuhr]

In other words: A plumed.dat input file (and it's location) are not sufficient by itself to assume the location of the output file. The only valid location for an output file is in conjunction with the location of the trajectory that was generated using the input file.

[jmbuhr]

cd some/working/dir
gmx mdrun <...> -plumed /some/path/to/plumed.dat

with

... plumed.dat
FILE=distances.dat

produces

some/working/dir/distances.dat

[jmbuhr]

So just like

After an MD, it looks for the output in the run directory of this MD (also correct).

KIMMDY should apply the same logic when starting from an existing trajectory. And while the parent directory of the trajectory is only a heuristic (one could have ran gromacs and specified paths with subdirectories for outputs) it certainly is a better heuristic than looking next to the plumed input file, because those can be re-used and referenced from many simulations.