-
Notifications
You must be signed in to change notification settings - Fork 62
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
How to manage multiple geometries? #1
Comments
I haven't really thought about this. What's the advantage to having a grid On Sun, Apr 26, 2015 at 1:33 AM, Jérémy Viau-Trudel <
Rick Muller |
Excellent comment. I'm asking myself this kind of design questions and I do not have a clean answer yet. I could give you more details about my view on this issue and the reason of my interest on it. But for now, it seems it is issue shared by the QC community. An interesting work have been done within the COST european initiatives and it have proposed a standard for QC data structures (at least for their storing and sharing). I recommend to have a look at this paper DOI: 10.1002/jcc.23492 . The Q5COST library were about defining single point data structure and D5COST (as far as I understand) is devoted to allow the manipulation of many geometries for Quantum Dynamics applications. |
Well, Jérémy I've got your idea. I think about using HDF5 format too. |
I don't know. I guess everyone in the QC field is doing this by some way or another... manually most of the time. It would probably be not so difficult to fetch basis set data from databases using python. BasisSet Exchange is a good source and it seems to be managed by NewChem. I'll ask them questions about basis set standards, Q5Cost integration and possible development of api binding their database. HDF5 is very easy in python, but I would prefer to work on a standard implementation that everyone could use. Respect. |
Ok. Basis set exchange database have nice and modern features: they use xml Schema and allow programmatic download from their database. |
But this is not related discussion is not related to the topic of this issue. I started a new issue #2. |
Jérémy why you create so many tickets? |
Vladimir. The reason I started a new issue is that your comment is not exactly answering my question. The Issues system is very useful for collaborative work and discussions, but it is not a simple forum. It provide tools to organise work and structure discussions, track ideas, etc... I do not want to spam any one, I just want to work in collaboration with you. If you are not interested by receiving these comments, you can unwatch the project. But as it is @rpmuller's project, I ask him is opinion about issues' usage. |
I don’t have any problems with people raising issues, either as official On Tuesday, May 5, 2015, Jérémy Viau-Trudel notifications@github.com
Rick Muller |
A lot of QuantumChemistry methods need to handle many geometries. But, as it is designed, pyquante2.geo.molecule can only be used with one geometry.
My question is: have you plan to extend geo.molecule?
It would be interesting to have an object geo.grid. From it, I will try to launch energy calculation in parallel with mpi4py. It can easily be done without any modification of piquant, but I think that for more complex applications, it would be interesting to have geo.grid embedded in geo.molecule and not the reverse.
What do you think of that idea and which implication would it have on other components of the program?
The text was updated successfully, but these errors were encountered: