-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generation of grids is slow #39
Comments
It takes 74 x 7 seconds? This is indeed slow. Can you post a full example? Then I can look where the code is sitting and how we can speed it up. I was anyway considering porting it to Rust. |
The code is exactly the same as above for the calculation. Outside the above for loop, I use the following details:
I created the arrays for coordinates from the following XYZ file:
PC: |
BTW I am really loving the flexibility of the library right now. By flexibility I mean
Therefore, if you do consider making it faster, I would request to keep the above things in mind. As speed is something that one often has to sacrifice to keep the above advantages. Similarly if you port it to rust, I hope you would still keep this library because it is one of a kind based on what I have seen. Thanks! |
I will look at this example and report back. Thanks for that. And indeed I will definitely keep the pip-installability in case I go for the rewrite. |
Here is the code in full:
|
And it's really nice to hear that you find the library useful. I am sure we will be able to solve the generation time problem. |
I confirm that this takes forever also on my side. I have a feeling for what it is (Becke partitioning) but need to do some digging in the code. But this is now the "code's fault", not your fault. |
Few years ago I used this to create big grids but maybe later I introduced something which made the Becke partitioning not scale well. Based on very quick tests the problem is neither the radial grid generation, nor the angular grid generation itself but probably this: numgrid/numgrid/becke_partitioning.cpp Lines 24 to 32 in 29f94b7
|
Thanks a lot for looking into it. Also, I noticed that the smaller grids generated using numgrid, compared to PySCF give similar results. Even when the grids are half the size or even smaller. I am not sure if this is a coincidence or an advantage of the used method. But it is a very welcome feature for me. I was also looking into parallelisation using Python, but don't seem to be getting somewhere with that. I will also try to play with the older code that you mention and see if I can see something. Thanks again! |
I am now able to parallelise the generation of grids. So basically the grids for different atoms are generated in parallel. For a Benzene dimer (C12H12) which took 20-21 seconds serially, I was able to get the computation time down to 9-10 seconds. I did the parallelisation using JOBLIB. If you want I can post an example. |
Long time ago I had this screening in: numgrid/numgrid/becke_partitioning.cpp Lines 55 to 60 in 29f94b7
Without this the Becke partitioning scales quadratically. I removed that check because it lead to errors for very diffuse basis sets. So I could try to put that back in but needs some testing so that it is a conservative estimate. |
That's interesting. Would it be possible to have an optional argument to turn this on and provide some cutoff? By default it can be off. And if the optional argument is provided it can be turned on for testing/experimenting purposes. I think C++ does support it. |
I was also thinking of re-enabling it with a very conservative default which can be adjusted in the function call. |
Also, I am not sure but what do you think about using pre-computed interatomic distances numgrid/numgrid/becke_partitioning.cpp Line 80 in 29f94b7
I saw that PySCF and HORTON both are doing something like this (precomputing): But I am not sure how much of an impact this is going to have. |
Similarly stuff like numgrid/numgrid/becke_partitioning.cpp Line 88 in 29f94b7
This and |
I will work on this in September but the next two weeks are packed with events so I have to park this a bit but I see no reason why this should not be super fast. We will get there. |
Good progress on porting the code to Rust and at the same time cleaning up some dusty corners. I will soon have it done (1-2 weeks?). |
@manassharma07 would love to hear your view on #40. |
Version 2.0.0 is out now and it should be a bit faster. Still, the bottleneck is the space partitioning and what I or somebody should do is to implement a more efficient space partitioning as suggested in #43. |
Thanks a lot! I could install it on a linux virtual machine and it works very well. Seems to be significantly faster. A big thank you! |
That is great to hear - thanks for feedback! More work upcoming soon. |
I will soon have the LKO and SSF partitioning schemes in place. Just need to do a bit more testing. These will significantly speed up grid generation. |
I was playing around with the library and noticed that for a 74 atom molecule with C and H atoms, the generation of grids is very slow.
I am using the following code:
The context creation takes a fraction of a second, however, the
numgrid.get_grid
method takes a lot of time around 7 seconds forradial_precision = 1.0e-10
Is this expected or I could do something better?
For example, I understand that for the same type of atoms, I could just create the context once. But that is hardly the dominant step, so I don't think it makes much of a difference.
If there is nothing wrong with how I am using it, then should I look for parallelization?
The text was updated successfully, but these errors were encountered: