Skip to main content



PINY_MD(c) is a multipurpose, object-oriented molecular simulation package developed as a collaborative effort between Indiana University, New York University and the University of Pennsylvania. PINY_MD(c) is capable of performing a wide variety of molecular dynamics, electronic structure, and geometry optimization calculations. Such capabilities include force-field based (``classical'') simulations on system ranging in complexity from simple molecular liquids (.e.g, water, ammonia, liquid alkanes) and crystals (e.g., ice) to large biomolecular systems such as the HIV-1 protease in solution. Long range electrostatic forces are treated using smooth particle-mesh Ewald summation techniques. Biomolecular systems can be constructed using the code's built-in molecular building tools. In addition, PINY_MD(c) can perform ab initio molecular dynamics and geometry optimization using plane-wave based generalized gradient (GGA) density functional based representations of the electronic structure combined with the Car-Parrinello propagation scheme.

Versions and Availability

Softenv Keys for piny on oliver
Machine Version Softenv Key
None Available N/A N/A
▶ Softenv FAQ?

The information here is applicable to LSU HPC and LONI systems.


A user may choose between using /bin/bash and /bin/tcsh. Details about each shell follows.


System resource file: /etc/profile

When one access the shell, the following user files are read in if they exist (in order):

  1. ~/.bash_profile (anything sent to STDOUT or STDERR will cause things like rsync to break)
  2. ~/.bashrc (interactive login only)
  3. ~/.profile

When a user logs out of an interactive session, the file ~/.bash_logout is executed if it exists.

The default value of the environmental variable, PATH, is set automatically using SoftEnv. See below for more information.


The file ~/.cshrc is used to customize the user's environment if his login shell is /bin/tcsh.


SoftEnv is a utility that is supposed to help users manage complex user environments with potentially conflicting application versions and libraries.

System Default Path

When a user logs in, the system /etc/profile or /etc/csh.cshrc (depending on login shell, and mirrored from csm:/cfmroot/etc/profile) calls /usr/local/packages/softenv-1.6.2/bin/ to set up the default path via the SoftEnv database.

SoftEnv looks for a user's ~/.soft file and updates the variables and paths accordingly.

Viewing Available Packages

The command softenv will provide a list of available packages. The listing will look something like:

$ softenv
These are the macros available:
*   @default
These are the keywords explicitly available:
+amber-8                       Applications: 'Amber', version: 8 Amber is a
+apache-ant-1.6.5              Ant, Java based XML make system version: 1.6.
+charm-5.9                     Applications: 'Charm++', version: 5.9 Charm++
+default                       this is the default environment...nukes /etc/
+essl-4.2                      Libraries: 'ESSL', version: 4.2 ESSL is a sta
+gaussian-03                   Applications: 'Gaussian', version: 03 Gaussia
... some stuff deleted ...
Managing SoftEnv

The file ~/.soft in the user's home directory is where the different packages are managed. Add the +keyword into your .soft file. For instance, ff one wants to add the Amber Molecular Dynamics package into their environment, the end of the .soft file should look like this:



To update the environment after modifying this file, one simply uses the resoft command:

% resoft

The command soft can be used to manipulate the environment from the command line. It takes the form:

$ soft add/delete +keyword

Using this method of adding or removing keywords requires the user to pay attention to possible order dependencies. That is, best results require the user to remove keywords in the reverse order in which they were added. It is handy to test out individual keys, but can lead to trouble if changing multiple keys. Changing the .soft file and issuing the resoft is the recommended way of dealing with multiple changes.


Usage requires invoking the PINY_MD command and providing it with the name of an input file as an argument. Generically, it looks like:

    $ piny_md_machine sim_input

To find the name assigned to the executable, use the soft-dbq to examine the softenv key used for PINY. It will give the path to executable. For instance:

$ soft-dbq +piny-md-intel-11.1-mvapich-1.1
This is all the information associated with
the key or macro +piny-md-intel-11.1-mvapich-1.1.


Name: +piny-md-intel-11.1-mvapich-1.1
Description: @types: Applications @name: piny-md @version: Aug 30,
2005 @build: mvapich-1.1-intel-10.1 @about: PINY_MD(c) is a
multipurpose, object-oriented molecular simulation package developed
as a collaborative effort between Indiana University, New York
University and the University of Pennsylvania.
Flags: none
Groups: none
Exists on: Linux


On the Linux architecture,
the following will be done to the environment:

  The following environment changes will be made:
    PATH = ${PATH}:/usr/local/packages/piny-md/intel-11.1-mvapich-1.1/bin
$ ls /usr/local/packages/piny-md/intel-11.1-mvapich-1.1/bin

This shows the path to PINY_MD and the existance of a single executable name piny_md_par. The _par indicates it is a parallel build, and the key name shows it was built with mvapich 1.1.

Setting up a simulation is the hard part of using the program. For guidance there, please refer to the Resources below.

▶ QSub FAQ?

Portable Batch System: qsub


All HPC@LSU clusters use the Portable Batch System (PBS) for production processing. Jobs are submitted to PBS using the qsub command. A PBS job file is basically a shell script which also contains directives for PBS.

$ qsub job_script

Where job_script is the name of the file containing the script.

PBS Directives

PBS directives take the form:

#PBS -X value

Where X is one of many single letter options, and value is the desired setting. All PBS directives must appear before any active shell statement.

Example Job Script
 # Use "workq" as the job queue, and specify the allocation code.
 #PBS -q workq
 #PBS -A your_allocation_code
 # Assuming you want to run 16 processes, and each node supports 4 processes, 
 # you need to ask for a total of 4 nodes. The number of processes per node 
 # will vary from machine to machine, so double-check that your have the right 
 # values before submitting the job.
 #PBS -l nodes=4:ppn=4
 # Set the maximum wall-clock time. In this case, 10 minutes.
 #PBS -l walltime=00:10:00
 # Specify the name of a file which will receive all standard output,
 # and merge standard error with standard output.
 #PBS -o /scratch/myName/parallel/output
 #PBS -j oe
 # Give the job a name so it can be easily tracked with qstat.
 #PBS -N MyParJob
 # That is it for PBS instructions. The rest of the file is a shell script.
 #   1. Copy the necessary files from your home directory to your scratch directory.
 #   2. Execute in your scratch directory.
 #   3. Copy any necessary files back to your home directory.

 # Let's mark the time things get started.


 # Set some handy environment variables.

 export HOME_DIR=/home/$USER/parallel
 export WORK_DIR=/scratch/myName/parallel
 # Set a variable that will be used to tell MPI how many processes will be run.
 # This makes sure MPI gets the same information provided to PBS above.

 export NPROCS=`wc -l $PBS_NODEFILE |gawk '//{print $1}'`

 # Copy the files, jump to WORK_DIR, and execute! The program is named "hydro".

 cp $HOME_DIR/hydro $WORK_DIR
 mpirun -machinefile $PBS_NODEFILE -np $NPROCS $WORK_DIR/hydro

 # Mark the time processing ends.

 # And we're out'a here!

 exit 0


Last modified: June 26 2015 14:09:16.