Thanks for your reply. I am most appreciative of your detailed response.
Please see below for my comments.
On 05/15/2019 08:12 PM, Steven D'Aprano wrote:
Hi Stephen,
My responses are interleaved with your comments below. Please excuse the
length of my post, but your problem is a complicated one.
On Wed, May 15, 2019 at 08:16:02AM -0400, Stephen P. Molnar wrote:
I am writing scripts to semi-automate some of my Quantum Chemistry
software and have encountered a problem that has me baffled. The two
scripts have the same form, the only difference being the commands. One
script works, the other bombs.
A note on terminology: to programmers, the terminology "bombs" usually
refers to a fatal application crash detected by the operating system:
https://en.wikipedia.org/wiki/Bomb_%28icon%29
whereas what you are experiencing is merely an exception with a
traceback displayed. The difference is that a "bomb" (or a "crash") is a
serious bug in the application (Python), while an exception is actually
a sign that Python is working correctly.
The bottom line is that there's not much you can do about a bomb except
stop running the script, whereas an exception means there's a bug in
your code you can fix.
My use of computers in my scientific work goes back to the early 1960's
as a graduate student when I took an introductory course in FORTRAN II.
I am a Chemist and not a professional programmer, although I
occasionally write a FORTRAN program, thanks to Linux and gfortran.
Although retired, I am still maintaining a computational chemistry
research program.
So, substitute 'bug' for 'bomb' in this thread.
The script that works is:
[...]
Thanks for the careful and detailed samples of your code, but in general
unless you are paying a consultant to to the work for you, it is best to
try to narrow down the samples to the smallest amount that demonstrates
the problem. We're volunteers, donating our time for free, and often
with very limited time to offer. Every extra line of code you present us
with discourages us a little more from tackling your problem, so the
smaller the amount of code, the more likely we are to help.
For a better explanation, you might like to read this:
http://www.sscce.org/
It is written for Java programmers but applies to any language.
#!/usr/bin/env python
This line tells a Unix system to run the script using "python", which is
probably going to be Python 2. But I see from your code below that you
are actually running Python 3 code. So this is a potential problem. I
cannot tell if it is *actually* a problem right now, or will only become
one in the future.
You could try replacing the word "python" with "python3", but you should
run these commands at the Unix shell first:
env python
env python3
and see what they say.
Another problem is that both of your scripts call out to an external
script `pythonsh` which we cannot see, so there's no way of knowing what
that is doing.
Pythonsh is a bash script, a part of MGL_Tools
(http://mgltools.scripps.edu/) which is the source of prepare_ligand4.py
and prepare_dpf4.py which I am attempting to implement in my two
scripts. MGL_Tools is a gui for AutoDock which, in turn I have been
using for at least 25 years now. (Both MGL_Tools and AutoDock are open
source and have been widely used.)
The function of pythonsh is to establish an environment for the use of
python2 and to set a number of paths.. If I invoke pythonsh in a bash
shell I get:
comp@AbNormal:/sdc1/Apps/Models/1-NerveAgents/Scripts$ ./pythonsh
setting PYTHONHOME environment
Python 2.5.6 (r256:88840, Nov 6 2012, 15:29:26)
[GCC 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>
The second script refers to yet another Python script
`prepare_pdf4.py` but the output says this file doesn't exist:
can't open file
'./prepare_pdf4.py': [Errno 2] No such file or directory
So that's a problem you need to fix. I have no idea if that will fix
everything, or just part of the issue.
The problem may not be the invocation of prepare_dpf4.py, because:
comp@AbNormal:/sdc1/Apps/Models/1-NerveAgents/Ligands$ ./pythonsh
./prepare_dpf4.py
prepare_dpf4.py: ligand and receptor filenames
must be specified.
Usage: prepare_dpf4.py -l pdbqt_file -r pdbqt_file
-l ligand_filename
-r receptor_filename
Optional parameters:
[-o output dpf_filename]
[-i template dpf_filename]
[-x flexres_filename]
[-p parameter_name=new_value]
[-k list of parameters to write]
[-e write epdb dpf ]
[-v] verbose output
[-L] use local search parameters
[-S] use simulated annealing search parameters
[-s] seed population using ligand's present conformation
Prepare a docking parameter file (DPF) for AutoDock4.
The DPF will by default be _.dpf. This
may be overridden using the -o flag.
Then:
/sdc1/Apps/Models/1-NerveAgents/Ligands$ ./pythonsh
