20.10.2010, 18:00, “Eric Brown” eric.c.brown@mac.com:
I see there are computations in libavogadro/src/extensions/qtaim too.
It would be OK if everything was in libavogadro/src/extensions/qtaim, but you shouldn’t split up
computations
The computations in the extension directory are the actual QTAIM calculations, the ones in the libavogadro are because nuclear critical points and bond critical points are mimics of the atom and bond classes, and then there is the engine because I need to display the molecular graphs using an engine (originally a mimic of BSDY).
The libavogadro part will be cut out once the QTAIM results are coded up as Properties. Do you think that everything should be put in the qtaim extensions directory?
If you put something into libavogadro, you make it a part of libbavogadro public API. This means that your
code should be well-documented and potentially reusable by other developers. You also will not be able
to break this API (e.g., remove or rename methods) in 1.x series
If you think your code deserves to be in libavogadro (why not?) I think it would be better to separate it into module,
like libAvogadroQTAIM - that library will be loaded into memory only when it is needed.
–
Regards,
Konstantin
On Oct 20, 2010, at 10:18 AM, Konstantin Tokarev wrote:
20.10.2010, 18:00, “Eric Brown” eric.c.brown@mac.com:
I see there are computations in libavogadro/src/extensions/qtaim too.
It would be OK if everything was in libavogadro/src/extensions/qtaim, but you shouldn’t split up
computations
The computations in the extension directory are the actual QTAIM calculations, the ones in the libavogadro are because nuclear critical points and bond critical points are mimics of the atom and bond classes, and then there is the engine because I need to display the molecular graphs using an engine (originally a mimic of BSDY).
The libavogadro part will be cut out once the QTAIM results are coded up as Properties. Do you think that everything should be put in the qtaim extensions directory?
If you put something into libavogadro, you make it a part of libbavogadro public API. This means that your
code should be well-documented and potentially reusable by other developers. You also will not be able
to break this API (e.g., remove or rename methods) in 1.x series
If you think your code deserves to be in libavogadro (why not?) I think it would be better to separate it into module,
like libAvogadroQTAIM - that library will be loaded into memory only when it is needed.
We already spoke about this, and decided to keep it out of the public API. It is in the process of being migrated, and will have more time to mature. It would be good to put it into a module, and we have been looking at how best to fit this together with other parts of Avogadro such as the quantum calculation code.
Marcus