theochem-vu / pyfrag Goto Github PK

When using molecular symmetry in PyFrag one can compute the orbital interaction energy per symmetry irrep (e.g. for C(S) symmetry the total orbital interaction can be decomposed into components of the A' and A'' irreps (AA and AAA in AMS)). However, this symmetry decomposition is currently not standard printed in the PyFrag output summary textfile (only the total orbital interaction at each point). To get these symmetry decomposed energy terms, you now need to substract this data from all individual fragment analysis files (e.g. with grep).

Would it be possible that the symmetry decomposition of the orbital interaction energy is standard printed in the output textfile?

• make easy to install
• simplify input files check new and old versions

Dear sir
Execuse me , why does the host suggest “could not resolve host :raw.githubusercontent.com” during the process of installing?
Thank you very much!

The scripts pyfragparce.sh and argueparce.sh do not reliably extract the data from within the different blocks (i.e. JOBSUB, ADF, PyFrag) in the input file. The presence in the input file of any text that matches the keywords of those blocks derails the whole process. The issue stems from the grep commands, such as in the file:
https://github.com/sunxb05/PyFrag/blob/5618d5518a8f4a1fc22805feac57b6e6717a08dc/host/standalone/adf_new/pyfragparce.sh#L77-L82

Matching the block keywords without any additional constrain will fail whenever the user uses those strings in their input. For instance, in our system, ADF is loaded with a module called ADF/2019.103. So it is necessary to add the command module load ADF/2019.103 inside the JOBSUB block. Hence, the grep commands will match the ADF in the module name, failing to generate a viable job script.

There are multiple solutions to this problem. We have solved it by replacing those grep commands with sed commands of the form:

sed -n '/^JOBSUB$/,/^JOBSUB END$/{//!p;}' $input > jobsub.txt

• the block keywords are only matched if they are found between the beginning (^) and end of the line ($), so only element in the line
• the code within the blocks is extracted with a single execution instead of 4
• this also avoids needing to define any limit of number of lines

You can find the patch for PyFrag that we developed in https://github.com/lexming/easybuild-easyconfigs/blob/vub-hpc/easybuild/easyconfigs/p/PyFrag/PyFrag-2019_fix_flaky_input_fetch.patch . It might not be complete though.

An annoying issue of PyFrag is that it fails to read less common ADF inputkeys. For example, RemoveFragOrbitals and NMR keys are handled incorrectly.

The way pyfrag currently reads the input file is the following:
It first uses the parses script to split the pyfrag input file into three blocks/text files: jobsub, adfinputfile, and "sub". The last two parts are then parsed into the PyFrag.py . The adfinputfile is made in a "semi plams settings object" which sometimes fails to read keys correctly.

In the PyFrag.py script, the inputfiles are read through the parses and the "semi plams settings object" are further modified to represent a plams settings object.

However, it is possible with plams to just convert an ADF input file directly to a plams settings object (AMSJob.from_inputfile()) which pyfrag uses in its main driver.

Therefore, I propose to execute the following adjustment:

1. Remove the current way of converting an ADFInputfile into a semi-settings object and a settings object consequently, and just read in the inputfile directly. This entails removing a large part of the pyfragparce.sh code (lines 23 - 70; 91; 98 - 106) and waiting with removing the sub.in / EXTRA files
2. Change the current Grep commands that may cause an issue as illustrated by Lexming
3. Change lines 121-143; 157-182 in PyFrag.py to directly read a adf inputfile and convert it into a plams Settings() object via the above described method of using AMSJob

With this, I hope to finally end the frustrating parts of not recognizing ADF input keys.

Often times, when reading orbital data (e.g. energies) we see that MOs can switch ordering. For example, the HOMO at the start of an IRC becomes the HOMO-1 towards the end. This will lead to incorrect data for these orbitals. We should implement an orbital tracking feature that can fix this issue.
The get_alike_orbital method of the pyfmo.Orbitals class allows us to retrieve orbitals that are similar to a given orbital. We can use this feature to fix the above problem statement.

For example:

from pyfmo import Orbitals
from tcutility import pathfunc
import os
import matplotlib.pyplot as plt

# the directory that stores the pyfrag calculations
dirs = pathfunc.get_subdirectories('../../../test/fixtures/pyfrag')
# get the files to the adf.rkf files
files = [os.path.join(d, 'adf.rkf') for d in sorted(dirs, key=lambda d: int(d.split('.')[-1]))]
# and load them
orbs = [Orbitals(f) for f in files]

# plot energy levels of the MOs based on the ordering in the adf.rkf files
plt.plot([orb.mos['HOMO'].energy for orb in orbs], label='HOMO')
plt.plot([orb.mos['HOMO-1'].energy for orb in orbs], label='HOMO-1')
plt.xlabel('IRC Step')
plt.ylabel(r'$\epsilon$ (eV)')
plt.legend()

def MO_track(start_mo, orbs):
    '''
    Function used to track a MO through a series of calculations.
    
    Args:
        start_mo: the MO object that should be tracked through the other calculations.
        orbs: the other orbitals objects that we use to compare to start_mo

    Returns:
        A list of MO objects that are tracked from start_mo
    '''
    mos = [start_mo]
    for orb in orbs[1:]:
        best = orb.get_alike_orbital(mos[-1])
        mos.append(best)
    return mos

# plot the tracked MO energies
plt.figure()
plt.plot([mo.energy for mo in MO_track(orbs[1].mos['HOMO'], orbs[1:-1])], label='HOMO')
plt.plot([mo.energy for mo in MO_track(orbs[1].mos['HOMO-1'], orbs[1:-1])], label='HOMO-1')
plt.xlabel('IRC Step')
plt.ylabel(r'$\epsilon$ (eV)')
plt.legend()
plt.show()

Make a function for pyfrag to combine backwards and forwards paths.

pyfrag combine_paths path1.ams.rkf path2.ams.rkf output.xyz

This should also determine if one of the paths or both have to flipped. For this we can compare RMSDs between first and final structures in each path.

Hello,

I am trying to run the example in PyFrag/host/standalone/orca/, but I get the following error (with previous output):

 ===============================================================================
 *  Pyfrag 2019.02                                                             *
 *  Streamlining your reaction path analysis!                                  *
 *                                                                             *
 *  Author: Willem-Jan van Zeist                                               *
 *
 *                                                                             *
 *  Find the manual at http://www.few.vu.nl/~wolters/pyfrag/                   *
 *  For some examples on how to use PyFrag, see the examples directory.        *
 *                                                                             *
 *  E-mail for PyFrag: LP.Wolters@vu.nl                                        *
 ===============================================================================

 ====================== PyFrag Is Initializing =================================

 ====================== Read print statements ==================================
Traceback (most recent call last):
  File "pyfrag.py", line 508, in <module>
    alist_length = len(atom_list)
NameError: name 'atom_list' is not defined

The only thing I changed was in pyfrag.py, I added the path to my ORCA executable and loaded openmpi in new_adf():

        f.write('module load openmpi')
        f.write('/global/cscratch1/sd/sallec/orca_5_0_2_static/orca ' + orca_input + '>' + orca_output)

Any help regarding this issue is greatly appreciated! 😊

Sarah