Closed gitpeterwind closed 10 months ago
Thanks Peter!
How was it that we force it to use the latest mrcpp?
Note that the solvation tests fail now:
49 - reaction_operator (Failed)
60 - Li_solvent_effect (Failed)
The former is a unit test, the latter an integration test. For the latter it might be enough to regenerate the reference output:
60: JSON['output']['properties']['scf_energy']['E_next']....................................................................PASSED
60: JSON['output']['properties']['scf_energy']['E_el']: computed value (-7.09457290) does not match (-7.09458382) to atol=1e-06, rtol=1e-06 by difference (0.00001092).
60: JSON['output']['properties']['scf_energy']['Er_tot']: computed value (-0.06409434) does not match (-0.06408885) to atol=1e-06, rtol=1e-06 by difference (-0.00000550).
60: JSON['output']['properties']['scf_energy']['Er_el']: computed value (0.12807619) does not match (0.12806527) to atol=1e-06, rtol=1e-06 by difference (0.00001092).
60: JSON['output']['properties']['scf_energy']['Er_nuc']: computed value (-0.19217053) does not match (-0.19215412) to atol=1e-06, rtol=1e-06 by difference (-0.00001641).
This looks great @gitpeterwind! You made a lot of simplifications that I've been also making in #456 😄 For which system(s) have you been testing the memory footprint reductions? And what is the before and after consumption?
I've left some comments, especially about argument passing. Please have a look.
Actually @Gabrielgerez did most of the work. I mostly provided the function to multiply directly the orbitals with a representable function. (PS: I am in Oslo, and busy this week)
@robertodr @gitpeterwind Now I have fixed what was needed and updated the input parsing (since i removed a keyword) and tests. All tests should be passing now. Sorry for the wait as well, attempted a big refactor to try and shave off the last few gb and it took longer than expected, so i had to branch it off
Attention: 12 lines
in your changes are missing coverage. Please review.
Comparison is base (
70e9fbd
) 69.58% compared to head (516cc21
) 69.25%. Report is 20 commits behind head on master.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
LGTM but there's two comments @Gabrielgerez should chime in on before this can be merged. Also:
- One curiosity: How are you measuring the memory consumption?
- What are the final before-and-after ballpark numbers on how much memory is needed for a solvent calculation?
Im using the log file output from slurm in betzy an example for a HF water calculation before and after: before
Memory statistics, in GiB:
ID Alloc Usage
732516 968.0
732516.batch 242.0 20.0
732516.orted 726.0 57.5
after:
Memory statistics, in GiB:
ID Alloc Usage
732519 968.0
732519.batch 242.0 9.1
732519.orted 726.0 22.7
When testing we were using a PBE0 calculation, where the gain showed a bit more, but now I am doing some proper scaling calculations with different sizes.
LGTM but there's two comments @Gabrielgerez should chime in on before this can be merged. Also:
- One curiosity: How are you measuring the memory consumption?
- What are the final before-and-after ballpark numbers on how much memory is needed for a solvent calculation?
For the memory necessary for a solvent calculation, again an example of HF water gas phase
Memory statistics, in GiB:
ID Alloc Usage
732514 968.0
732514.batch 242.0 6.9
732514.orted 726.0 12.9
solvent (eps=2.0, default for everything else)
Memory statistics, in GiB:
ID Alloc Usage
732519 968.0
732519.batch 242.0 9.1
732519.orted 726.0 22.7
Looks very good! What is the difference between batch and orted rows?
Looks very good! What is the difference between batch and orted rows?
I was hoping @gitpeterwind could answer, I am assuming one is the memory used by the main process while the other is the shared one. The machine docs do not have much documentation on this, that I could easily find
Looks very good! What is the difference between batch and orted rows?
"Batch" is for the master compute node, while "orted" (Open Runtime Environment Daemon) is for the sum of all others compute nodes. Your run on 4 compute nodes , each of them has 242 GB available (3*242=726).
So the sum of the two is the estimate of the memory consumption, right? If yes, the cost of the solvent went from ~4x to ~1.6x the cost of the vacuum calculation. Impressive!
So the sum of the two is the estimate of the memory consumption, right?
Yes, but the most relevant is the memory usage of the most memory consuming compute-node (normally master): it does not help to have compute nodes that consume little memory, if one of the compute nodes needs more memory than available. (compute nodes can not use memory from other compute nodes)
Avoids memory consuming function trees, by using directly the analytical function. Note: requires the latest version of MRCPP Gabriel will test/polish before merge into master