LCAO Calculation with 0 down-spin electron - Seg fault

[anbenali]

When using ECP, Cases like Na, Li or other elements end up with one electron only in the valence. Normal converter and all attempts to remove the down determinant lead to a segmentation fault or an error in the LCAO builder. Does anyone remember/know what is the "trick" to get these systems to run properly.

[prckent]

Just to confirm: you have no issue with the converter(s), only QMCPACK?

There should be no trick needed of course - it is totally reasonable to run a single electron of "either" spin, but probably this is a corner case we need to check.

Do you get a SEGV with no jastrow?

[ye-luo]

Please provide an reproduce of this issue. Just attach files here.

[anbenali]

Yes. Converter generates correct file (in the sens that it avoids generating 2BJ and 3Body J and puts the size of the down determinant to 0 but I get a segfault when running qmcpack. This is definetly a corner case but quite annoying for isolated atoms such as Li Na or H (even if I never run H).

[prckent]

It is a bug, possibly several.

[anbenali]

Na.tar.gz

[ye-luo]

A quick investigation shows multiple breakage in the code.

[ye-luo]

To support systems with electrons all in one kind of spin. The converter writes the electron particleset with size 0 of down spin electron and a determinant of size 0.

0. Currently, the code complains that the number of orbitals doesn't meet the requirement >0.
1. After bypassing the check and allows 0, I got a segmentation fault. Because, the code expect two determinants based on the number of groups (2) in the particleset but only one was generated. The down electron determinant was skipped
2. Then remove the return and got an error in the delayed update input check. default delay rank is 1 and it doesn't meet the requirement [1, number of electrons].
3. After bypassing the check, I got an MKL error that dimension input of 0 is not acceptable by MKL.
4. Should I continue putting tons if(>0) in the source code?

Change my strategy.

1. Remove the 0 size down spin in the particleset of input.
2. Remove the 0 size down spin determinant in the determinantset of input.
3. Viva. I got the right result.

So in theory, there are two ways to support this case. One doesn't mention the second spin at all. The other one fakes the second spin with size 0. If we want to fix this feature, we should stop allowing the second way.

If we decide to stop user input if the sizes are 0. We will need to protect all the converters. I think this is doable. However, it is not clear to me how to deal with multi determinant. I believe the current multi-det code never worked with system with only 1 kind of spin.

[prckent]

Thanks for looking at this. Updating the converters seems straightforward and, equally important, maintainable.

For the main application, not mentioning the down spin determinant at all in the inputs is preferable since it is cleaner from the user perspective, and we should need very few if (n>0) checks throughout the code. Aborting if a zero size determinant is specified in the input is straightforward.

Running a multidet calculation with only electrons of one spin present seems like a case we don't need to worry about immediately. If the multidet code has problems, make a follow-up issue. Logically it shouldn't be too hard to fix (...), but I think it likely that other more important parts of the code could have troubles, e.g. in the optimizers.