Closed jvtrudel closed 5 years ago
I haven't really thought about this. What's the advantage to having a grid object to, for example, just keeping a list of geometries?
On Sun, Apr 26, 2015 at 1:33 AM, Jérémy Viau-Trudel < notifications@github.com> wrote:
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?
— Reply to this email directly or view it on GitHub https://github.com/rpmuller/pyquante2/issues/1.
Rick Muller rpmuller@gmail.com 505-750-7557
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. But can you answer my question first. Is it possible to download Basis Set Database in HDF5 format or anyone try to convert it to? http://www.nwchem-sw.org/index.php/Special:AWCforum/st/id1493/Basis_Set_Database_in_HDF5_forma....html With respect, Vladimir.
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. jvtrudel
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? If you have any ideas on how to improve the PyQuante2, you can fork it and realize your desires there, otherwise, I consider your requests as spam.
Vladimir. I do have a fork on which I work an realize my tests. Thanks for the advice.
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 issues or as email messages. However, I’m generally pretty slow to respond to these issues (it has been a while since quantum chemistry was a regular part of my job), and people may prefer to simply fork the code to implement their own changes.
On Tuesday, May 5, 2015, Jérémy Viau-Trudel notifications@github.com wrote:
Vladimir. I do have a fork on which I work an realize my tests. Thanks for the advice.
The reason I started a new issue is that your question is not to my question. The Issues system is very useful for collaborative work and discussion, 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.
— Reply to this email directly or view it on GitHub.< https://ci6.googleusercontent.com/proxy/d29f2YusFLiwLs80Ip4upbiY5fchkac9ot4hJLHZxE5v6vVl7TGhHZhxbKloafXiVgCSs-k0P0IqQiVJtjKPNf1qyelpRk6eOQK8PB_jYghivcBW9HhyKqRtRTxNoctYNuwjkj0Ds2v5hfPA27RgHXc_OjuAzw=s0-d-e1-ft#https://github.com/notifications/beacon/AAchstow1hGNYU7fXblfnQYCSCt96mG_ks5oGJuWgaJpZM4EI5LK.gif
Rick Muller rpmuller@gmail.com 505-750-7557
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?