A strange error

[BandTheory]

I killed a run today, presuming I had a convergence issue that was unresolved when I discovered the following error:

# ----------------------------------------------------------------
# Equivalent Bulk Calculation (Initial Density for TwoProbe)
# ----------------------------------------------------------------
/home/local/bin/atk-64: line 3: 16373 Killed                  LD_LIBRARY_PATH=$EXEC_DIR/../lib $EXEC_DIR/atk_exec $*
/home/local/bin/atk-64: line 3: 16923 Killed                  LD_LIBRARY_PATH=$EXEC_DIR/../lib $EXEC_DIR/atk_exec $*
Traceback (most recent call last):
  File "<string>", line 414, in ?
ATKError: St9bad_alloc
Traceback (most recent call last):
  File "<string>", line 414, in ?
ATKError: St9bad_alloc
terminate called after throwing an instance of 'std::bad_alloc'
  what():  St9bad_alloc
/home/local/bin/atk-64: line 3: 15631 Aborted                 LD_LIBRARY_PATH=$EXEC_DIR/../lib $EXEC_DIR/atk_exec $*
terminate called after throwing an instance of 'std::bad_alloc'
  what():  St9bad_alloc
/home/local/bin/atk-64: line 3: 16988 Aborted                 LD_LIBRARY_PATH=$EXEC_DIR/../lib $EXEC_DIR/atk_exec $*
mpiexec: Warning: tasks 0,6 exited with status 134.
mpiexec: Warning: tasks 2,5 exited with status 137.

Now I don't doubt that some of what is up there may be particular to our cluster/our installation of Linux, but can is there anything up there that can otherwise be made sense of ?

I'm not sure if I have made it clear before, but I really appreciate how responsive and helpful everyone is here in the forum. It makes everything much easier.

Thanks again,
BT

[Nordland]

ATKError: St9bad_alloc means out of memory. The linux kernel terminate the program since it is not able to allocate the memory needed for the calculation.

[BandTheory]

No kidding ?  What kind of measure could I take to remedy this ?

Thanks again.

[Nordland]

Well you have a list of options to do:

• Either reduce the size of the problem
• Decrease parameters that affect the memory usage highly. In system with a lot of vacuum, this is likely the grid-mesh cutoff. If there is many atoms, then reduce the number of atoms.
• Since this is a twoprobe calculation, disable the equivalent bulk will reduce the memory usage alot.
  
• Alternative run on a machine with more memory.

[BandTheory]

Excellent.

I will likely reduce the mesh cutoff, but I do have a question about the two probe algorithm.  Are there any consequences to using the 'Neutral Atom Density' other than increased convergence time ?  That is are the results in general, the same ?

Thanks again,

BT

[Nordland]

It is all a matter of the starting guess for the twoprobe algorithm, so in principal there is no dependency of the choice of method apart from the time
used to converge a system.

It is in fact to jugde which method is the best, since for systems the neutral atom density works like a charm, and hence it is must faster than the equivalent bulk run. In other systems, you will not be able converge the system if you are not using the equivalent bulk run, and then this is of course superior.

Originally I worked with the idea, that equivalent bulk run always superior, but I have found system, where converging the equivalent bulk is harder than the two-probe part, and in this case, the neutral atom density is the only solution that will work. A good example of such as system is the Z-shaped graphene junction.