Files prepared and density convergence / ELF calculation put into the queue on 32 nodes with 8 ppn and a walltime of 36 hours.

Density successfully converged after, however I forgot to add prtelf 1 so no elf was printed. In order to do things exactly the same as mz84 and mz133, the calculation is being rerun with prtelf 1 added in. I know this is a slight waste of computational time, but I want to be consistent.

Density successfully converged after 15 SCF steps and ELF printed.
Final etot = -951.01382589238 Hartrees.
Final diff in etot = -3.274E-9.
nkpt = 258.
natom = 128.
nband = 256.
ngfft = 180 50 100.
ecut = 25 Hartrees.
Run on 32 nodes, 8 ppn.
It took 35148.7 seconds per processor = 9 hours 46 minutes
Size of abinit ELF output file: 7.6 mb
Size of ELF vesta file: 20.7 mb

Next step is to converge the WFK and print the PDOS. Considering the memory problems of the others, I'm going to start right off with 64 nodes, 4 ppn, 24 hours.

The calculation ran a few days ago, however it did not run to completion. Instead it ran out of memory while apparently converging the wavefunction before angular analysis. A few things to note:

  1. It needs 647.822 Mbytes of memory (MORE than laqnib).
  2. It still says the the unit cell is not primitive.
  3. It did NOT have pvmem=5GB on. That was an amateur mistake.
  4. Despite that, it ran for longer than laqnoh (in terms of what was written in the log file).
  5. The log file departed from the successfully calculated (kinda) PDOS compounds (mz84 and mz133) as shown below:

Printing of kinetic energy totals usually happens at the end of an SCF cycle while converging the density in the first step. Odd that it's here too. - Determined this was because I had forgot to comment out prtelf 1.

Will report back on meeting with Josh.

Here's the plan:

  1. Run the calculations on a smaller k point grid, trying to print the PDOS. This will test if the memory required for the PDOS calculation is a function of k-points.
  2. If still unsuccessful, I will reduce the number of bands to reduce the memory required, as we know that memory scales with bands. I am worried about approaching the band edge, however.

The smaller k point grid calculation ran, however though only 449.177 Mbytes of memory were requested, the job ran out of memory. I'm changing nband to 260 to cut right to the chase. If we cannot calculate PDOS four bands above the valence band then we are in trouble.

I successfully calculated the PDOS with 40 k-points and 260 bands. The same error observed in mz133 and mz84 is also seen here (formatted runtime error) and the PDOS of atoms 3 and 11 failed to print. Still, this is an excellent result. Unfortunately, the 300 band calculation that ran yesterday I wasn't using 4 ppn and pvmem = 5GB, therefore I'm going to try that again with these in place to see if we can get all of the bands we want. If that is successful then I'll "fill in" the missing atoms and try to repeat the process for a larger number of k-points. By comparing the two PDOS plots qualitatively and their orbital overlaps quantitatively we should be able to see the effects of more or less k-points.

PDOS successfully (error still present) calculated with 40 k-points and 300 bands. I'm going to "fill in" the missing atoms, 3 and 11, and then I'll move onto a 4x4x4 k-point grid. In preparation I ran an interactive job with a 4x4x4 grid and determined that it gives 84 k-points which will require 21 nodes with 4 ppn. I've submitted two jobs into the queue and held them in preparation. I could just make a separate input file, however I'd prefer to not have twice as many temporary files in the directory, therefore I'll just wait and do them one at a time.

PDOS of atoms 3 and 11 printed successfully. Here are the specs:
nkpt = 40.
natom = 128.
nband = 300.
ngfft = 180 50 100.
ecut = 25 Hartrees.
Run on 10 nodes, 4 ppn.
It took 32675.9 seconds per processor = 9 hours 5 minutes

I'm now changing the k-point grid in the input file and releasing the first job.

I accidentally "filled in" the 84 k-point PDOS before doing the full calculation. Here are the specs:
nkpt = 84.
natom = 128.
nband = 300.
ngfft = 180 50 100.
ecut = 25 Hartrees.
Run on 21 nodes, 4 ppn.
It took 36575.2 seconds per processor = 10 hours 10 minutes

Shouldn't be a problem to do other calculation first. I've released the second job. I've also determined that a 5x5x5 grid will have 156 k-points, thereby requiring 39 nodes with 4 ppn. I've put two jobs into the queue with these specs and held them. After The 4x4x4 calulations are done I will release them one at a time to calculate and then fill in the PDOS. With 3x3x3, 4x4x4, and 5x5x5 calculations, I should be able to draw conclusions about the time it takes to calculate the PDOS, the approximate memory required, and the importance of the k-point grid on the PDOS and resulting orbital overlap.

Alex took a look at the abinit generated ELFs and the whole induced inert pair stuff is not at all present. Because we trust the ELFs from abinit a lot more than those from LMTO this means that this part of the story is simply gone. Kinda sucks, but it's better to be right.

Of course I forgot to change the natsph index from 2, therefore the PDOS was only calculated for atoms 1 and 2. Derp. I've fixed this mistake and set the k-point grid to 5x5x5 and released the first 156 k-point job. I have put another calculation into the queue for 84 k-points and I will come back and get the rest of the 84 k-point PDOS after the 156 k-point PDOS because these two jobs are now higher in the queue.

I'm going to do an examination of the dependence of the PDOS on k-points. See PDOS examination for more info.

156 k-point job ran out of memory. Looks like 84 k-points is going to have to do.

84 k-point PDOS complete. Hurrah!

Te coordination examined with Shape. See Shape Calculations for more information.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License