changes in p2y between rev. 52 and rev. 58

[leoteo]

Dear forum,

I have just updated the yambo revision from 52 to 58 and I am noticing several differences in the databases generated by p2y. For both revisions, I used the the same .save directory generated by Quantum Espresso 5.0.3 (using norm-conserving PBE pseudopotentials).

1. In ns.db1, I find that

Code: Select all

data:

 DIMENSIONS = 4672, 3, 4, 1, 3187, 1300, 1, 3784211, 473045, 1, 2, 1, 1, 0,
    66, 3, 101130 ;

changes to

Code: Select all

data:

 DIMENSIONS = 2780, 3, 4, 1, 3187, 1300, 1, 3784211, 473045, 1, 2, 1, 1, 0,
    66, 3, 101130 ;

Is this expected and will it influence the output of yambo calculations?

2. also in ns.db1, I find that

Code: Select all

 ATOM_POS =
  37.91466, 18.93937, 14.17295,
  37.9147, 28.30377, 14.17295,
  37.91827, 23.62156, 14.17295,
  39.22874, 16.70244, 14.17295,
  39.22862, 30.54069, 14.17295,
  39.20577, 21.30762, 14.17295,
  39.20582, 25.9356, 14.17295,
  41.94077, 21.30762, 14.17295,
  41.94083, 25.93551, 14.17295,
  41.91821, 16.70251, 14.17295,
  41.91818, 30.54055, 14.17295,
  43.22827, 23.62155, 14.17295,
  43.23206, 18.93941, 14.17295,
  43.23197, 28.30378, 14.17295,
  35.8508, 18.94293, 14.17295,
  35.85075, 28.3001, 14.17295,
  35.85205, 23.62161, 14.17295,
  38.21434, 14.90753, 14.17295,
  38.21423, 32.33563, 14.17295,
  42.93272, 14.9076, 14.17295,
  42.93266, 32.33556, 14.17295,
  45.29449, 23.62154, 14.17295,
  45.29596, 18.94333, 14.17295,
  45.29597, 28.29987, 14.17295,
  0, 0, 0,
  0, 0, 0,
  0, 0, 0,
  0, 0, 0 ;

changes to

Code: Select all

 ATOM_POS =
  37.91466, 18.93937, 14.17295,
  37.9147, 28.30377, 14.17295,
  37.91827, 23.62156, 14.17295,
  39.22874, 16.70244, 14.17295,
  39.22862, 30.54069, 14.17295,
  39.20577, 21.30762, 14.17295,
  39.20582, 25.9356, 14.17295,
  41.94077, 21.30762, 14.17295,
  41.94083, 25.93551, 14.17295,
  41.91821, 16.70251, 14.17295,
  41.91818, 30.54055, 14.17295,
  43.22827, 23.62155, 14.17295,
  43.23206, 18.93941, 14.17295,
  43.23197, 28.30378, 14.17295,
  35.8508, 18.94293, 14.17295,
  35.85075, 28.3001, 14.17295,
  35.85205, 23.62161, 14.17295,
  38.21434, 14.90753, 14.17295,
  38.21423, 32.33563, 14.17295,
  42.93272, 14.9076, 14.17295,
  42.93266, 32.33556, 14.17295,
  45.29449, 23.62154, 14.17295,
  45.29596, 18.94333, 14.17295,
  45.29597, 28.29987, 14.17295,
  NaNf, 0, 0,
  0, 0, 0,
  0, 1.401298e-45, 0,
  0, 0, 0 ;

Maybe these 4 additional coordinates are not really initialized? Anyhow, what is their role? Are they used in the yambo calculation?

3. The values in the ns.kb_pp_pwscf_fragment_1 database are completely different (e.g. factor of 5)!
Before rev. 52, using my pseudopotential the numbers inside the database ns.kb_pp_pwscf_fragment_1 were basically random numbers. That problem was solved in rev. 52 and I checked that this problem has not been reintroduced in rev. 58, but still the numbers are now very different. Do I need to redo all my calculations that have been done with rev 52?

Thanks a lot for your help!

Best,
Leo

[Davide Sangalli]

Dear Leopold,
thanks for the feed-back. We have to check this problem.

I did a simple test on Silicon and I do not have these differences. But maybe my sistem is too simple.

Anyway for the first different number you see:
DIMENSIONS = 4672
DIMENSIONS = 2780

It is the "serial number". It is a random number which p2y "attachs" to every run and it is correct the it differs from run to run.
It is used to avoid, for example, that you mix the ns.db1 from one run with the ns.wf from another run

For the atomic coordinates and the ns.kb_pp_pwscf DBs I have to check, but I would think that, if there is an error, it is more likely to be in the rev58.
I would suggest use to use version 57. Is this one ok ?

In version 58 I hade to change many lines of code to fix another bug which was appearing for runs with a huge number of kpts making p2y crashing (it was just a problem with the numbering of units, so if you where not experiencing seg-fault your runs were not affected)
However, as always every time you fix one bug, especially if it requires many lines of coding, it is likely that you create more new bugs ...

Could you provide me an input file for pwscf which I can use to reproduce your problem?

Best,
Davide

[leoteo]

Dear Davide,

thanks a lot for your kind offer.

I have attached a sample input that reproduces the problems with the 4 "ghost atoms" as well as the different ns.kb_pp_pwscf_fragment_1 databases when converted with p2y -S -N (SVN rev. 52 vs rev. 58).

The cutoff is already ridiculously small, but you can reduce it further if you need to (it does not affect the problem).
The number of atoms, however, does affect the problem with the "ghost atoms". I first wanted to create a smaller example (benzene, i.e. 6C, 6H instead of 14C, 10H, using the same pseudopotentials and everything) and in the case of benzene, there are no "ghost atoms" in ns.db1 generated by p2y.
Note that I also checked the <IONS> section in the data-file.xml file generated by QE and it seems fine both for benzene and the attached example.

I hope it is not some stupid mistake of mine that I am unable to see..

Best,
Leo

[Davide Sangalli]

Dear Leopold,
I did some test with your input files.

First about the last four atomc coordinates

Maybe these 4 additional coordinates are not really initialized? Anyhow, what is their role? Are they used in the yambo calculation?

These are not used at all by yambo.
Simply, when writing the DBs, yambo creates a variable which hase size (3,n_atomic_species, max_atoms_per_species) for all the atomic positions.
In your case n_atomic_species=2 (C and H) and you have 14 C and 10 H, thus max_atoms_per_species=14.
Thus it allocates a variable of size (3,2,14) and writes it on disk. It is not very efficient maybe, but since the number of atoms is always a small number if compared to the g_vectors, the number of bands, kpts, etc ...

Finally for the kb_pp factors

The values in the ns.kb_pp_pwscf_fragment_1 database are completely different (e.g. factor of 5)!

the results of revision 52 were wrong. So in the calculations of the dipoles the non-local part of the pseudo was enanched by a factor 4.81124353.
The bug was corrected with the gpl revision=57. The bug was affecting the computation of the dipoles using pseudo-potentials with only one projector.

Sorry for that. Can you see visible differences in your results between the two revisions (52 / 57) ?

Best,
Davide

[leoteo]

Dear Davide,

thanks a lot for your explanations!

I checked the quasiparticle energies calculated from the two different databases and the differences all seem to be below 1meV.

Best,
Leo