Problem solved. Looking at the three geometries with consistent settings give the same total energy ordering as other codes. Thanks for the pointer.

Ah yes! The change in the geometries between the different configurations drove inpgen to use different MT spheres. That's a trick for young players when comparing energies!

Yep, that solved the issue. Interestingly six is the right number. If I give seven significant digits in the coordinates I get the wrong symmetry error.

Thanks for the rapid response.

Here's my input:

melem in a box
 
&input cartesian=f film=t /
 
   45.0  0.0 0.0
    0.0 45.0 0.0
    0.0  0.0 20.0
 1.0
 1.0 1.0 1.0
 
    22
7 0 0 0 
6 0.059302 0.00162289 0
6 -0.028247 -0.0521672 0
6 -0.0310565 0.0505454 0
7 0.0881373 -0.046209 0
7 0.00138882 -0.0995056 0
7 0.085479 0.050959 0
7 -0.084088 -0.0532242 0
7 -0.00405272 0.0994338 0
7 -0.0868708 0.0485495 0
6 0.0577063 -0.0939239 0
6 -0.110196 -0.00301348 0
6 0.0524842 0.09694 0
7 0.0874023 -0.142269 0
7 -0.166911 -0.00456213 0
7 0.0794963 0.146834 0
1 0.129784 -0.140596 0
1 0.0667453 -0.179313 0
1 -0.186647 -0.0421058 0
1 -0.18867 0.0318464 0
1 0.0568529 0.182699 0
1 0.121907 0.147472 0
 
&kpt div1=1 div2=1 div3=1 /
 
 

Hi Gregor

My bad. Yes, I must have had a stray density. Cleaning up an rerunning now seems to be working fine.

Ciao
Terry

Yes, that's great. Thanks Gregor.

Hi Gregor

Can I suggest that the wording of that message might be tweaked a bit? In hindsight I can see what it means, but when I first read it in this thread I had no idea what the touch message meant (even as a full-time linux/unix user for more than two decades! )

Ciao
Terry

Hi folks

Does anyone care to comment about accessing "higher rungs" with fleur?

Ciao

Hi Gregor

Thanks for the advice. I will explore those options.

Ciao
Terry

In out.xml we have:
<basis nvd="23313" lmaxd="14" nlotot="0"/>

I didn't specify any options for the diagonalisation when building. The configuration output tells me that SCALAPACK was found (via MKL), but nothing else that looks like diagonalisation. Is that the info you want?

Here's juDFT_times.json (from a slightly different geometry). Run with 32 MPI processes, each allocated 9 cores (9 OpenMP threads) on 28 core broadwell nodes. So up to three MPI processes per node, 11 nodes.

I would have expected that the H must be covalently bound to O2-, putting (OH)- into the surface. Viewing ZnO as purely ionic it's not immediately apparent to me how that would make a conductive surface.

Nonetheless, I guess that is what I was missing was that even by my own argument the surface should be net charged.