Proposal for tool loading as in issue #68. Awaiting for opinions or changes proposals.

Even if almost complete it remains largely untested (eg. extra and groups).

except for two unit tests everything passes. Most changes should be harmless except for the tool registry, could be I broke that. But changing a dict during iteration isn't allowed in python 3 anymore.

fixes #44

Sorry I am new to the GW. I have successfully installed it on PyCharm. What next should I do?

I tried import GromacsWrapper but got ModuleNotFoundError: No module named 'GromacsWrapper'

I also tried gromacs.g_hbond(s=TPR, f=XTC, g="hbond.log", hbm="hb.xpm", hbn="hb.ndx") but got NameError: name 'gromacs' is not defined

I want to import my ss.xpm file, then I can get an numpy array which contains all the ss records of all the residues for all the time frames. For example, ss[32][21] = 'E' means the 33th residue at 22th time frame has beta-sheet structure. Is this doable?

@orbeckst

Fixes #61 @orbeckst

• Re-enable test cases,
• Exclusions-related bug,
• Handling improper overrides in scaling code,
• Atom naming to match conf.gro file in amber03w tests.

This commit enables to load GMXRC automatically in most common cases. If GMXPRFIX variable is not found in the environmnet, GMXRC is ran in a subprocess and the variables exported by it are set in this environment. I do exactly the same in my weekend toy project pslacerda/gmx. I hope it helps!

In response to my very old issue, this fixes #124.

This adds an option in the config file called append_suffix. If it is set to 'no', the suffix of the gmx executables (such as "_mpi" or "_d") will be ignored when making the tool names. It's not ideal to not differentiate them, but it can make code much more consistent across computers.

The largest change here is that in order to properly test this, the config file has to be changed before gromacs is imported. pytest makes all imports relative to the highest package it can find. Therefore, when tests was nested in the gromacs folder, the tests would be imported as gromacs.tests.test_.... This means that the gromacs.__init__.py is run before even running any of the pytest setup functions. By moving the tests folder out of the gromacs package, the config file can be edited before the gromacs.__init__.py is ever called.

Because of this change, I've tried to refactor all the references to gromacs.tests or gromacs/tests that I could find.

This PR another item to the travis testing matrix that tests this option. Using two new command line options to pytest, a link to the gmx executable called 'gmx_mpi' is put into the home folder and written in the tools section of the config file; and the config file is written to ignore the suffix of the gmx executables found.

~Include Gromacs 2016 in tests (fixes #96)~

EDIT: We use Gromacs 2018 (see PR #127 and discussion in #130 ). This PR contains experimental pytest plugin to provide the pytest --low-performance flag and code to explicitly set the number of threads for gmx mdrun in the tests.

To make it possible to support multiple versions of gromacs installed on a single machine, as well as to make it easier to support custom user environments, we should switch from a INI-style config to a YAML configuration.

A portion of this config would go a long way in solving #48 and #26. For example, the schema for the tools available from various versions of gromacs could look like:

versions:
    4.6.5:
        serial:
            base: ""
            names:
                - grompp
                - trjconv
                - g_rms
        mpi:
            base: ""
            names:
                - mdrun_mpi

    5.1.1:
        serial:
            base: "gmx"
            names:
                - grompp
                - trjconv
                - rms
                - mdrun
        mpi:
            base: "gmx_mpi"
            names:
                - mdrun

We would then probably require specifying which version one plans to use on import. So, one can do:

import gromacs
gromacs.listconfig()             # could use interactively to list config keys available
gromacs.useconfig('4.6.5')  # this will build the classes from the tools found

This does not solve the problem where the same name is present multiple times within the same config, such as for mdrun in 5.1.1 above. At present the same class names are built regardless of the version used, so this would result in an exception.

Unless we build class names with clear namespace differences (such as using the base given in the config), we can't get around this problem. Although possible, having a library that changes its API depending on the config is probably not the best of ideas.

There are huge gaps in the autogenerated docs on http://gromacswrapper.readthedocs.org. Needs to be read, checked, and fixed.

Example: missing docs for most building block modules: http://gromacswrapper.readthedocs.org/en/latest/gromacs/building_blocks.html

My IT created a command gmx_mpi to contrast with a simple Gromacs installation. But I can create an UNIX alias (alias gmx=gmx_mpi) to get around the problem !? My Gromacs command seems to work but for GW it not may be sufficient ? So, may be It could be possible to allow GW use internally of Gromacs 5.1.x gmx_mpi command instead of gmx

Dear GromacswRappers,

I've just installed the GromacsWrapper using pip. Unfortunately, when I try to import any of the available tools, I run into this:

In [7]: import gromacs

ImportError Traceback (most recent call last) in () ----> 1 import gromacs

/usr/local/lib/python2.7/dist-packages/gromacs/init.py in () 184 all = ['config', 'tools', 'cbook', 'fileformats'] 185 --> 186 from . import fileformats 187 188 # Note: analysis not imported by default (requires additional pre-requisites)

ImportError: cannot import name fileformats

Hints on how to resolve it are welcome. Thanks

AttributeDict does not support hasattr() but it should:

import gromacs

ad = gromacs.utilities.AttributeDict(a=1, b=2)

assert hasattr(ad, "a")
assert not hasattr(ad, "x")    # raises AttributeError from KeyError

Using in is a workaround:

assert "a" in ad
assert "x" not in ad

Related to https://github.com/Becksteinlab/MDPOW/pull/174 In gromacs, one can add a specific number of ions by using keywords nn and np. But in gromacs wrapper solvate function, ions only can be added with the keywords concentration. And concentration keywords only works with some specific water models.

The problem: .names doubles after interacting with pickle, cPickle and dill.

How to reproduce (test.txt):

import gromacs.formats as gmx
import os
import pickle

def load_xvg(filepath, failsafe=2):
    xvg_file = gmx.XVG()
    xvg_file.read(filepath)
    return xvg_file

def test_fnc(xvg_file):
    print('names: ', xvg_file.names)
    print('shape: ', xvg_file.array.shape)
    print('names after: ', xvg_file.names)    
    print('shape after: ', xvg_file.array.shape)
    
xvg_filepath = 'test.txt'
pickle_filepath = 'test.pkl'

xvg_file = load_xvg(xvg_filepath)
print('names out: ', xvg_file.names)
print('shape out: ', xvg_file.array.shape)
test_fnc(xvg_file)

pickle.dump(xvg_file, open(pickle_filepath, 'wb'))
xvg_file = pickle.load(open(pickle_filepath, 'rb'))
print('\n2 out: ', xvg_file.names)
test_fnc(xvg_file)

os.remove(pickle_filepath)

gives

names out:  ['Temperature']
shape out:  (2, 2)
names:  ['Temperature']
shape:  (2, 2)
names after:  ['Temperature']
shape after:  (2, 2)

2 out:  ['Temperature']
names:  ['Temperature']
shape:  (2, 2)
names after:  ['Temperature', 'Temperature']
shape after:  (2, 2)

So, something wrong happens on the stage of either dumping or loading. It's also the case for cPickle and dill libs.

As pointed out in PR #164 , the edit_mdp() function should use the MDP parser.

This would also reduce extremely cryptic errors such as gmx grompp: -include is not an option, which happens when a custom template MDP file is used with gromacs.setup.MD() but the template does not contain an include = ... line, which edit_mdp() tries to replace but fails. The failed replacement is then interpreted as a commandline option for gromacs.grompp. Although that's pretty hacky/crappy code logic in the https://github.com/Becksteinlab/GromacsWrapper/blob/cda0874a6469238197e1bef2bd51274b5c80f641/gromacs/setup.py#L796 function, writing a better edit_mdp() (which could, for instance, insert variables as opposed to a simple search and replace, or could check if they are legal variables) would help.

For the paper #147 it would be very beneficial to demonstrate that GromacsWrapper has been used elsewhere, especially in software or work that can be cited.

Please add to this issue any citation for work that used GromacsWrapper.