please help me

I got the error "Fragment xx, xx electron, charge 0, multiplicity 1" from GAMESS using the inp file generated by FragIt. To solve this problem, I modified the function _fixAtomsAndCharges in fragmentation.py as following:

def _fixAtomsAndCharges(self):
    ....
    # self.formalCharges = [0.0 for i in range(self.mol.NumAtoms())]
    # if charge_model.ComputeCharges(self.mol):
        # self.formalCharges = list(charge_model.GetPartialCharges())
        # else:
               # print("Info: FragIt [FRAGMENTATION] fragment charges are not available.")
    self.formalCharges = []
    for atom_id in range(self.mol.NumAtoms()):
        self.formalCharges.append(self.mol.GetAtomById(atom_id).GetFormalCharge())
    ....

This solved the charge problem, I'd like to know if this modification is correct. Thanks!

It would be very nice if the output writers were able to utilize the atom names already found in PDB files.

We should make an effort in using SMARTS patterns to guesstimate the fragment charges and only (ONLY!) use the charge model if there are things we are uncertain about.

In the long run, we should probably also dump some information to a json-file (which can be read back in) regarding charges and other things. Now, it will become incomprehensible for even the keenest of users, but it should and could be a nice option.

{
  "title": "This is a test",
  "charge": 0,
  "fragments": 4,
  "fragment_charges": [ 0, 0, 0, 0],
  "fragment_indices": [
    [ 1, 2, 3],
    [ 4, 5, 6],
    [ 7, 8, 9],
    [10,11,12]
  ],
  "fragment_names": [
    "WATER",
    "WATER",
    "WATER",
    "WATER"
  ]
}

When openbabel can't be found by FragIt, the error message is that FragIt cannot find itself. Thus, it hides the true problem.

The problem is that in the fragit executable everything is masked with a

try:
    ...
except ImportError:

but not being able to import openbabel raises an import error. It should fail more gracely. Perhaps it's time to make a FragItException class.

Running FragIt without openbabel produces the error:

ERROR: Could not start FragIt.
Please add the custom installation path to the PYTHONPATH environment variable.

which is misleading.

FragIt was installed on Fedora 20 by running "./setup.py install --user" which installs in user .local directory.

Currently we rely on OpenBabel to parse the SMARTS and give us the atoms of the corresponding fragments. We should also make an effort to support other APIs such as RDKit.

There is some code available in src/openbabelwrapper.py which could be used as a starting point.

I suppose something like which is easily testable depending only on the classes themselves.

class FragmentationBase(object):
    """ A virtual class with all the support the fragmentation class needs except smarts handling """
    pass

class OBFragmentation(FragmentationBase):
    """ Make openbabel specific implementation of Fragmentation class """
    pass

class RDKitFragmentation(FragmentationBase):
    """ Make RDKit specific implementation of Fragmentation class """
    pass

some logic would then be built-in depending on what packages are available. Some things that the classes should provide:

• Based on a smarts fragmentation pattern, yield list of fragments.
• Calculate the charge of fragments in a somewhat consistent fashion
  • Perhaps we should start making SMARTS patterns for charges too. See ???

Initially we will ignore things like fragment grouping and so on.

It looks like protonated histidine charges are calculated to be zero (they should be +1) by the underlying Open Babel framework.

I propose as a temporary work-around to match the protonated histidine explicitly by SMARTS and change the charge accordingly.

Hello,

Is there a web site to use FragIt on-line?

Regards,

Camps

Hello,
I have encountered some issues when fragmenting organic crystals. If my molecule has hetero-atoms with Z=9,35,17 it is automatically being assigned to a different fragment. Is there a way to counter this issue?

KInd regards,
J.P

Presently only a subset of options is available on the command line. It would be good to consolidate options only in the configuration files.

Hello,

I am trying to setup an FMO calculation using your tool. I would like to calculate the interaction energy between a small molecule ligand and all amino acids that are 6 angstrom around it with correct neutralization/ hybridization states at the cut ends. No second layer is needed.

First I generate a setup file as indicated in the tutorial.

fragit-conf -o myconfig.in.txt
myconfig.in.txt - this is an .in file

I then use this file to generate an FMO input file

fragit --use-config=myconfig.in F709_reference.pdb.txt
F709_reference.pdb.txt - this is a .pdb file

which successfully yield a GAMESS-FMO input file.
F709_reference.inp.txt - this is a .inp file

Running this calculation leads to the computation of all fragments against all fragments 128x128 (127 amino acids + 1 ligand) which is undesirable. The calculation however runs (seemingly) fine.

However, when I change in the myconfig.in
centralfragment = 0 to centralfragment = 128
and set
--output-active-distance to --output-active-distance 6

it returns a file that crashes the calculation.

Could you, please, suggest a way to obtain the desired fragmentation scheme?

Additional question: I would also be interested in further "fragmenting" the fragments between side chains and backbone to calculate their individual contributions. Would this be possible with your tool and if so, I wold be grateful if you could indicate me how.

Many thanks in advance for your response,

Bests,

Harold Grosjean

Traceback (most recent call last):
File "/people/disk2/magnus/programs/python/bin/fragit", line 28, in
main()
File "/people/disk2/magnus/programs/python/lib/python2.7/site-packages/fragit/cmdline.py", line 170, in main
out.writeFile(outfile)
File "/people/disk2/magnus/programs/python/lib/python2.7/site-packages/fragit/xyzmfcc.py", line 141, in writeFile
ss = self._fragment_xyz( capped_fragment )
File "/people/disk2/magnus/programs/python/lib/python2.7/site-packages/fragit/xyzmfcc.py", line 127, in _fragment_xyz
(x,y,z) = calculate_hydrogen_position( heavy_atom, atom )
File "/people/disk2/magnus/programs/python/lib/python2.7/site-packages/fragit/util.py", line 387, in calculate_hydrogen_position
alpha = table[heavy.GetAtomicNum()]
KeyError: 16

Instead of the GAMESS-FMO writer being hardcoded inside the gamessfmo.py file it should be template based like the PyMol templates. This will allow for some easier configuration and different templates for different purposes. One could envision one template for FMO with HOP and another for FMO with AFO so that those two are set up differently.

As title says. E.g. if you use Fragit to fragment a water cluster, and therefore no bonds are cut, the "RAFO(1)=1,1,1" line is still in the $FMO group, which in turn confuses GAMESS and yields the following message:

"FMO/AFO requires some orbital localisation in $CONTRL LOCAL."

Thank you for making fragit! It is an awesome tool!

It would be beneficial for debugging purposes to dump the configuration file in the output for debugging purposes and to make sure people had a copy of the configuration file.

There is no check of the parameters being entered in configuration files. For instance, it is possible to enter -2 in the groupcount field.

The statement LOCAL=BOYS is present in the input file per default. For non-covalent systems this is not needed.

The name of the writer 'GAMESS' is too ambiguous. Since GAMESS support many methods of calculation it would be more appropriate to already now adopt a different naming scheme. Also, other programs can do FMO calculations or other fragment based method.

A suggested style would be PROGRAM-METHOD which would make the current GAMESS writer become GAMESS-FMO

This will stop autoloading of FMO specific options such as patterns and what not.

To remove clutter it could be beneficial to demote EFP waters in PyMol output to lines instead of the usual sticks model that is currently used.

Hello @cstein ,

I am facing an error running FragIt. After the error, I am only getting a Python file (no PyMol or JMol files), but I don't know what to do with it.

Here are the input files I am using.

I appreciate any help you can give me.

Regards,

Camps

I added TXT to the files in order to upload them.

1CVZ_prepared.inp.py.txt
FragIt_config.ini.txt
output.out.txt

1CVZ_prepared.pdb.txt

To install fragit I've performed the following steps:

conda create -n frag_it python=3.8
conda activate frag_it
git clone https://github.com/FragIt/fragit-main.git
cd fragit-main

And then as per the README I tried:

python setup.py install

which results in numerous warning.

(frag_it) anthony@mechanicus:~/fragit-main$ python setup.py install
Warning: 'classifiers' should be a list, got type 'filter'
/home/anthony/anaconda3/envs/psi4_python_3_11/lib/python3.11/site-packages/setuptools/_distutils/cmd.py:66: SetuptoolsDeprecationWarning: setup.py install is deprecated.
!!

        ********************************************************************************
        Please avoid running ``setup.py`` directly.
        Instead, use pypa/build, pypa/installer or other
        standards-based tools.

        See https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.html for details.
        ********************************************************************************

!!
  self.initialize_options()
/home/anthony/anaconda3/envs/psi4_python_3_11/lib/python3.11/site-packages/setuptools/_distutils/cmd.py:66: EasyInstallDeprecationWarning: easy_install command is deprecated.
!!

        ********************************************************************************
        Please avoid running ``setup.py`` and ``easy_install``.
        Instead, use pypa/build, pypa/installer or other
        standards-based tools.

        See https://github.com/pypa/setuptools/issues/917 for details.
        ********************************************************************************

!!
  self.initialize_options()
zip_safe flag not set; analyzing archive contents...

Then I tried executing fragit from the command line and I get the warning:

(frag_it) anthony@mechanicus:~/fragit-main$ fragit
/home/anthony/anaconda3/envs/frag_it/bin/fragit:4: DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
  __import__('pkg_resources').run_script('fragit==1.9.0', 'fragit')
Traceback (most recent call last):
  File "/home/anthony/anaconda3/envs/frag_it/bin/fragit", line 4, in <module>
    __import__('pkg_resources').run_script('fragit==1.9.0', 'fragit')
  File "/home/anthony/anaconda3/envs/frag_it/lib/python3.8/site-packages/pkg_resources/__init__.py", line 722, in run_script
    self.require(requires)[0].run_script(script_name, ns)
  File "/home/anthony/anaconda3/envs/frag_it/lib/python3.8/site-packages/pkg_resources/__init__.py", line 1548, in run_script
    raise ResolutionError(
pkg_resources.ResolutionError: Script 'scripts/fragit' not found in metadata at '/home/anthony/fragit-main/fragit.egg-info'

Please note, by following the default installation and not setting a customer prefix, I have not made any adjustment to my PATH or PYTOHNPATH - I'm assuming it's unnecessary as python setup.py install should send everything to the default path.

This might be a simple change to the README to bring it up to date. These deprecation warnings don't explicitly state how to use pypa/build or pypa/installer to help the user. Can these warnings be ignored? Also, I am very sorry if I missed this elsewhere, but what version of Python does fragit require? I noticed 2.7 was mentioned, but not stated whether it was a strict requirement. And finally, any thoughts on why fragit throws a DeprecationWarning?

Thank you for your software and your hard work. It's appreciated.

It would serve FragIt to include the notion of minimum fragment size in order for it to deal well with highly repetitive systems such as polymers.

Often it is difficult to specify unique fragments via SMARTS patterns for polymers and thus a combination of minimum fragment size together with very general SMARTS patterns would make a sound case for FragIt.

Since we are using center of coordinate anyways this should be faster to compute directly in python when the .pymol script is being dumped than when it is computed inside the PyMol GUI.

It would be useful to be able to plot fragment colors by charge (blue for negative, red for positive and green for neutral) in the UI such that the user might be able to identify potential charge problems.

It would be nice if it was possible in some sensible way to include FMO options, especially regarding basis sets and/or orbitals from the HOP scheme.

If you calculate the orbitals yourself for HOP you can distribute them WITH FragIt.

This would, however, require some restructuring of the data folders much like what is done with calcit.

If one uses a file with metal in them, fragit crashes. The problem is that the fragmentation code assumes charges are always available. However, Open Babel silently halts the calculation because of missing charges for the elements.

currently it is now known what the alternative charge-model 'GASTEIGER' does.

it is also unknown how to get the alternative charge-models (http://openbabel.org/dev-api/classOpenBabel_1_1OBChargeModel.shtml#_details) working with the python bindings.

Hello,

I installed OpenBabel and python-openbabel using apt (Ubuntu 19.04).

The problem is that after installing FragIt, I am getting the following error messages:

Error: OpenBabel could not be loaded.
Please make sure OpenBabel has been installed with python bindings.

But Babel and Babel-GUI are working fine when I call them from the command line.

Any idea how to make FragIt to see OpenBabel?

Regards,

The default value of --output-buffer-distance should be zero.

The value in itself has no meaning unless other parameters are specified such as --output-central-fragment.

when doing "sudo setup.py install" to install fragit to /usr/local the setup scripts defaults to installing everything into dist-packages but the data goes into site-packages.

There should be some consistency here.

The fragit_prefix path is hardcoded. It probably shouldn't.

The FMO method in GAMESS supports having EFP fragments mixed with regular FMO fragments. I propose to make the following options to allow for such an input file to be generated directly from FragIt:

• Add option to allow ALL water molecules in a calculation to be treated as EFP waters
• Add option to allow ALL water molecules from a specific layer to be treated as EFP waters

perhaps something along the following lines

[fmo]
watersasefp=0

would be the standard setting, treating NO water molecules as EFP.
For a standard calculation without multiple layers, the change to

[fmo]
watersasefp=1

would indeed include all waters as EFP. This is because the number of layers is 1 for a standard calculation.

In the case of a multilayer calculation, i.e. a calculation where boundaries are used together with centralfragment in [output] the following would promote all waters present in the lower level layer, i.e. layer 1, to EFP waters, but not those present in the higher level layer.

[fmo]
watersasefp=1

This option would then disable the multilayer part of the calculation. Multilayer calculations with EFP waters seems quite exotic.

Currently, I do not envision the settings to be more complicated than this, i.e. including something from a three-layer calculation (who runs those?) would be futile at the moment.

When launching FragIt with the --use-config=FILE option, but FILE does not exist, fragit silently uses the default settings without letting the user know anything.

A recommended fix is to kill FragIt if that happens with an error message.

The following .pdb file will name the sodium atom 'Car' for some reason.

REMARK   4      COMPLIES WITH FORMAT V. 3.0, 1-DEC-2006
REMARK 888
REMARK 888 WRITTEN BY MAESTRO (A PRODUCT OF SCHRODINGER, LLC)
TITLE     A_MM
CRYST1   47.742   47.742   47.742  90.00  90.00  90.00 P 1           1
MODEL        1
HETATM    1  Na  NA      1       1.742  10.448   6.511  1.00  0.00          Na1+
HETATM    2  C1  BEN   900       0.406  -8.166   4.798  1.00  0.00           C
HETATM    3  C2  BEN   900       0.282  -9.416   5.338  1.00  0.00           C
HETATM    4  C3  BEN   900      -0.965  -9.882   5.713  1.00  0.00           C
HETATM    5  C4  BEN   900      -2.061  -9.035   5.628  1.00  0.00           C
HETATM    6  C5  BEN   900      -1.917  -7.702   5.203  1.00  0.00           C
HETATM    7  C6  BEN   900      -0.615  -7.263   4.801  1.00  0.00           C
HETATM    8  H1  BEN   900       1.314  -7.691   4.457  1.00  0.00           H
HETATM    9  H2  BEN   900       1.109 -10.094   5.490  1.00  0.00           H
HETATM   10  H3  BEN   900      -1.089 -10.918   5.993  1.00  0.00           H
HETATM   11  H4  BEN   900      -3.068  -9.236   5.963  1.00  0.00           H
HETATM   12  H5  BEN   900      -2.788  -7.085   5.038  1.00  0.00           H
HETATM   13  H6  BEN   900      -0.496  -6.277   4.378  1.00  0.00           H
CONECT    2    3    7    8
CONECT    2    7
CONECT    3    2    4    9
CONECT    3    4
CONECT    4    3    5   10
CONECT    4    3
CONECT    5    4    6   11
CONECT    5    6
CONECT    6    5    7   12
CONECT    6    5
CONECT    7    2    6   13
CONECT    7    2
CONECT    8    2
CONECT    9    3
CONECT   10    4
CONECT   11    5
CONECT   12    6
CONECT   13    7
ENDMDL
END

The pymol script that fragit generates an error in the hex_to_rgb function because of integer division (in python3 one should use // to force integer-division)

Also, the script should be renamed .py instead of .pymol as .pymol is not recognized in pymol version 1.8.6.

The metals/ions are moved to the back of the file silently(?) due to OpenBabel and it's charge-models. However, the user is not notified of this change.

This issue can (and will be solved in different stages):

1. provide textual information to the user that metal ions have been moved around.
2. should the user provide some manual bond, be very explicit about this.
3. eventually we should just remember the indices of where these atoms need to go instead of appending them.

items 1 and 2 above is quickly 'fixed'. number 3 above is fixed when 1.8 is released.

for now users should either shift indices in the configuration file or move the ions to the back of their file which will also serve as a workaround

Thanks to Morten Steen Nørby for notifying me of this.