Hello,
I am trying single point calculation of system having around 440 atoms. I tried with 400 cores initially but the simulation was terminated automatically after a while. I again tried with 220 cores, but the simulation was terminated saying "BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES".
There was no changes in the oszicar file in both cases and OUTCAR files was like stuck after setting up the simulation means nothing was written afterwards.
I am sharing the related files. PFA..
BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
Moderators: Global Moderator, Moderator
-
aniket_singha
- Newbie
- Posts: 28
- Joined: Fri Dec 18, 2020 1:23 pm
BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
You do not have the required permissions to view the files attached to this post.
-
martin.schlipf
- Global Moderator
- Posts: 542
- Joined: Fri Nov 08, 2019 7:18 am
Re: BAD TERMINATION OF ONE OF YOUR APPLICATION PROCESSES
There doesn't seem to be a fundamental issue why this calculation wouldn't run. It is possible that your current setup is not sufficient to handle this large system. Did you explore some easier intermediate systems first to approach the full complexity of this interface?
If you did not, here are a few recommendations how to approach a complicated system like this:
1) Calculate the bulk compounds to get some idea of the electronic structure of the constituents. This can already help to find a good setup e.g. in terms of the magnetic moments.
2) Create individual films of the constituents. This way lattice mismatches are avoided and typically the cell is much smaller. The vacuum distance does not have to be converged at this stage.
3) Mix the two constituents into a film. Explore if there is some way to create a smaller cell even if that involves reducing the number of layers or larger lattice mismatches.
4) Run the true system of interest but reduce the computational cost, e.g., by smaller vacuum distances, switching off magnetization, no vdW ...
5) Step by step increase the computational cost until you arrive at the converged setup.
The general idea is to learn a bit more about the system at every step along the way. When jumping from step 1 or 2 to step 5, often one is not aware of the computational cost.
I also had a look at the computational setup and there seem to be a few mistakes that will limit the performance.
1) If only the Gamma point is used, the gamma-only version of VASP should be used. This is ~2 times more efficient.
2) Please consider the warnings and the advice the code prints.
3) For large cells use LREAL = .FALSE.
4) Use also the NCORE parallelization level
5) Do not switch of scalapack
It may also be beneficial to contact the HPC support at your site. It seems that you installed VASP manually which may not be the most efficient setup. They may either help you setting up a better installation on their machine or install VASP as a module. I'm also a bit puzzled about the SLURM_CPUS_ON_NODE=11 which doesn't seem to be a factor of the 400 cores you requested, so maybe they offer also some advice for these larger jobs.
If you did not, here are a few recommendations how to approach a complicated system like this:
1) Calculate the bulk compounds to get some idea of the electronic structure of the constituents. This can already help to find a good setup e.g. in terms of the magnetic moments.
2) Create individual films of the constituents. This way lattice mismatches are avoided and typically the cell is much smaller. The vacuum distance does not have to be converged at this stage.
3) Mix the two constituents into a film. Explore if there is some way to create a smaller cell even if that involves reducing the number of layers or larger lattice mismatches.
4) Run the true system of interest but reduce the computational cost, e.g., by smaller vacuum distances, switching off magnetization, no vdW ...
5) Step by step increase the computational cost until you arrive at the converged setup.
The general idea is to learn a bit more about the system at every step along the way. When jumping from step 1 or 2 to step 5, often one is not aware of the computational cost.
I also had a look at the computational setup and there seem to be a few mistakes that will limit the performance.
1) If only the Gamma point is used, the gamma-only version of VASP should be used. This is ~2 times more efficient.
2) Please consider the warnings and the advice the code prints.
3) For large cells use LREAL = .FALSE.
4) Use also the NCORE parallelization level
5) Do not switch of scalapack
It may also be beneficial to contact the HPC support at your site. It seems that you installed VASP manually which may not be the most efficient setup. They may either help you setting up a better installation on their machine or install VASP as a module. I'm also a bit puzzled about the SLURM_CPUS_ON_NODE=11 which doesn't seem to be a factor of the 400 cores you requested, so maybe they offer also some advice for these larger jobs.
Martin Schlipf
VASP developer