Due to a recent software vulnerability discovered in bwa versions 0.7.17 and 0.7.13, it is highly recommended to immediately stop using these versions and instead use bwa/0.7.17-r1198 which contains a patch to mitigate this vulnerability.
We have found that recent MPI jobs using openmpi/1.10-hpcx and openmpi/2.0-hpcx on Owens may complete or hang until the job is killed, but receive segmentation fault. Some applications might be affected (if you run these applications with openmpi mentioned above): orca, openfoam and lammps. OSC users can use other compatible versions, e.g. openmpi/1.10.7-hpcx and openmpi/2.1.6-hpcx. Please check available version from the software page.
Gaussian-4 (G4) theory calculations in Gaussian 16 Rev. B.01 can produce erratic results. A workaround is to use Gaussian 16 Rev. A.03 or Rev. C.01, e.g.:
module load gaussian/g16c01
Gaussian 16 Rev. A.03 has been made the default module on all clusters. A typical symtom is energy blow up in step 8 resulting in an unusually large, erroneous HF/GFHFB2 energy and consequently an incorrect G4 total energy.
On Pitzer both LAMMPS 22Aug18 and 5Jun19 gpu jobs with ppn=40 hang immediately after lammps begins execution. A workaround is to use ppn=39.
We are experiencing problems with the ArcGIS license server. We will resume working on restoring access to this software on October 24th, 2018.
=====
It is fixed and running correctly on Oct 14, 2018
We are experiencing problems with the LS-DYNA license server. We will resume working on restoring access to this software on October 24th, 2018.
==
It has been fixed and working correctly since Oct. 24, 2018
Libraries for intel/18.0.3 and intel/17.0.7 are not compatible with cxx17.
Intel compilers need gnu library to support 2017 ISO C++ standard, and cxx17 is the module to load the gnu environment for the intel compilers.
You could have errors when you try to compile with the libraries with the default intel environment.
=== update ===
We fixed the issue on Sep 19, 2018. Please contact OSC Help if you have any questions.
If you run a parallel (or even serial!) job, but not using all the cpus per node, the number of processes and their distribution is OK, but on the first node it appears they are all pinned to 1 cpu.
On Owens, usage of user-defined material (UMAT) script for abaqus is limited as following:
abaqus 2017: correctly running on single and multi-nodes
abaqus 6.14 and 2016: correctly running only on a single node
Resolved: We confirmed that this is an issue on the old versions only. The software page indicates this issue.
