Replaced post processing "alt" script

[arn-all]

Hi Tom,
Based on the script you added a while ago, I wrote a python script that simplifies post processing of PAFI runs. It also allows plotting the profile directly with PafiResult.plot(), which returns the plt.ax for further modification.

import pafi
import matplotlib.pyplot as plt

p = pafi.PafiResult('raw_ensemble_output_0K_0')
ax = p.plot()
plt.show()

It also allows plotting the activated free energy vs temperature very easily:

import pafi
import matplotlib.pyplot as plt
import glob

fl = glob.glob('raw_ensemble_output_*K_0')
ax = pafi.free_energy_vs_temperature(fl, harmonic_until_T=100)
plt.show()

ax is also returned for further modification or export.

I made the script importable from the main pafi directory (with the pafi/__init__.py file), but it is not necessary. I could also write a setup.py file to make the script installable, i.e importable from anywhere, if you think it is a good idea. I also have some pre-processing scripts that I used to deal with the spline issues we discussed, by remove images or adding new ones. I guess a more general python script for pre-processing a MEP for best result with PAFI could be written based on that and the pafi-path-test you added recently.

I kept the older alt_sample_plot script for now.

Let me know if it is good for you,

Arnaud

[arn-all]

I packaged the python script with setuptools to make it installable. All installation details are in INSTALL.md. I also added a simple command line mode to make it even more convenient.

[tomswinburne]

Hi Arnaud,

This is very nice, apologies I just looked at the code in more detail. Putting everything in classes is for sure better

Given that we will only ever use this with PAFI, I think the code could remain self-contained in a jupyter notebook, or keep it as an external python file as you have done. I don't think it's required to install everything, however, putting things in this format will help if we want to host online with binder etc

[tomswinburne]

If you check out the notebook in examples/standard in the dev-std branch you can see what I've been starting on, I think it is pretty similar to what you have done, I've just tried to be as general as possible. Perhaps you could fork this branch and merge our two approaches?

[tomswinburne]

where are your pre-processing scripts?

[tomswinburne]

Final thing- the new config file is designed to allow for general parameter sweeps - i.e. with

<Parameters>
  <ReactionCoordinate>0.0 1.0 9</ReactionCoordinate>
  <Temperature>0. 800. 5</Temperature> <!-- steps of 200K -->
  <Stress>0 500 6</Stress><!-- steps of 100MPa-->
</Parameters>

You could then have a parameter %Stress% in the input script and it will parse that for you

[arn-all]

Hi Tom,

• For my personal use, I was feeling more comfortable with a package as it's just more convenient to have it versioned in one place (pafi repo) instead of copying it on each of my work folders, and it makes it easier to do PRs. The CLI also was a motivation. I also thought it'd be easier to maintain in case some other features would follow (e.g. preprocessing or full wrapper). But I'm completely fine with keeping the setuptools part on my personal fork if it does not make sense to have it in the main repo. I agree that having generic code in a notebook is awkward, as it makes version control very difficult (among other issues).
• What you did in the notebook is indeed much more general. Though I'm not sure I'm getting the purpose of such a generality. I can't think of a case where we'd have to integrate along another axis than the Reaction Coordinate for example ? I can have a look and try to come up with a mix of what we did.
• I didn't upload any pre-processing scripts yet because they are too complicated and have dependencies. The purpose of my preprocessing is to transform a MEP (lammps positions files + energy barrier saved as csv) into a path that is usable by PAFI. I'd basically avoid large jumps and remove flat segments in 2 steps :

1. Zooming in in the region of the activated state. It is important in my case, as under high stress levels, the activation energy is very small compared to the mechanical work between initial and final state. For this, I crop my MEP after the activated state is passed (with some arbitrary criterion), interpolate a number of new knot images, and perform free end NEB.
2. After that, and before passing the MEP to PAFI, I'd remove any flat segment to avoid spline issues, again based on an arbitrary criterion.

I guess this process would be better performed internally, with direct access to LAMMPS for relaxation after adding knots, and could be much simplified.

• Thanks for the %Stress% tip, I wasn't aware of that. I'm filling config.xml files as templates anyway, but it can definitely be useful.