ATKError: bad allocation

[lib]

I generate the input file using VNL and the calculation can't finish normally.

Traceback (most recent call last):
  File "graphene-zigzag-water.py", line 445, in ?
    runtime_parameters = runtime_parameters
ATKError: bad allocation

I found there's some suggestions posted in the forum. So I disabled the equivalent bulk calculation, changed the number of k-points in z-axis from 500 to 100, and tried to calculate again. But the error seems the same. Should I reduced the number of k-points again or my error belongs to another case?

Another change in the second calculation is the basis set is SZP instead of DZP.

[Anders Blom]

The error means "out of memory", so you did the right thing to reduce the calculation size. Is there any chance you are running several MPI processes in parallel on the same computer? That is, you run in parallel but only have, say, a quad-core, or you use more MPI nodes than physical CPUs? That will put a much smaller limit on the max size of the calculation.

Where does it fail, in the two-probe part or in the electrode calculation? If it's in the two-probe (or equivalent bulk, when included), then changing kz points will not make a difference. How many kx/ky points? How many atoms in total?

Perhaps best to post the script + output, if you are comfortable doing so. You can mask the atom list if needed (replace all atoms by Hydrogen, or something). We just need to see the parameters and get an idea of the size of the system.

[lib]

I have already posted my input files.

I think this problem may be caused by the lack of memory. Although the processor is quad-core one, I run only one atk process on it. There's more than 3.5G physical memory available for ATK and the peak memory it used is no more than 2.0G. I tried to reduce the k-point number in z-axis to 10, but there's the same error when the two probe calculation starts. Today I moved the calculation to a linux workstation, the memory is also 4G on it. By now the calculation is going on well without the same error even when the input file is the 100 k-ponit in z-axis.

[Anders Blom]

Is the error really exactly like you wrote?
In that case, it might not be an out-of-memory error after all (which is St9bad_alloc), but rather something else (like over-lapping atoms).
On the other hand, if you are running it properly now, let's hope it was a spurious thing, perhaps. Let us know if it appears again, and regularly.

Good luck with your calculations!

[Quantamania]

I get this same error with a system known as rhombohedral graphite, which I successfully converted to a hexagonal crystal structure.  The unusual thing is that if I use a large sized unit cell to separate the three layers from their neighboring cells (a supersized cell), I do not encounter this error.  If I use a normal sized unit cell for the structure, I seem to get this error below.

Traceback (most recent call last):
  File "c:/users/christ~1.wel/appdata/local/temp/tmpo_zain.nl", line 213, in ?
    runtime_parameters = runtime_parameters
ATKError: bad allocation
Terminated Abnormally

The normal sized cell has c set at 10.065 angstroms, while the supersized unit cell has it set at 30 angstroms, with the layers still at 3.435 angstroms apart.

I attached a VNL file corresponding to a successful result (the supersized cell).  The error happens almost immediately, before the self-convergence iteration begins, so it does not complete.  I have a dual core PC on Vista.

[zh]

The following parameters should be checked for each configuration because they could strongly affect the required memory size:
i). How many atoms are included in your two different configurations (i.e.,normal size and supercell one)?
ii). What kind of basis set is used? DZP, SZP, or others?
iii). What size is used for the k-point grid? i.e., how many k points are used?
iv). What is the value of the mesh cutoff?

In additional, the nearest neighbor (NN) distances between atoms should also be checked. If one of the NN distances is too short, i.e., two atoms are very close or even overlapped, the job would fail.

[Anders Blom]

I'm a bit confused... The structure you attached works, but the smaller structure does not work? If so, please attach the structure that doesn't work, it is more relevant to inspect that one...

[Quantamania]

There is basically not much difference between the two systems.  The same six atoms placed in relative positions to each other, yet the boundaries are at different distances from this ensemble of atoms.  I have been using DZDP and a 40x40x10 grid to help obtain high-quality results for my dissertation work.  The mesh cutoff is 150 Rydbergs and I normally use LDA-PZ or GGA-revPBE, one at a time.  The models that worked were the ones having the boundaries far away from the atoms (the c-axis direction in the Brillouin zone is very reduced), while the ones that failed were the ones with a more significant c-axis component in the BZ.

The Brillouin zone pathway I used in the previous experiment was to comply with another article, a 1992 entry in Russian Physics Journal by Grinyaev and Lopatin.  It is A-L-M-Gamma-K-H-A-Gamma or in fractional coordinates: (0,0,1/2) - (0,1/2,1/2) - (0,1/2,0) - (0,0,0) - (1/3,1/3,0) - (1/3,1/3,1/2) - (0,0,1/2) - (0,0,0) in that order.  60 points between each k-point are used to produce the band structure diagrams, which help me a lot with making zooms of the K point for carbon-containing layer models.

I have attached the VNL files that failed to produce output.  The crystal system is hexagonal, so that I can relate with the previous conformers (staggered and eclipsed) of the same layered system.  I have looked at the structures with Nanoscope and found no overlap of atoms, but very well formed hexagonal rings.

[Anders Blom]

Normally one would suspect that the larger unit cell would be a problem for the supersized system, in terms of memory. But in this particular case I think the issue lies with the enormous k-points sampling. I doubt you need 40x40, probably 20x20 is just as good, and uses much less memory, and runs much faster.

Note that for the supercell there is no real periodicity in the c-direction, and thus no need for k-point sampling there (1 point is enough). Therefore you have an easier time getting that system to fit in memory, but of course the results will not be the same due to the vacuum gap in the c-direction.

So, in summary, the problem is that you run out of memory due to the large k-point sampling.

[Quantamania]

I see...I have already repeated the runs using 30x30x10 grids for the normal size unit cells.  They are working now at the moment.  Some of the literature that investigated the same kinds of pi-stacked layer materials have used 36x36 grids in the past, and I was well aware of why larger grids improve results of band structure calculations.  That was in fact the solution to the misaligned bands in graphite relative to the Fermi energy level (one of my posted topics).

[zh]

I was well aware of why larger grids improve results of band structure calculations.  That was in fact the solution to the misaligned bands in graphite relative to the Fermi energy level (one of my posted topics).

Usually, before one does any productive calculations, he had better do some convergence test, e.g., the convergence with respect to the size of k-point grid. If the system studied is metallic, the choice of electron temperature in the Fermi-Dirac function could also affect the exact value of Fermi energy level. 



 

[rahulprajesh]

The following parameters should be checked for each configuration because they could strongly affect the required memory size:
i). How many atoms are included in your two different configurations (i.e.,normal size and supercell one)?
ii). What kind of basis set is used? DZP, SZP, or others?
iii). What size is used for the k-point grid? i.e., how many k points are used?
iv). What is the value of the mesh cutoff?

In additional, the nearest neighbor (NN) distances between atoms should also be checked. If one of the NN distances is too short, i.e., two atoms are very close or even overlapped, the job would fail.

Hello ,
m also getting the same error while simulating my structure can anybody help me out. My script file is attached here.

[Anders Blom]

Not much to help, I'm afraid. The system is very large, and your computer does not have enough memory to handle it.

Besides, it is not correctly built. You need to have some Cu in the central region too. Essentially if you split your electrode, and put have the atoms in the electrode and half in the central region, it will at least be a proper two-probe system.