possible problem with no_vvvv_integrals

[kgasperich]

I have attached some job output where I used different combinations of values for no_vvv_integrals, no_ivvv_integrals, and no_vvvv_integrals. Files are given names that indicate which of these are true and which are false {fff,fft,ftt,tft,ttt} (in the same order as given above).

I'm using the h2o geometry from h2o.xyz in the tests directory with the cc-pVDZ basis. I first run SCF, and then I print the bielec_mo integrals for the five different cases. I've created a python script to parse two sets of integrals (compare.py in the attached archive); for each integral that differs between the two sets, I print [i, j, k, l, int1, int2, int2/int1] (int1 is always from fff; int2 is from one of the other four sets of parameters).

When no_vvvv_integrals is set to true, some of the bielec_mo integrals are larger than they should be. When one or both of the other two parameters is also true, this changes to different integer values (always between 4x and 7x too large for the small test I did).

diff-fft.txt diff-ftt.txt diff-tft.txt diff-ttt.txt

The attachment below contains the input and some of the output from these jobs (along with output from a few fci calculations).

If you would like more information (compiler/flags or hardware), I can provide those.

I think the problem is in the provider for mo_bielec_integrals_in_map; I might take a closer look at this within the next few days.

no-vvvv-error.tar.gz

[TApplencourt]

Thanks for the report. Let's debug it together today

On Wed, Jun 6, 2018 at 7:00 PM, Kevin Gasperich notifications@github.com wrote:

I have attached some job output where I used different combinations of values for no_vvv_integrals, no_ivvv_integrals, and no_vvvv_integrals. Files are given names that indicate which of these are true and which are false {fff,fft,ftt,tft,ttt} (in the same order as given above).

I'm using the h2o geometry from h2o.xyz https://github.com/LCPQ/quantum_package/blob/master/tests/input/h2o.xyz in the tests directory with the cc-pVDZ basis. I first run SCF, and then I print the bielec_mo integrals for the five different cases. I've created a python script to parse two sets of integrals (compare.py in the attached archive); for each integral that differs between the two sets, I print [i, j, k, l, int1, int2, int2/int1] (int1 is always from fff; int2 is from one of the other four sets of parameters).

When no_vvvv_integrals is set to true, some of the bielec_mo integrals are larger than they should be. When one or both of the other two parameters is also true, this changes to different integer values (always between 4x and 7x too large for the small test I did).

diff-fft.txt https://github.com/LCPQ/quantum_package/files/2078466/diff-fft.txt diff-ftt.txt https://github.com/LCPQ/quantum_package/files/2078467/diff-ftt.txt diff-tft.txt https://github.com/LCPQ/quantum_package/files/2078468/diff-tft.txt diff-ttt.txt https://github.com/LCPQ/quantum_package/files/2078469/diff-ttt.txt

The attachment below contains the input and some of the output from these jobs (along with output from a few fci calculations).

If you would like more information (compiler/flags or hardware), I can provide those.

I think the problem is in the provider for mo_bielec_integrals_in_map; I might take a closer look at this within the next few days.

no-vvvv-error.tar.gz https://github.com/LCPQ/quantum_package/files/2078474/no-vvvv-error.tar.gz

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/LCPQ/quantum_package/issues/236, or mute the thread https://github.com/notifications/unsubscribe-auth/AGOP67h3OVyexK6LFrm_zuCizGZoUV2Mks5t6G0tgaJpZM4UditP .

[kgasperich]

It looks like the problem is not in the set of conditionals in the provider for mo_bielec_integrals_in_map, but rather in the way that the different bitmasks are generated. In the tests I've been running, the union of the sets of core, active, and inactive MOs has some overlap with the set of virtual MOs (I didn't use qp_set_mo_class for any of these, I just used qp_create_ezfio_from_xyz and then ran an SCF calculation). If these sets are disjoint, then everything should be okay. I haven't looked into the default behavior for choosing the sets of core, active, inactive, and virtual MOs, but it seems that something should be added to the code to ensure that these sets do not overlap (or if they are allowed to overlap, then the set of conditionals in the provider for mo_bielec_integrals_in_map should be changed)

[scemama]

Hi Kevin,

Indeed we assume that the bit masks are always valid when we read them from the EZFIO. This is why we created the qp_set_mo_class tool. A MO can belong to only one class, so the sets are disjoint. We should put a comment in the code.

Thanks for the report!