MSD arbitrary species input #2935

camelto2 · 2021-02-18T19:53:49Z

Proposed changes

This PR generalizes the multi-slater build path. Previously, everything was hard wired to have alpha and beta electron species. The PR adds a new build path that can handle any number of fermion species to occupy the multi slater determinants. This partially addresses #2698 in that you could now use only "alpha" electrons (useful for spinors) or additional species for other applications.

essentially, the input (if you want variable number of species) becomes
<multidetermiant fast="yes" optimize="no" spo_0="name0" spo_1="name1" ... spo_(N-1)="nameN-1">
where the number of species is determined by the particle set.

and (in the xml example) a similarly modified det list

and the CI specifcation

The changes are similar for the hdf5 input style.

This keeps all backwards compatibility, so all current unit tests/input will continue to work.

What type(s) of changes does this code introduce?

New feature

Does this introduce a breaking change?

No.
The new input style works and preserves the previous approach so all previous calculations/formats behave as expected. However, there does need to be an additional PR to properly generalize the MultiSlaterDeterminantFast evaluation routines to handle arbitrary sum_i c_i x (an arbitrary product of determinants). See MSD arbitrary species evaluation (1/N) #2947 which addresses the changes necessary for MultiSlaterDeterminantFast.

What systems has this change been tested on?

My workstation

Checklist

Yes. This PR is up to date with current the current state of 'develop'
Yes. Code added or changed in the PR has been clang-formatted
Yes. This PR adds tests to cover any new code, or to catch a bug that is being fixed
No. Documentation has been added (if appropriate)

need to generalize readDetList in each case

…ecies_input

qmc-robot · 2021-02-18T19:54:33Z

Can one of the admins verify this patch?

ye-luo

Hopefully my reaction is not totally a surprise.

Once Spin-orbit input logic simplification #2735 is solved
I don't see why we need a new input tag ngroups. I mean ngroups can be figured out by query the electron particle set.
Also the old builder code-path should converge with the new code path, convince me if you really think it is needed to keep two versions. It seems the new code is a good move but we need to kill the old one. Also need input tests like test_spo_collection_input_LCAO_xml.cpp and test_spo_collection_input_MSD_LCAO_h5.cpp.

camelto2 · 2021-02-18T20:39:26Z

Hopefully my reaction is not totally a surprise.

Once Spin-orbit input logic simplification #2735 is solved
I don't see why we need a new input tag ngroups. I mean ngroups can be figured out by query the electron particle set.

Sure that can be done. I was essentially just doing a first pass to get some comments.

Also the old builder code-path should converge with the new code path, convince me if you really think it is needed to keep two versions. It seems the new code is a good move but we need to kill the old one. Also need input tests like test_spo_collection_input_LCAO_xml.cpp and test_spo_collection_input_MSD_LCAO_h5.cpp.

I don't think we need to support both paths once the evaluation and everything is cleaned up. I separated everything for now just to make sure I didn't break anything that currently worked.

I will add unit tests once the input style is settled

ye-luo · 2021-02-18T20:46:34Z

@camelto2 I think we don't need to wait for the fix on the evaluation side, as long as the generic input parsing can support the legacy parsing, then it is good enough for merging with some safeguard.
our input class do support multiple tags mapped to the same variable.
mparam.add(occ, "occ1") which is handled by the loop
mparam.add(occ, "occ_up") which can be added for backward compatibility.

camelto2 · 2021-02-18T20:49:25Z

@camelto2 I think we don't need to wait for the fix on the evaluation side, as long as the generic input parsing can support the legacy parsing, then it is good enough for merging with some safeguard.
our input class do support multiple tags mapped to the same variable.
mparam.add(occ, "occ1") which is handled by the loop
mparam.add(occ, "occ_up") which can be added for backward compatibility.

Ahh, I didn't think about that. I can update that accordingly to take care of this backward compatibility issue

ye-luo · 2021-02-18T20:53:03Z

Also ParticleSet::groups() returns how many kinds of quantum particles are there.

…SDFast, allow backwards compatibility input

camelto2 · 2021-02-18T21:53:19Z

I removed the need for separate build paths for the MSD fast algorithm. In cases where the number of species is two, I also allow for backwards compatibility. For example, in the hdf5 for two particle species, most hdf5 files will have "CI_Alpha" "CI_Beta". So if reading CI_0, CI_1 fails, it tries CI_Alpha and CI_Beta. Same in the xml path.

I still have overloaded readDetList and readDetListH5, which is used for the legacy all_determinants algorithm, but that can be changed as well using the newer builder functions. Updating that now

camelto2 · 2021-02-22T19:49:45Z

I added a unit test for the xml style MSD input, with an arbitrary number particle species to make sure everything in constructed correctly. I also removed the need for overloaded readDetList and readDetListH5 so that we can reduce the amount of basically redundant code. Backwards compatibility is retained for both MultiSlaterDeterminant and MultiSlaterDeterminantFast.

ye-luo

Great simplification. Seems only minor issues left.

src/QMCWaveFunctions/Fermion/SlaterDetBuilder.cpp

ye-luo · 2021-02-22T22:13:20Z

src/QMCWaveFunctions/Fermion/SlaterDetBuilder.cpp

-        app_error() << "In SlaterDetBuilder: SPOSet \"" << spo_beta_name
-                    << "\" is not found. Expected for MultiSlaterDeterminant.\n";
-        abort();
+        spos[grp] = sposet_builder_factory_.getSPOSet(spoNames[grp]);


The pointer return from getSPOSet should be treated as a reference. It was kept pointer for checking nullptr. Please assign the value to a temporal pointer variable. In the current way, the SPOSet actually got destroyed when you reset the smart pointer.

I guess I'm confused as to what you mean. The smart pointer spo_clones[grp] calls reset, but the argument is spos[grp]->makeClone(). So the spo_clones[grp] should take ownership of the pointer being returned by makeClone(), not taking ownership of spos[grp] itself. So I don't see how the original ptr returned by getSPOSet (spos[grp]) gets destroyed.

reset() first calls delete on the previously stored pointer before taking the new one. This is not desired.

Sure, but spo_clones[grp] was initially a nullptr, so it wouldn't actually call the delete. I guess reset implies that it was storing something before, so it is not as clear as it could be. I changed it to be a bit more clear hopefully.

I was confused by spos and spo_clones. Could you remove spos and store the return of sposet_builder_factory_.getSPOSet in spo_tmp for nullptr check locally.

spo_clones.emplace_back(spo_tmp->makeClone());

should be OK.

src/QMCWaveFunctions/Fermion/SlaterDetBuilder.cpp

ye-luo · 2021-02-23T18:57:19Z

deterministic-unit_test_wavefunction_sposet fails now.

ye-luo

All look good to me.

ye-luo · 2021-02-24T06:32:20Z

Okay to test

ye-luo · 2021-02-25T13:14:14Z

https://cdash.qmcpack.org/CDash/viewTest.php?onlydelta&buildid=189182 failures from last night.

camelto2 added 8 commits February 17, 2021 14:15

multislater to allow arbitrary particle groups

ac8075e

allow for old input for the time being

6992a4e

generalize createMSDFast

68936f6

need to generalize readDetList in each case

readDetList generalized

469aa98

readDetListH5

70874a0

Properly guard against alpha,beta input style

f78c10e

remove redundant if statement

009b044

Merge remote-tracking branch 'upstream/develop' into MSD_arbitrary_sp…

5e4a9b7

…ecies_input

camelto2 requested a review from anbenali February 18, 2021 19:53

ye-luo requested changes Feb 18, 2021

View reviewed changes

remove nGroups reading from input. Remove separate paths from createM…

7f77688

…SDFast, allow backwards compatibility input

camelto2 added 2 commits February 22, 2021 11:31

add unit test for arbitrary number of MSD species

ed5aec6

Remove need for overloaded readDetList and readDetListH5

acf14ba

ye-luo reviewed Feb 22, 2021

View reviewed changes

camelto2 added 2 commits February 22, 2021 15:23

nGroups to const

2463b18

change abort to barrier_and_abort

d0d528e

shivupa mentioned this pull request Feb 23, 2021

MSD arbitrary species evaluation (1/N) #2947

Merged

change spo_clones

5b9fcb4

camelto2 changed the title ~~[WIP] MSD arbitrary species input~~ MSD arbitrary species input Feb 23, 2021

camelto2 added 3 commits February 23, 2021 12:13

remove spos vector

8c0bf87

fix unit test to work for real build

5ebface

change unit test and CI coeff parsing in readDetList

321b596

ye-luo approved these changes Feb 24, 2021

View reviewed changes

Merge branch 'develop' into MSD_arbitrary_species_input

f037f2a

ye-luo merged commit 63fb63d into QMCPACK:develop Feb 24, 2021

camelto2 deleted the MSD_arbitrary_species_input branch September 12, 2022 18:21

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MSD arbitrary species input #2935

MSD arbitrary species input #2935

camelto2 commented Feb 18, 2021 •

edited

Loading

qmc-robot commented Feb 18, 2021

ye-luo left a comment •

edited

Loading

camelto2 commented Feb 18, 2021 •

edited

Loading

ye-luo commented Feb 18, 2021

camelto2 commented Feb 18, 2021

ye-luo commented Feb 18, 2021

camelto2 commented Feb 18, 2021

camelto2 commented Feb 22, 2021 •

edited

Loading

ye-luo left a comment

ye-luo Feb 22, 2021

camelto2 Feb 22, 2021

ye-luo Feb 22, 2021 •

edited

Loading

camelto2 Feb 23, 2021 •

edited

Loading

ye-luo Feb 23, 2021

camelto2 Feb 23, 2021

ye-luo commented Feb 23, 2021

ye-luo left a comment

ye-luo commented Feb 24, 2021

ye-luo commented Feb 25, 2021

MSD arbitrary species input #2935

MSD arbitrary species input #2935

Conversation

camelto2 commented Feb 18, 2021 • edited Loading

Proposed changes

What type(s) of changes does this code introduce?

Does this introduce a breaking change?

What systems has this change been tested on?

Checklist

qmc-robot commented Feb 18, 2021

ye-luo left a comment • edited Loading

Choose a reason for hiding this comment

camelto2 commented Feb 18, 2021 • edited Loading

ye-luo commented Feb 18, 2021

camelto2 commented Feb 18, 2021

ye-luo commented Feb 18, 2021

camelto2 commented Feb 18, 2021

camelto2 commented Feb 22, 2021 • edited Loading

ye-luo left a comment

Choose a reason for hiding this comment

ye-luo Feb 22, 2021

Choose a reason for hiding this comment

camelto2 Feb 22, 2021

Choose a reason for hiding this comment

ye-luo Feb 22, 2021 • edited Loading

Choose a reason for hiding this comment

camelto2 Feb 23, 2021 • edited Loading

Choose a reason for hiding this comment

ye-luo Feb 23, 2021

Choose a reason for hiding this comment

camelto2 Feb 23, 2021

Choose a reason for hiding this comment

ye-luo commented Feb 23, 2021

ye-luo left a comment

Choose a reason for hiding this comment

ye-luo commented Feb 24, 2021

ye-luo commented Feb 25, 2021

camelto2 commented Feb 18, 2021 •

edited

Loading

ye-luo left a comment •

edited

Loading

camelto2 commented Feb 18, 2021 •

edited

Loading

camelto2 commented Feb 22, 2021 •

edited

Loading

ye-luo Feb 22, 2021 •

edited

Loading

camelto2 Feb 23, 2021 •

edited

Loading