There is a bug with VASP 5.4.1 built with mvapich2/2.2 on Owens such that the VASP job with out-of-memory issue crashes the Owens compute node(s). We will investigate monitoring for this type of jobs so that we can cleanup after the job more efficiently, and notify the user of their problem more quickly.
LAMMPS 14May16 on Owens can hang when using the velocity command. Inputs that hang on Owens work on Oakley and Ruby. We are investigating and are looking for a simple example to use in a bug report. We appreciate any help in that endeavor. Here is an example failing input snippet:
velocity mobile create 298.0 111250 mom yes dist gaussian
Update: We think this is fixed. Please submit a ticket if you encounter further problems.
As a result of updates made during yesterday's downtime, software built with mvapich2/1.7 is failing with the error:
libibumad.so.2: cannot open shared object file: No such file or directory
We're working on fixing the problem.
LAMMPS 14May16 was built with the USER-OMP package on Oakley, Ruby, and Owens. Its default behavior is to spawn too many OpenMP threads. lammps/14May16 batch scripts that do not use the USER-OMP package should set the OMP_NUM_THREADS environment variable to 1 as a workaround, e.g.:
for Bourne type shells and
setenv OMP_NUM_THREADS 1
for C type shells.
The default MPI installation on Oakley and Ruby, mvapich2/2.1, appears to have a bug that is triggered by certain programs. The symptoms are 1) the program hangs or 2) the program fails with an error related to Allreduce.
To test whether a failure is related to this issue, as opposed to an error in your code, set the following environment variable in your batch job: MV2_USE_SLOT_SHMEM_COLL=0 This option disables optimizations. If your program runs correctly, you can blame the MPI library.
There are several workarounds to choose from.
Intel compiler versions 11 and later on Glenn do not support the -mkl compiler options. Contact firstname.lastname@example.org for workarounds.
Typical symptoms are
../fft3d.h(184): catastrophic error: cannot open source file "mkl_dfti.h" ld: cannot find -lmkl_intel_lp64
NAMD 2.11 precompiled binaries do not work. Please use NAMD 2.11 installed from the source and available via module namd/2.11.
The NAMD 2.11 issue involves changes to the command charmrun in Charmm++.
A typical symtom is:
Batch scripts loading module lammps-7Dec15 should use the user's login shell or
the Korn shell, e.g. #PBS -S /bin/ksh
There is a bug that causes the module load to fail if the job script specifies the Bash shell, i.e.:
#PBS -S /bin/bash
Alternatiely you can unload mpi and intel-10.x before loading the lammps module.
An example failure is:
OSC has acquired its new ABAQUS license with new license terms. Use is now limited by both institution and for use in educational, institutional, instructional, and/or research purposes. Results arising from use of OSC’s license must be made freely available to anyone without reasonable delay.
Due to the way our Fluent and ANSYS modules are configured, simultaneously loading multiple of either module will cause a cryptic error. The most common case of this happening is when multiple of a users jobs are started at the same time and all load the module at once. In order for this error to manifest, the modules have to be loaded at precisely the same time; a rare occurrence, but a probable occurrence over the long term.
If you encounter this error you are not at fault. Please resubmit the failed job(s).