Vasp-PLO converter does not produce correct projectors with two correlated shells

[merkelm]

When using more than one shell in the PLO converter and using projectors, there are a few things that seem incorrect with the resulting h5 archive.

Steps to Reproduce

I used the NiO tutorial from DFTTools as a minimal example.

1. I performed a Vasp calculation with the input files from the tutorial.
2. In plo.cfg from the tutorial, I changed HK to False, Shell 2/CORR to True and COMPLEMENT to False (complete plo.cfg: plo.cfg.txt)
3. I ran the converter with

   
   from triqs_dft_tools.converters.vasp import *
   import triqs_dft_tools.converters.plovasp.converter as plo_converter

plo_converter.generate_and_output_as_text('plo.cfg', vasp_dir='./') Converter = VaspConverter(filename = 'nio', proj_or_hk = 'hk') Converter.convert_dft_input()

**Expected behavior:** An h5 archive as output with projectors for two inequivalent, correlated shells.

**Actual behavior:** This h5 archive [nio.zip](https://github.com/TRIQS/dft_tools/files/10863575/nio.zip) as output with two problems:
- `corr_shells/0/sort` and `corr_shells/1/sort` are both 1, so they are tagged as symmetry-equivalent. Same applies to `shells`
- `proj_mat` only contains a 5x5 diagonal matrix as projectors on shell 1 but if I understand the structure correctly only zeros for shell 2. This does not happen when `COMPLEMENT` is True.

Of course, for NiO, changing back to the original plo.cfg from the tutorial avoids these problems. I am using this as a minimal example of a bug I found in LuNiO3 calculations, where it happens when the 4 Ni sites are split over two shells. Therefore, this does not have anything to do with the shells having different dimensions.

### Versions

I used commit 03aa19b of the unstable branch of dft_tools and Vasp 5.4.4.

[opeil]

There are two possibilities:

1. either something got broken in the intermediate text-file representation (*.plog1);

2. or det_shell_equivalence is not applied correctly to VASP input (this would be the first suspect, as a matter of fact).

Could you also attach the text file (*.plog1) for both the tutorial original case and for your modified input?

On Wed, Mar 1, 2023 at 6:20 PM merkelm @.***> wrote:

When using more than one shell in the PLO converter and using projectors, there are a few things that seem incorrect with the resulting h5 archive. Steps to Reproduce

I used the NiO tutorial from DFTTools as a minimal example.

1. I performed a Vasp calculation with the input files from the tutorial.
2. In plo.cfg from the tutorial, I changed HK to False, Shell 2/CORR to True and COMPLEMENT to False (complete plo.cfg: plo.cfg.txt https://github.com/TRIQS/dft_tools/files/10863532/plo.cfg.txt)
3. I ran the converter with

from triqs_dft_tools.converters.vasp import * import triqs_dft_tools.converters.plovasp.converter as plo_converter

plo_converter.generate_and_output_as_text('plo.cfg', vasp_dir='./') Converter = VaspConverter(filename = 'nio', proj_or_hk = 'hk') Converter.convert_dft_input()

Expected behavior: An h5 archive as output with projectors for two inequivalent, correlated shells.

Actual behavior: This h5 archive nio.zip https://github.com/TRIQS/dft_tools/files/10863575/nio.zip as output with two problems:

• corr_shells/0/sort and corr_shells/1/sort are both 1, so they are tagged as symmetry-equivalent. Same applies to shells
• proj_mat only contains a 5x5 diagonal matrix as projectors on shell 1 but if I understand the structure correctly only zeros for shell 2. This does not happen when COMPLEMENT is True.

Of course, for NiO, changing back to the original plo.cfg from the tutorial avoids these problems. I am using this as a minimal example of a bug I found in LuNiO3 calculations, where it happens when the 4 Ni sites are split over two shells. Therefore, this does not have anything to do with the shells having different dimensions. Versions

I used commit 03aa19b https://github.com/TRIQS/dft_tools/commit/03aa19b90d73eaa3f4b277fc2530fd42f4748860 of the unstable branch of dft_tools and Vasp 5.4.4.

— Reply to this email directly, view it on GitHub https://github.com/TRIQS/dft_tools/issues/235, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA2PU7RQDFGSMDCQ4T2HIS3WZ6APBANCNFSM6AAAAAAVMKUB64 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

--

Dr. Oleg E. Peil Senior Scientist Materials Center Leoben Forschung GmbH Roseggerstrasse 12 A-8700 Leoben Austria Tel :+43 3842 45922 45

[merkelm]

Thank you for your fast response! In nio.pg1.zip, I put the pg1 files

• nio.pg1_modcfg from the plo.cfg I attached to the original message
• nio.pg1_modcfg_complementtrue from the same plo.cfg but with COMPLEMENT set back to true
• nio.pg1_orig generate with the original cfg file from the tutorial

[opeil]

Thanks for the files. I see now that the intermediate representation in text files are correct. However, some of the index maps (shion_to_shell) in the VaspConverter are obviously incorrect, at least for the case of NiO when both shells are set as correlated. As the assignment of shion_to_shell has been modified (mostly by Malte) already twice since the original version it is difficult to say what was the motivation behind these changes. Extra complications come also from a feature introduced some time ago, which allows one to specify equivalence groups of ions beyond those determined by the space group (e.g., one can split 4 Ni ions into two inequivalent groups in the Pbnm unit cell).

In any case, I will try to make a set of tests specifically for the converter (most of the current tests are related to the initial preparation of projectors) to understand what kind of input data leads to the incorrect *.h5 file. Once this is clear, I will try to fix the issue with ion/shell index mapping.

As a side note, I have noticed that the convention for LOCPROJ has been changed in VASP 6.1.x. Now, one must provide a single LOCPROJ entry with a multiline string value. The current tutorial for NiO will not work as expected in the latest version of VASP.

On Thu, Mar 2, 2023 at 5:22 PM merkelm @.***> wrote:

Thank you for your fast response! In nio.pg1.zip https://github.com/TRIQS/dft_tools/files/10873442/nio.pg1.zip, I put the pg1 files

• nio.pg1_modcfg from the plo.cfg I attached to the original message
• nio.pg1_modcfg_complementtrue from the same plo.cfg but with COMPLEMENT set back to true
• nio.pg1_orig generate with the original cfg file from the tutorial

— Reply to this email directly, view it on GitHub https://github.com/TRIQS/dft_tools/issues/235#issuecomment-1452150898, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA2PU7XTLN7XGKABDHJCWYTW2DCN3ANCNFSM6AAAAAAVMKUB64 . You are receiving this because you commented.Message ID: @.***>

--

Dr. Oleg E. Peil Senior Scientist Materials Center Leoben Forschung GmbH Roseggerstrasse 12 A-8700 Leoben Austria Tel :+43 3842 45922 45

[the-hampel]

Thank you for looking into this Oleg. I believe I noticed the problem already earlier: https://github.com/TRIQS/maxent/issues/23#issuecomment-1047000732 reported by a different user. However, I never really went to the bottom of it. I think it shows itself as soon as one defines multiple shells. Then all shells have been marked as equivalent in the problem of the other user. Maybe that helps to track down the problem.

You don't need to correct the tutorials. I will do this at some point when I correct the CSC scheme in the tutorial.

[merkelm]

Thanks also from me for looking into it!

[opeil]

There are two possibilities how to fix the issue and I need an input at least from @the-hampel and @merkelm as users of the PLOVasp interface.

One part of the problem to correctly determine equivalence between correlated shells is related to an old convention as to what is the meaning of the property ion_sort of a correlated shell. Originally, it was introduced only to distinguish ions within a given shell. However, in the converter it is treated as an actual index of inequivalent ions and it is stored in corr_shells[i]['sort']. I can modify the generated values of ion_sort in two ways:

1. to make it contain the site index read from LOCPROJ, with equivalent sites having the same index (of a representative site);
2. the same as above but the indices will be transformed to start from 0 or 1 and having no gaps.

To clarify, let us consider an example of our favorite LuNiO3. Four Ni ions have site indices 5, 6, 7, 8. If we now group them as ([5, 6], [7, 8]) the array ion_sort will contain: in case 1 -- ([5, 5], [7, 7]), in case 2 -- ([0, 0], [1, 1]).

My question: Do you actually use these indices (corr_shells[i]['sort']) from the object corr_shells of group dft_input? If you do use them, do you use the continuity of indices (i.e., that for n ions you always expect indices 0, 1, .., n-1)? I just want to make sure, before I do any changes, that I do not break your scripts.

For my part, I can tell that I have never used these indices directly. Moreover, I was always generating inequivalent shells by hands in the DMFT script, never relying on the automatic subroutine of converter utils.

[the-hampel]

Hi Oleg, I believe that those indices are never actually used besides identifying a side and they are used inside of the blockstructure class to map things. I do believe the absolute number is not needed right now for anything. However, it was nice to check which atom of the POSCAR has been used. I could live with both solutions but slightly favor option 1. if not too complicated? Thanks.

[opeil]

Thanks for the feedback! Actually, option 1 is the easiest. Option 2 would require extra index transformation.

On Thu, Mar 23, 2023 at 6:03 PM Alexander Hampel @.***> wrote:

Hi Oleg, I believe that those indices are never actually used besides identifying a side and they are used inside of the blockstructure class to map things. I do believe the absolute number is not needed right now for anything. However, it was nice to check which atom of the POSCAR has been used. I could live with both solutions but slightly favor option 1. if not too complicated? Thanks.

— Reply to this email directly, view it on GitHub https://github.com/TRIQS/dft_tools/issues/235#issuecomment-1481557054, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA2PU7XTTW6TIIMJWWMYGJ3W5R65BANCNFSM6AAAAAAVMKUB64 . You are receiving this because you commented.Message ID: @.***>

--

Dr. Oleg E. Peil Senior Scientist Materials Center Leoben Forschung GmbH Roseggerstrasse 12 A-8700 Leoben Austria Tel :+43 3842 45922 45

[the-hampel]

should be fixed now with the merge of #237