Here the basic command class GromacsCommand is defined. All Gromacs command classes in gromacs.tools are automatically generated from it. The documentation of GromacsCommand applies to all wrapped Gromacs commands and should be read by anyone using this package.
Each command wrapped by either GromacsCommand or Command takes three additional keyword arguments: stdout, stderr, and input. stdout and stderr determine how the command returns its own output.
The input keyword is a string that is fed to the standard input of the command (actually, subprocess.Popen.stdin). Or, if it is not string-like then we assume it’s actually a file-like object that we can read from, e.g. a subprocess.Popen.stdout or a File.
By setting the stdout and stderr keywords appropriately, one can have the output simply printed to the screen (use True; this is the default, although see below for the use of the capture_output gromacs.environment flag), capture in a python variable as a string for further processing (use False), write to a file (use a File instance) or as input for another command (e.g. use the subprocess.Popen.stdin).
When writing setup- and analysis pipelines it can be rather cumbersome to have the gromacs output on the screen. For these cases GromacsWrapper allows you to change its behaviour globally. By setting the value of the gromacs.environment Flag capture_output to True (in the GromacsWrapper gromacs.environment.flags registry)
import gromacs.environment
gromacs.environment.flags['capture_output'] = True
all commands will capture their output (like stderr = False and stdout = False). Explicitly setting these keywords overrides the global default. The default value for flags['capture_output'] is False, i.e. output is directed through STDOUT and STDERR.
Warning
One downside of flags['capture_output'] = True is that it becomes much harder to debug scripts unless the script is written in such a way to show the output when the command fails. Therefore, it is advisable to only capture output on well-tested scripts.
A third value of capture_output is the value "file":
gromacs.environment.flags['capture_output'] = "file"
This writes the captured output to a file. The file name is specified in flags['capture_output_filename' and defaults to “gromacs_captured_output.txt”. This file is over-written for each command. In this way one can investigate the output from the last command (presumably because it failed). STDOUT and STDERR are captured into this file by default. STDERR is printed first and then STDOUT, which does not necessarily reflect the order of output one would see on the screen. If your code captures STDOUT for further processing then an uncaptured STDERR is written to the capture file.
Note
There are some commands for which capturing output (flags['capture_output'] = True) might be problematic. If the command produces a large or inifinite amount of data then a memory error will occur because Python nevertheless stores the output internally first. Thus one should avoid capturing progress output from e.g. Mdrun unless the output has been throttled appropriately.
Base class for wrapping a g_* command.
Limitations: User must have sourced GMXRC so that the python script can inherit the environment and find the gromacs programs.
The class doc string is dynamically replaced by the documentation of the gromacs command when an instance is created.
Set up the command with gromacs flags as keyword arguments.
The following are generic instructions; refer to the Gromacs command usage information that should have appeared before this generic documentation.
As an example, a generic Gromacs command could use the following flags:
cmd = GromacsCommand('v', f=['md1.xtc','md2.xtc'], o='processed.xtc', t=200, ...)
which would correspond to running the command in the shell as
GromacsCommand -v -f md1.xtc md2.xtc -o processed.xtc -t 200
Gromacs command line arguments
Gromacs boolean switches (such as -v) are given as python positional arguments ('v') or as keyword argument (v=True); note the quotes in the first case. Negating a boolean switch can be done with 'nov', nov=True or v=False (and even nov=False works as expected: it is the same as v=True).
Any Gromacs options that take parameters are handled as keyword arguments. If an option takes multiple arguments (such as the multi-file input -f file1 file2 ...) then the list of files must be supplied as a python list.
If a keyword has the python value None then it will not be added to the Gromacs command line; this allows for flexible scripting if it is not known in advance if an input file is needed. In this case the default value of the gromacs tool is used.
Keywords must be legal python keywords or the interpreter raises a SyntaxError but of course Gromacs commandline arguments are not required to be legal python. In this case “quote” the option with an underscore (_) and the underscore will be silently stripped. For instance, -or translates to the illegal keyword or so it must be underscore-quoted:
cmd(...., _or='mindistres.xvg')
Command execution
The command is executed with the run() method or by calling it as a function. The two next lines are equivalent:
cmd(...) cmd.run(...)When the command is run one can override options that were given at initialization or one can add additional ones. The same rules for supplying Gromacs flags apply as described above.
Non-Gromacs keyword arguments
The other keyword arguments (listed below) are not passed on to the Gromacs tool but determine how the command class behaves. They are only useful when instantiating a class, i.e. they determine how this tool behaves during all future invocations although it can be changed by setting failuremode. This is mostly of interest to developers.
Keywords : |
|
---|
Returns a special Popen instance (PopenWithInput).
The instance has its input pre-set so that calls to communicate() will not need to supply input. This is necessary if one wants to chain the output from one command to an input from another.
Todo : | Write example. |
---|
Returns the commandline that run() uses (without pipes).
mode determines how the GromacsCommand behaves during failure
It can be one of the following:
- ‘raise’
- raises GromacsError if command fails
- ‘warn’
- issue a GromacsFailureWarning
- None
- just continue silently
Available failure modes.
Usage for the underlying Gromacs tool (cached).
Print help; same as using ? in ipython. long=True also gives call signature.
Run the command; args/kwargs are added or replace the ones given to the constructor.
Combine arguments and turn them into gromacs tool arguments.
Wrap simple script or command.
Set up the command class.
The arguments can always be provided as standard positional arguments such as
"-c", "config.conf", "-o", "output.dat", "--repeats=3", "-v", "input.dat"
In addition one can also use keyword arguments such as
c="config.conf", o="output.dat", repeats=3, v=True
These are automatically transformed appropriately according to simple rules:
If this does not work (as for instance for the options of the UNIX find command) then provide options and values in the sequence of positional arguments.
Run command with the given arguments:
rc,stdout,stderr = command(*args, input=None, **kwargs)
All positional parameters args and all gromacs kwargs are passed on to the Gromacs command. input and output keywords allow communication with the process via the python subprocess module.
Arguments : |
|
---|
Depending on the value of the GromacsWrapper flag gromacs.environment.flags```['capture_output']` the above default behaviour can be different.
All other kwargs are passed on to the Gromacs tool.
Returns : | The shell return code rc of the command is always returned. Depending on the value of output, various strings are filled with output from the command. |
---|---|
Notes : | In order to chain different commands via pipes one must use the special PopenWithInput object (see GromacsCommand.Popen() method) instead of the simple call described here and first construct the pipeline explicitly and then call the PopenWithInput.communicate() method. STDOUT and PIPE are objects provided by the subprocess module. Any python stream can be provided and manipulated. This allows for chaining of commands. Use from subprocess import PIPE, STDOUT
when requiring these special streams (and the special boolean switches True/False cannot do what you need.) (TODO: example for chaining commands) |
Run the command; args/kwargs are added or replace the ones given to the constructor.
Transform arguments and return them as a list suitable for Popen.
Returns a special Popen instance (PopenWithInput).
The instance has its input pre-set so that calls to communicate() will not need to supply input. This is necessary if one wants to chain the output from one command to an input from another.
Todo : | Write example. |
---|
Print help; same as using ? in ipython. long=True also gives call signature.
Derive a class from command; typically one only has to set command_name to the name of the script or executable. The full path is required if it cannot be found by searching PATH.
Popen class that knows its input.
Note
Some versions of python have a bug in the subprocess module ( issue 5179 ) which does not clean up open file descriptors. Eventually code (such as this one) fails with the error:
OSError: [Errno 24] Too many open files
A weak workaround is to increase the available number of open file descriptors with ulimit -n 2048 and run analysis in different scripts.
Initialize with the standard subprocess.Popen arguments.
Keywords : |
|
---|
Run the command, using the input that was set up on __init__ (for use_input = True)