Skip to content
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

6-dimensional grids #17

Open
PaulWAyers opened this issue Jan 23, 2019 · 3 comments
Open

6-dimensional grids #17

PaulWAyers opened this issue Jan 23, 2019 · 3 comments
Assignees
Labels
low-priority Low Priority Issue

Comments

@PaulWAyers
Copy link
Member

6-dimension (double-molecular grid) for brute-force integration of Coulomb-like integrals. Depending on structure, promolecular tricks specific to this case may go here or may go somewhere else....

@FarnazH FarnazH added this to the release milestone May 14, 2021
@tczorro tczorro removed this from the release milestone Jul 16, 2021
@PaulWAyers
Copy link
Member Author

There was a (very old) pull request on this. Probably need to redo it.
#53

@PaulWAyers
Copy link
Member Author

@sanchezw17 will need this for his project, together with the extensions to 9- and 12- dimensions.

@PaulWAyers
Copy link
Member Author

From @marco-2023:
"The idea of these double/triple/quadruple grids is to integrate 6(9,12)-dimensional functions. Should these grids support that the integration intervals be different (for example for finding the classic coulomb repulsion of two different electron clouds) or they will be used only for integrals like the coulomb repulsion of an electron cloud with itself (the integration interval is the same). The idea is that the second case only needs to store a grid but the first case will need to store two (three or four) grids inside the class."

This is a good point. There are really two cases. One is where the grid can be duplicated. In such a case, one merely stores a single 3D grid.

The second case is where the grid cannot be duplicated; in that case one needs to store 4 different grids. It could easily be that one needs a different local grid for each set of 3 dimensions, but the local grid is constructed from the full 3D grid, so this doesn't change things much.

I'm not sure the right strategy, honestly. One could using is or dictionaries set it up so that a single grid looks like multiple grids when they are distinct, but not otherwise. However, $3k$ dimensional grids where $k$ is small, just storing the extra grid (not the full $3k$-dimensional grid, which is absurd, but all the underlying 3-dimensional grids) only increases memory requirements linearly, and might not be exceptionally problematic.

@FarnazH FarnazH added the low-priority Low Priority Issue label Nov 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
low-priority Low Priority Issue
Projects
None yet
Development

No branches or pull requests

5 participants