Open moritzgubler opened 2 months ago
hei Moritz, could you add a quick description of how this differs from the Hellmann-Feynman calculation of the forces? Also, I have C++ code that:
I can share both if it's of interest.
I find i kind of usefule to be able to exchange the lebvedev file with something else and not have to recompile the code to test things. But if you like it more to avoid reading the file, I can also use your method.
What would be the purpose of the Leopardi points? are they more accurate than the lebvedev grids?
I sent you a small description of my method on zulip. I don't want to publish this yet.
I find i kind of usefule to be able to exchange the lebvedev file with something else and not have to recompile the code to test things. But if you like it more to avoid reading the file, I can also use your method.
Yes, of course. The approach is the same, since the grids are known beforehand. If you tabulate all of them, there's not much you can swap them with, as their structure is not shared (that I know of) with other grids on the sphere. I dislike reading files at runtime. It's Lebedev, not lebvedev, by the way.
What would be the purpose of the Leopardi points? are they more accurate than the lebvedev grids?
In terms of accuracy they're similar. They're easier to generate though, so you're not limited to a pre-tabulated set of points and weights.
I sent you a small description of my method on zulip. I don't want to publish this yet.
Thanks!
Can you send me the lebedev cpp library please you were talking about? I can also integrate that to avoid reading the file.
here you go https://github.com/robertodr/balls
Thanks, I integrated your library into my code.
Open shell calculations now also work, I still need to implement the GGA stress density (see my question on zulip) and make sure, that the forces are calculated using the hellmann-feynman theorem in an exact exchange calculation.
Attention: Patch coverage is 2.54735%
with 1492 lines
in your changes missing coverage. Please review.
Project coverage is 62.59%. Comparing base (
df39ee2
) to head (13b89d8
). Report is 2 commits behind head on master.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Hi @robertodr @ilfreddy I implemented now everything I wanted to, cleaned up to code and added a bit of documentation. The new method to calculate the forces now works for LDA and GGA functionals for both restricted and unrestricted calculations. The pulll request is now ready for review. Best, Moritz
I previously tested GGA calculations only for H2 where the forces where the forces were correct. In more complicated systems this is not the case. (LDA is always correct). I will look into it and let you know once I have solved the problem.
The GGA bug is fixed now, I forgot to add the divergence terms in the xc potential for the GGA case. They have been added now. MPI does not work anymore, it segfaults in the calculation of the kinetic stress. I suspect, that I try to access orbitals in an orbitalvector that are stored on another rank. @gitpeterwind Do you know what could be the problem?
I can recreate the error with this input:
world_prec = 1.0e-4
world_unit = bohr
WaveFunction {
method = blyp
restricted = false
}
Properties {
geometric_derivative = true
}
Forces {
method = "surface_integrals"
#method = 'hellmann_feynman'
surface_integral_precision = medium
}
Molecule {
$coords
H 0.86387418 -0.02789966 0.13501906
Li -0.44463806 -0.04858572 -0.04959119
$end
}
I start the simulation with:
mrchem --dryrun hli.inp
mpirun -np 4 mrchem.x hli.json
@moritzgubler would you mind adding also some testing to your code? According to the code coverage report, your patch is only marginally covered. Tests are essential to make sure the code does not get broken by others later on.
I added a test, is there a way to look at the codecov report?
This is my implementation of the idea I had of calculating forces with surface integrals. It works quite well and the forces are more accurate. Also, mrchem struggles to compute forces when the world precision is 1e-7 or smaller. Then it requires a lot of memory (more than 32 GB for a H2 molecule). This is not the case with my approach . Geometry optimizations seem to be reliable if the stopping criterion is chosen 10 * world_prec.
I have already put all the parameters into the parser, so it is quite simple to test and run my code (look for the section "- name: Forces" in the template.yaml input parser file).
At the moment, there is two things that need to be improved:
@stigrj Do you think my changes in the xc operator classes are fine.