11.11.2010, 00:39, “Geoffrey Hutchison” geoff.hutchison@gmail.com:
On Nov 10, 2010, at 4:34 PM, Konstantin Tokarev wrote:
I think we should create a tag (e.g., 1.1.beta) and make build for all platforms
from this tag
I vote to just call it 1.1.0, tag this tomorrow perhaps? We can add big “WARNING, not STABLE” signs, but that was always true of 0.9 and previous releases too.
I think we’d better released 1.1.0 as RC-grade and than stabilize it in 1.1.1 or 1.1.2.
If we release buggy 1.1.0, it will be included into Linux distributions instead of 1.0.x
branch, and people will think we are losing stability.
–
Regards,
Konstantin
11.11.2010, 00:39, “Geoffrey Hutchison” geoff.hutchison@gmail.com:
On Nov 10, 2010, at 4:34 PM, Konstantin Tokarev wrote:
I think we should create a tag (e.g., 1.1.beta) and make build for all platforms
from this tag
I vote to just call it 1.1.0, tag this tomorrow perhaps?
This would go if we made a tag every two weeks, like Wine 
But if you think it’s better, I don’t insist on anything
We can add big “WARNING, not STABLE” signs, but that was always true of 0.9
and previous releases too.
I have some bad memories about 0.9.x, Avogadro crashed from bad glance those days
And distros included 0.9.x instead of certainly more stable 0.8.1
–
Regards,
Konstantin
On Wed, Nov 10, 2010 at 3:03 PM, Louis Ricard
louis.ricard@polytechnique.edu wrote:
Hi David.
I think you should make an official post of this installer on the Avogadro
official site. I feel certain that others gave it a try and I am aware that
anyone may have biases in testing (preferred options …), but overall
my biases worked, not meaning that I made extensive tests. This can
only come from a larger community, being aware that “bugs” are often
missusages.
I agree, it is about time for another release cycle.
It might be a good idea to develop a test suite for Avo. Not so simple
to implement.
There are a few test cases written to test the core of avogadro, but
we definitely do need more.
Best wishes to Geoff and you for your nearing meeting,
Thanks I’m looking forward to it, it sounds like it will be a
great conference.
Dave
On Wed, Nov 10, 2010 at 4:39 PM, Geoffrey Hutchison
geoff.hutchison@gmail.com wrote:
On Nov 10, 2010, at 4:34 PM, Konstantin Tokarev wrote:
I think we should create a tag (e.g., 1.1.beta) and make build for all platforms
from this tag
I vote to just call it 1.1.0, tag this tomorrow perhaps? We can add big “WARNING, not STABLE” signs, but that was always true of 0.9 and previous releases too.
I’d like to wait until we get the QTAIM patches in before we push out
an RC. This is a popular topic right now and it’d be good to get some
early feedback on Eric’s implementation. I still need to review some
of the patches myself – let’s make this a priority, then start an RC
cycle. IIRC, the QTAIM stuff is finished from a functional standpoint,
and all that’s left is some cleanup/documentation? This is my busiest
week of the semester between TA work and writing the tutorials, but
after the conference I should be able to finish reviewing the rest of
the QTAIM patches.
Dave
11.11.2010, 17:12, “David Lonie” loniedavid@gmail.com:
On Wed, Nov 10, 2010 at 4:39 PM, Geoffrey Hutchison
geoff.hutchison@gmail.com; wrote:
On Nov 10, 2010, at 4:34 PM, Konstantin Tokarev wrote:
I think we should create a tag (e.g., 1.1.beta) and make build for all platforms
from this tag
I vote to just call it 1.1.0, tag this tomorrow perhaps? We can add big “WARNING, not STABLE” signs, but that was always true of 0.9 and previous releases too.
I’d like to wait until we get the QTAIM patches in before we push out
an RC. This is a popular topic right now and it’d be good to get some
early feedback on Eric’s implementation. I still need to review some
of the patches myself – let’s make this a priority, then start an RC
cycle. IIRC, the QTAIM stuff is finished from a functional standpoint,
and all that’s left is some cleanup/documentation? This is my busiest
week of the semester between TA work and writing the tutorials, but
after the conference I should be able to finish reviewing the rest of
the QTAIM patches.
I’ve found that most of plugins are transferable between 1.0 and master, even if
compiled against master. So why it’s necessary to synchronize QTAIM releases
with Avogadro releases?
–
Regards,
Konstantin
11.11.2010, 17:24, “Konstantin Tokarev” annulen@yandex.ru:
11.11.2010, 17:12, “David Lonie” loniedavid@gmail.com;:
On Wed, Nov 10, 2010 at 4:39 PM, Geoffrey Hutchison
geoff.hutchison@gmail.com;; wrote:
On Nov 10, 2010, at 4:34 PM, Konstantin Tokarev wrote:
I think we should create a tag (e.g., 1.1.beta) and make build for all platforms
from this tag
I vote to just call it 1.1.0, tag this tomorrow perhaps? We can add big “WARNING, not STABLE” signs, but that was always true of 0.9 and previous releases too.
I’d like to wait until we get the QTAIM patches in before we push out
an RC. This is a popular topic right now and it’d be good to get some
early feedback on Eric’s implementation. I still need to review some
of the patches myself – let’s make this a priority, then start an RC
cycle. IIRC, the QTAIM stuff is finished from a functional standpoint,
and all that’s left is some cleanup/documentation? This is my busiest
week of the semester between TA work and writing the tutorials, but
after the conference I should be able to finish reviewing the rest of
the QTAIM patches.
I’ve found that most of plugins are transferable between 1.0 and master, even if
compiled against master. So why it’s necessary to synchronize QTAIM releases
with Avogadro releases?
I’ve checked QTAIM specifically - it’s binary compatible with 1.0
Incompatible are:
orbitalextension.so
pythonterminal.so (master version needs DockExtension, but it’s the only change after 1.0)
smartscolor.so
–
Regards,
Konstantin
On Nov 11, 2010, at 8:30 AM, Konstantin Tokarev wrote:
11.11.2010, 17:24, “Konstantin Tokarev” annulen@yandex.ru:
11.11.2010, 17:12, “David Lonie” loniedavid@gmail.com;:
On Wed, Nov 10, 2010 at 4:39 PM, Geoffrey Hutchison
geoff.hutchison@gmail.com;; wrote:
On Nov 10, 2010, at 4:34 PM, Konstantin Tokarev wrote:
I think we should create a tag (e.g., 1.1.beta) and make build for all platforms
from this tag
I vote to just call it 1.1.0, tag this tomorrow perhaps? We can add big “WARNING, not STABLE” signs, but that was always true of 0.9 and previous releases too.
I’d like to wait until we get the QTAIM patches in before we push out
an RC. This is a popular topic right now and it’d be good to get some
early feedback on Eric’s implementation. I still need to review some
of the patches myself – let’s make this a priority, then start an RC
cycle. IIRC, the QTAIM stuff is finished from a functional standpoint,
and all that’s left is some cleanup/documentation? This is my busiest
week of the semester between TA work and writing the tutorials, but
after the conference I should be able to finish reviewing the rest of
the QTAIM patches.
I’ve found that most of plugins are transferable between 1.0 and master, even if
compiled against master. So why it’s necessary to synchronize QTAIM releases
with Avogadro releases?
I’ve checked QTAIM specifically - it’s binary compatible with 1.0
Incompatible are:
orbitalextension.so
pythonterminal.so (master version needs DockExtension, but it’s the only change after 1.0)
smartscolor.so
I don’t know exactly what this means, but I think that it good news for the QTAIM extension.
The QTAIM code is probably a trainwreck by Avogadro standards, but I thought that it was best to get it all out so that everyone could see that I was serious about making something that worked. What works now, and I think is robust:
- Its GPL
- Its graphical
- All algorithms are QtConcurrent!!! I run on a 12-core Mac Pro.
- ODE integrator is adaptive and automatically switches between stiff and non-stiff (LSODA)
- Integrator is Adaptive and converges on accuracy (not relative).
- Based on the (orthodox) Bader Group style of QTAIM algorithms.
Molecular Graphs (bonding drawn by QTAIM without bias)
*Nuclear and Bond Critical Points
*Curvaceous Bond Paths and different styles for covalent vs. non-covalent (solid vs. dashed)
*framework for Ring and Cage is there, too. I wish someone might help me with DAGs. This is probably the best way to go, although the Lone Pair approach, a bunch of initial points on a grid, also works.
Lone Pairs
This is important for chemical interpretation of of electronic structure and its reactivity. Lone pairs are local surplus of electron density, and these hook up with corresponding depletion of electron density. All this is implemented.
Delineation and Integration over Atomic Basins
- Fully Adaptive Algorithms
- Three types of integration:
** theta,phi and r done separately
** r,theta,phi
** x,y,z
- All single-basin properties (e.g. charge, volume, KE and PE) can be done. two-basin properties (very expensive) can be done by nesting another set of integrations inside the existing integrations.
Accuracy down to 0.01 au of charge, but may be able to go more.- Easy to do Surface Properties (only function of theta,phi).
Best
Eric
11.11.2010, 17:56, “Eric Brown” brown@brown.chem.luc.edu:
On Nov 11, 2010, at 8:30 AM, Konstantin Tokarev wrote:
11.11.2010, 17:24, “Konstantin Tokarev” annulen@yandex.ru;:
11.11.2010, 17:12, “David Lonie” loniedavid@gmail.com;;:
On Wed, Nov 10, 2010 at 4:39 PM, Geoffrey Hutchison
geoff.hutchison@gmail.com;;; wrote:
On Nov 10, 2010, at 4:34 PM, Konstantin Tokarev wrote:
I think we should create a tag (e.g., 1.1.beta) and make build for all platforms
from this tag
I vote to just call it 1.1.0, tag this tomorrow perhaps? We can add big “WARNING, not STABLE” signs, but that was always true of 0.9 and previous releases too.
I’d like to wait until we get the QTAIM patches in before we push out
an RC. This is a popular topic right now and it’d be good to get some
early feedback on Eric’s implementation. I still need to review some
of the patches myself – let’s make this a priority, then start an RC
cycle. IIRC, the QTAIM stuff is finished from a functional standpoint,
and all that’s left is some cleanup/documentation? This is my busiest
week of the semester between TA work and writing the tutorials, but
after the conference I should be able to finish reviewing the rest of
the QTAIM patches.
I’ve found that most of plugins are transferable between 1.0 and master, even if
compiled against master. So why it’s necessary to synchronize QTAIM releases
with Avogadro releases?
I’ve checked QTAIM specifically - it’s binary compatible with 1.0
Incompatible are:
orbitalextension.so
pythonterminal.so (master version needs DockExtension, but it’s the only change after 1.0)
smartscolor.so
I don’t know exactly what this means, but I think that it good news for the QTAIM extension.
This means you can deploy builds of your plugin on Avogadro 1.0.0 and 1.0.1 right now!
–
Regards,
Konstantin
11.11.2010, 17:30, “Konstantin Tokarev” annulen@yandex.ru:
11.11.2010, 17:24, “Konstantin Tokarev” annulen@yandex.ru;:
11.11.2010, 17:12, “David Lonie” loniedavid@gmail.com;;:
On Wed, Nov 10, 2010 at 4:39 PM, Geoffrey Hutchison
geoff.hutchison@gmail.com;;; wrote:
On Nov 10, 2010, at 4:34 PM, Konstantin Tokarev wrote:
I think we should create a tag (e.g., 1.1.beta) and make build for all platforms
from this tag
I vote to just call it 1.1.0, tag this tomorrow perhaps? We can add big “WARNING, not STABLE” signs, but that was always true of 0.9 and previous releases too.
I’d like to wait until we get the QTAIM patches in before we push out
an RC. This is a popular topic right now and it’d be good to get some
early feedback on Eric’s implementation. I still need to review some
of the patches myself – let’s make this a priority, then start an RC
cycle. IIRC, the QTAIM stuff is finished from a functional standpoint,
and all that’s left is some cleanup/documentation? This is my busiest
week of the semester between TA work and writing the tutorials, but
after the conference I should be able to finish reviewing the rest of
the QTAIM patches.
I’ve found that most of plugins are transferable between 1.0 and master, even if
compiled against master. So why it’s necessary to synchronize QTAIM releases
with Avogadro releases?
I’ve checked QTAIM specifically - it’s binary compatible with 1.0
Incompatible are:
orbitalextension.so
pythonterminal.so (master version needs DockExtension, but it’s the only change after 1.0)
smartscolor.so
OK, there are a few others requiring OB >= 2.2.99, but majority are compatible.
I think it would be reasonable to provide a possibility for users to install chosen
extensions from master into stable release. Sometimes unexpected bugs in one
plugin can introduce difficulties in “production” use of “full master”, but it is not
the reason why not to try other plugins earlier!
–
Regards,
Konstantin
This means you can deploy builds of your plugin on Avogadro 1.0.0 and 1.0.1 right now!
Oh, don’t forget to remove non-working menu entry in this case
–
Regards,
Konstantin
On Nov 11, 2010, at 9:16 AM, Konstantin Tokarev wrote:
This means you can deploy builds of your plugin on Avogadro 1.0.0 and 1.0.1 right now!
Oh, don’t forget to remove non-working menu entry in this case
–
Regards,
Konstantin
Actually now that works, and there is another one added that does Molecular Graph plus Lone Pairs. :->>> (It is in Gerrit) The Atomic Charge Integration dumps to console, but I need to route it to a table…
On Nov 11, 2010, at 8:56 AM, Eric Brown wrote:
I don’t know exactly what this means, but I think that it good news for the QTAIM extension.
The QTAIM code is probably a trainwreck by Avogadro standards, but I thought that it was best to get it all out so that everyone could see that I was serious about making something that worked. What works now, and I think is robust:
- Its GPL
- Its graphical
- All algorithms are QtConcurrent!!! I run on a 12-core Mac Pro.
- ODE integrator is adaptive and automatically switches between stiff and non-stiff (LSODA)
- Integrator is Adaptive and converges on accuracy (not relative).
- Based on the (orthodox) Bader Group style of QTAIM algorithms.
Molecular Graphs (bonding drawn by QTAIM without bias)
*Nuclear and Bond Critical Points
*Curvaceous Bond Paths and different styles for covalent vs. non-covalent (solid vs. dashed)
*framework for Ring and Cage is there, too. I wish someone might help me with DAGs. This is probably the best way to go, although the Lone Pair approach, a bunch of initial points on a grid, also works.
Lone Pairs
This is important for chemical interpretation of of electronic structure and its reactivity. Lone pairs are local surplus of electron density, and these hook up with corresponding depletion of electron density. All this is implemented.
Delineation and Integration over Atomic Basins
- Fully Adaptive Algorithms
- Three types of integration:
** theta,phi and r done separately
** r,theta,phi
** x,y,z
- All single-basin properties (e.g. charge, volume, KE and PE) can be done. two-basin properties (very expensive) can be done by nesting another set of integrations inside the existing integrations.
Accuracy down to 0.01 au of charge, but may be able to go more.- Easy to do Surface Properties (only function of theta,phi).
Best
Eric
Hi All,
I was using the wrong email address to post on the list. Please find above a summary of some of the features of QTAIM that are either already in or are in Gerrit.
Kind regards
Eric
On Nov 11, 2010, at 9:16 AM, Konstantin Tokarev wrote:
This means you can deploy builds of your plugin on Avogadro 1.0.0 and 1.0.1 right now!
Oh, don’t forget to remove non-working menu entry in this case
Actually now that works, and there is another one added that does Molecular Graph plus Lone Pairs. :->>> (It is in Gerrit) The Atomic Charge Integration dumps to console, but I need to route it to a table…
eric
p.s. sorry for duplicate
2010/11/11 Konstantin Tokarev annulen@yandex.ru:
I’d like to wait until we get the QTAIM patches in before we push out
an RC. This is a popular topic right now and it’d be good to get some
early feedback on Eric’s implementation. I still need to review some
of the patches myself – let’s make this a priority, then start an RC
cycle. IIRC, the QTAIM stuff is finished from a functional standpoint,
and all that’s left is some cleanup/documentation? This is my busiest
week of the semester between TA work and writing the tutorials, but
after the conference I should be able to finish reviewing the rest of
the QTAIM patches.
I’ve found that most of plugins are transferable between 1.0 and master, even if
compiled against master. So why it’s necessary to synchronize QTAIM releases
with Avogadro releases?
Because the current master still has qtaim files under
libavogadro/src, and it would be best to release an RC/beta that is as
full-featured as possible. Clearing the good patches out of the review
board before starting a release cycle is a good practice IMHO. During
the release cycle the focus should be on bug fixes, not adding new
features, so lets get this new feature in.
Dave
11.11.2010, 19:29, “David Lonie” loniedavid@gmail.com:
2010/11/11 Konstantin Tokarev annulen@yandex.ru;:
I’d like to wait until we get the QTAIM patches in before we push out
an RC. This is a popular topic right now and it’d be good to get some
early feedback on Eric’s implementation. I still need to review some
of the patches myself – let’s make this a priority, then start an RC
cycle. IIRC, the QTAIM stuff is finished from a functional standpoint,
and all that’s left is some cleanup/documentation? This is my busiest
week of the semester between TA work and writing the tutorials, but
after the conference I should be able to finish reviewing the rest of
the QTAIM patches.
I’ve found that most of plugins are transferable between 1.0 and master, even if
compiled against master. So why it’s necessary to synchronize QTAIM releases
with Avogadro releases?
Because the current master still has qtaim files under
libavogadro/src, and it would be best to release an RC/beta that is as
full-featured as possible. Clearing the good patches out of the review
board before starting a release cycle is a good practice IMHO. During
the release cycle the focus should be on bug fixes, not adding new
features, so lets get this new feature in.
I was thinking about different thing: why it is impossible to release QTAIM
plugin as separate download? Eric could make releases more often than we
do, and since his plugin is compatible with 1.0, more people would be able
try it without any difficulties.
We could also give Eric more rights in Gerrit for his subproject to speed up
development
–
Regards,
Konstantin
On Nov 11, 2010, at 11:29 AM, David Lonie wrote:
2010/11/11 Konstantin Tokarev annulen@yandex.ru:
I’d like to wait until we get the QTAIM patches in before we push out
an RC. This is a popular topic right now and it’d be good to get some
early feedback on Eric’s implementation. I still need to review some
of the patches myself – let’s make this a priority, then start an RC
cycle. IIRC, the QTAIM stuff is finished from a functional standpoint,
and all that’s left is some cleanup/documentation? This is my busiest
week of the semester between TA work and writing the tutorials, but
after the conference I should be able to finish reviewing the rest of
the QTAIM patches.
I’ve found that most of plugins are transferable between 1.0 and master, even if
compiled against master. So why it’s necessary to synchronize QTAIM releases
with Avogadro releases?
Because the current master still has qtaim files under
libavogadro/src, and it would be best to release an RC/beta that is as
full-featured as possible. Clearing the good patches out of the review
board before starting a release cycle is a good practice IMHO. During
the release cycle the focus should be on bug fixes, not adding new
features, so lets get this new feature in.
Sorry, I have been out of town at a meeting most of the week. I am back in town now, and would love to get a release rolling. I would much rather get a couple of snapshots out, verifying things are reasonable on Windows etc before tagging and getting the distros packaging it. I also want to confirm there is nothing we broke for Kalzium, bump the .so version etc.
We should definitely get some releases rolling - I will work through the backlog in Gerrit on the weekend. I have not read through all of the emails, and so maybe missed some of the points made (I will try and get through them later). I thought we wanted to get the QTAIM data structures out of Molecule before a release?
I have some time, and could work on this if we need it. Maybe we could have an IRC meeting or Skype call to sync up soon? I feel like we have spread out a little and I would like to bring things together a little.
Marcus
Sorry, I have been out of town at a meeting most of the week. I am back in town now, and would love to get a release rolling. I would much rather get a couple of snapshots out, verifying things are reasonable on Windows etc before tagging and getting the distros packaging it. I also want to confirm there is nothing we broke for Kalzium, bump the .so version etc.
Surely. Also, there is a lot of new features which were not widely tested by users, and “beta” release may help us to found some bugs before distros will package it. I’ve set up environment for cross-distribution Linux binaries, so all major platforms are covered
We should definitely get some releases rolling - I will work through the backlog in Gerrit on the weekend. I have not read through all of the emails, and so maybe missed some of the points made (I will try and get through them later). I thought we wanted to get the QTAIM data structures out of Molecule before a release?
I have some time, and could work on this if we need it. Maybe we could have an IRC meeting or Skype call to sync up soon? I feel like we have spread out a little and I would like to bring things together a little.
I’m on IRC now, and I see David is also connected
–
Regards,
Konstantin
-----Original Message-----
From: Marcus D. Hanwell [mailto:mhanwell@gmail.com]
Sent: Thu 11/11/2010 16:57
To: David Lonie
Cc: Louis Ricard; Avogadro-devel Devel; Eric Brown
Subject: Re: [Avogadro-devel] Announcement about testing builds?
On Nov 11, 2010, at 11:29 AM, David Lonie wrote:
2010/11/11 Konstantin Tokarev annulen@yandex.ru:
I’d like to wait until we get the QTAIM patches in before we push out
an RC. This is a popular topic right now and it’d be good to get some
early feedback on Eric’s implementation. I still need to review some
of the patches myself – let’s make this a priority, then start an RC
cycle. IIRC, the QTAIM stuff is finished from a functional standpoint,
and all that’s left is some cleanup/documentation? This is my busiest
week of the semester between TA work and writing the tutorials, but
after the conference I should be able to finish reviewing the rest of
the QTAIM patches.
I’ve found that most of plugins are transferable between 1.0 and master, even if
compiled against master. So why it’s necessary to synchronize QTAIM releases
with Avogadro releases?
Because the current master still has qtaim files under
libavogadro/src, and it would be best to release an RC/beta that is as
full-featured as possible. Clearing the good patches out of the review
board before starting a release cycle is a good practice IMHO. During
the release cycle the focus should be on bug fixes, not adding new
features, so lets get this new feature in.
Sorry, I have been out of town at a meeting most of the week. I am back in town now, and would love to get a release rolling. I would much rather get a couple of snapshots out, verifying things are reasonable on Windows etc before tagging and getting the distros packaging it. I also want to confirm there is nothing we broke for Kalzium, bump the .so version etc.
We should definitely get some releases rolling - I will work through the backlog in Gerrit on the weekend. I have not read through all of the emails, and so maybe missed some of the points made (I will try and get through them later). I thought we wanted to get the QTAIM data structures out of Molecule before a release?
I have some time, and could work on this if we need it. Maybe we could have an IRC meeting or Skype call to sync up soon? I feel like we have spread out a little and I would like to bring things together a little.
This is probably on someone’s radar - and is maybe what Marcus meant, but I just wanted to say that I was looking at the QTAIM stuff earlier and it looks like the data that it needs is already parsed for the orbital rendering code.
If you’re refactoring some of the code around this, it’s make sense to make it possible to instantiate a QTAIM wavefunction from the stuff parsed for the orbital code. That way Avogadro would instantly support AIM for all the codes it can render orbitals, which would be a pretty impressive feature for not much work.
Unfortunately I’m away for the rest of the week, but I might be able to help out with this next week if people think it’s a good idea.
Best wishes,
Jens
–
Scanned by iCritical.
On Nov 11, 2010, at 1:46 PM, jens.thomas@stfc.ac.uk wrote:
This is probably on someone’s radar - and is maybe what Marcus meant, but I just wanted to say that I was looking at the QTAIM stuff earlier and it looks like the data that it needs is already parsed for the orbital rendering code.
If you’re refactoring some of the code around this, it’s make sense to make it possible to instantiate a QTAIM wavefunction from the stuff parsed for the orbital code. That way Avogadro would instantly support AIM for all the codes it can render orbitals, which would be a pretty impressive feature for not much work.
Unfortunately I’m away for the rest of the week, but I might be able to help out with this next week if people think it’s a good idea.
Best wishes,
Jens
Hi Jens,
Absolutely, this is what I am working on now this instant. I got bogged down grading midterms, but now I'm back. Now I am following Geoff's advice and stuff the required the Molden, Gaussian, GAMESS etc. wavefunction information into properties of the Molecule class so that they can be read by the QTAIM code.
Thanks for your encouragement!!!
Best
Eric
On Nov 11, 2010, at 1:46 PM, jens.thomas@stfc.ac.uk wrote:
This is probably on someone’s radar - and is maybe what Marcus meant, but I just wanted to say that I was looking at the QTAIM stuff earlier and it looks like the data that it needs is already parsed for the orbital rendering code.
If you’re refactoring some of the code around this, it’s make sense to make it possible to instantiate a QTAIM wavefunction from the stuff parsed for the orbital code. That way Avogadro would instantly support AIM for all the codes it can render orbitals, which would be a pretty impressive feature for not much work.
Unfortunately I’m away for the rest of the week, but I might be able to help out with this next week if people think it’s a good idea.
Best wishes,
Jens
Hi Jens,
Absolutely, this is what I am working on now this instant. I got bogged down grading midterms, but now I'm back. Now I am following Geoff's advice and stuff the required the Molden, Gaussian, GAMESS etc. wavefunction information into properties of the Molecule class so that they can be read by the QTAIM code.
Thanks for your encouragement!!!
That’s great - really looking forward to giving it a go when you’re done!
Best wishes,
Jens
Hi Jens, and All,
I just submitted the "Missing Link" to Gerrit. It bolts on to the Gaussian basis set class, and if Cartesian GTOs, loads up the QTAIM arrays.
Kind regards
Eric