From: nordgren_at_sas.upenn.edu
Date: Thu Jun 09 2005 - 21:56:31 CDT

Hi all,

OK, Axel, thanks for the help. Indeed, I was unaware that the Unix "env"
command could be used to call other commands -- but now I see that this
must be exactly the construction the developers had in mind for calling
NAMD in a parameterized fashion from a wrapper script.

Unfortunately, I'm still having difficulty of a more subtle nature. Now
that I know someone is reading :) I'll elaborate a bit more. Basically,
what I want to do is use VMD to force a rescaling of the distance between
certain parts of my system, and then call NAMD to do some brief energy
minimization of the coordinates, and then repeat the process in a loop
over my scaling parameter. At each step, a new coord frame is generated,
and at the end the entire trajectory is saved. Here is the skeleton of the
VMD script I'm trying to get to work (where the scaling is given by "L")...

---------------------------------------------------------------------------
mol load psf $start_psf pdb $start_pdb
set frame 0
# initial coords are left as-is in frame 0; begin minimizing in next frame
for {set L [expr $max - $del]} {$L >= $min} {set L [expr $L - $del]} {

   # add new frame to the trajectory, with coords copied from current frame
   animate dup frame $frame 0
   incr frame
   animate goto $frame

   # (modify coords of new frame...)

   # call NAMD to energy-minimize the new coords
   animate write pdb $temp_pdb beg $frame end $frame
   set cell_size [expr 4.0 * $L]
   exec env NAMD_psf=$start_psf \
            NAMD_pdb=$temp_pdb \
            NAMD_outfile=$out_name \
            NAMD_minsteps=$namd_minsteps \
            NAMD_cell=$cell_size \
            namd2 +p1 $namd_configfile

   # replace coords of current frame with new (minimized) coords
   animate read pdb $out_name.coor beg $frame end $frame

}

# write the complete trajectory to disk
# (note that this will append to the file, if it exists already)
animate write dcd $final_dcd beg 0 end $frame waitfor all
---------------------------------------------------------------------------

Now, all of the above works, *if* rather than using my "for" loop as above,
I simply set a starting value for "L" and let this code run once (i.e., it
successfully sets up and communicates the variables, runs NAMD once, and
then saves a 2-frame DCD trajectory). But when I try the loop construct,
the script fails, and the first call to NAMD prints:

ERROR: src/NamdState.C(158): Number of pdb and psf atoms are not the same!
Info: Entering startup phase 0 with 7456 kB of memory in use.
Info: Entering startup phase 1 with 7456 kB of memory in use.
Info: Entering startup phase 2 with 14144 kB of memory in use.
Info: Entering startup phase 3 with 14144 kB of memory in use.
Info: PATCH GRID IS 6 (PERIODIC) BY 6 (PERIODIC) BY 3
Info: REMOVING COM VELOCITY 0 0 0
Info: LARGEST PATCH (82) HAS 348 ATOMS
FATAL ERROR: Incorrect atom count in WorkDistrib::assignNodeToPatch
FATAL ERROR: Incorrect atom count in WorkDistrib::assignNodeToPatch

(This appears after the NAMD startup messages and parameter summary, in place
of what should be the "structure summary"; interestingly, the patch grid is
also slightly different, namely 6x6x3 here, instead of 6x6x4 in the non-loop,
non-error case.)

I'm baffled as to what could be different due to using the loop construct.
Again, any insight from the VMD/NAMD community will be much appreciated!

- Erik

p.s. In case it matters, I'm running VMD1.8.3 and NAMD2.5 on an SGI Origin.

Quoting Axel Kohlmeyer <axel.kohlmeyer_at_theochem.ruhr-uni-bochum.de>:

> On Wed, 8 Jun 2005 nordgren_at_sas.upenn.edu wrote:
>
>
>
> EN> I have need for running NAMD multiple times (for short minimization
> runs)
> EN> in a semi-automated way, driven by a VMD (Tcl) script. My inquiry is
> this:
> EN>
> EN> Is it possible to send command-line parameters to NAMD? Something
>
> erik,
>
> since VMD uses the tcl interpreter, you should be able
> to use the tcl 'exec' command without problems and use
> VMD/tcl variables as arguments. you may have to build the
> command line as a tcl list beforehand. some of the VMD plugins
> do spawn external programs, so you may try to grep through
> the bundled tcl scripts for examples that are similar to
> your needs.
>
> EN> analogous to the "args" command for VMD or simple Tcl procs? If not,
> how can
> EN> I communicate the values of variable parameters from a higher-level
> script
> EN> into a particular instance of NAMD? I see in the manual that NAMD can
> EN> read shell environment variables, and this works if I set the
> variables from
> EN> my C-shell and run NAMD once; but when I tried this using "exec
> setenv"
> EN> commands from within a VMD/Tcl script, the environment variables were
> not
> EN> readable by NAMD. I also tried reading/writing my variables from/to a
> text
>
> true. since each 'exec' will spawn a new shell, the environment
> won't be carried over. however, you can try to run NAMD via 'env'
> and get the environment exported. totally stupid example:
>
> please compare
>
> exec sh -c {echo $PATH}
>
> with
>
> exec env PATH=/bin:/usr/bin sh -c {echo $PATH}
>
> and especially
>
> set my_path {/bin:/usr/bin}
> exec env PATH=$my_path sh -c {echo $PATH}
>
> EN> file, using Tcl commands from within VMD and NAMD, but again to no
> avail.
> EN> (Again, running my NAMD job directly from the Unix shell, taking its
> input
> EN> parameters from my VMD-written text file, DOES work; but this time,
> when I
> EN> try running the same NAMD config file from within VMD, I get this
> message:
> EN> "ERROR:src/NamdState.C(158): Number of pdb and psf atoms are not the
> same".)
>
> if the suggestions from above don't help you, could you provide a
> (small) example that demonstrates the problem, so we could try
> locating the root of the problem. your current discription is
> rather vague to me.
>
> regards,
> axel.
>
> EN> I had hoped that, since NAMD and VMD come from the same "house" and
> are
> EN> supposed to play well together, that there might be a simple solution
> to
> EN> my problem. Maybe I've just missed something obvious? Well, anyone
> who
> EN> has any experience and could shed some light, I'd be most grateful.
> EN>
> EN> thanks, as always,
> EN> - Erik
> EN>
> EN> C. Erik Nordgren, Ph.D.
> EN> Department of Chemistry
> EN> University of Pennsylvania
> EN>
> EN>
>
> --
>
> =======================================================================
> Dr. Axel Kohlmeyer e-mail: axel.kohlmeyer_at_theochem.ruhr-uni-bochum.de
> Lehrstuhl fuer Theoretische Chemie Phone: ++49 (0)234/32-26673
> Ruhr-Universitaet Bochum - NC 03/53 Fax: ++49 (0)234/32-14045
> D-44780 Bochum http://www.theochem.ruhr-uni-bochum.de/~axel.kohlmeyer/
> =======================================================================
> If you make something idiot-proof, the universe creates a better idiot.
>