Add option to include waters as EFP in GAMESS-FMO

[cstein]

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.

[cstein]

In the recent commit 52d95d92b8fca8efa2e7479450ece1f8999596f8 the labels are broken because we try to keep the same labels as in the original file. This is not so intelligent because different versions of openbabel will fragment systems differently and the search for water molecules is also not deterministic.

Therefore I suggest to relabel them as 1, 2, 3 ... and so on.

[cstein]

After adding a sort through 09fad2024ee74d3a4b36855fa8d5cc3f5a4c9dd1 the atom coordinates in the efrag coordinate section is broken between python versions. It is not entirely clear why, but since there is no real order for fragmentation the 2form8wat.pdb files gives different (correct!) answers. So I wonder how to test that in a better way than what is currently being done (by checking for exact correctness of generated input)

[cstein]

In the end the tests run on Python 2.X but will fail in python 3.X because OpenBabel gives some randomness between the two versions.

[cstein]

Actually, we could just skip the check on the $EFRAG group. This might be more intelligent actually. So if (when) the test finds EFRAG just skip. We should then check on the number of fragments + number of EFPs.

Also add a test fixture of a system with covalent bonds. The re-indexing fucks it up good. The file 10_min_001.xyz attched in future_fixture.zip ought to do it.