Avogadro-devel Digest, Vol 90, Issue 2

Development
1

I think Albert was talking about a “glue” layer for quantum io, not for “regular” input. Regular input is probably best handled through Open Babel, since that already handles bond perception, typing, etc.

Right now, Avogadro v1 and v2 have separate code for reading basis set and MO information from various formats. Instead, such information (which is only performed when computing orbitals, etc) could be handled through a python call and cclib parsing.

I’m very much in favor of such an approach, since cclib handles a greater variety of quantum data and a greater variety of formats than Avogadro does presently (e.g., MO symmetries, energy scans).

As far as CP2K, Quantum Espresso and the like, I think these would require some cclib support for periodic boundary conditions. I think there was also some push on the solid-state side to use XCrysDens format (XCrySDen - (X-Window) Crystalline Structures and Densities http://www.xcrysden.org/doc/XSF.html) as something like Molden format in molecular chemistry.

-Geoff

On Thu, Dec 11, 2014 at 7:29 PM Marcus D. Hanwell mhanwell@gmail.com wrote:
On Thu, Dec 11, 2014 at 4:14 PM, Defusco III, Albert A <defusco@pitt.edu mailto:defusco@pitt.edu> wrote:

Hi guys,

Would good project be to re-wire Avogadro to use cclib instead of relying on the quantumio in Avogadro2? I’m very much in favor of adding visualization capabilities for QuantumEspresso and CP2K.

You don’t need to rewire, the Open Babel plugin reuses all of the
readers/writers advertised. That pattern could be used to reuse the
cclib readers/writers, offering the option of what reader to use if
there is more than one. I think it would be great to add that
capability.

Marcus

Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net mailto:Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options https://lists.sourceforge.net/lists/listinfo/avogadro-devel

2

Hi guys,

Would good project be to re-wire Avogadro to use cclib instead of relying on the quantumio in Avogadro2? I’m very much in favor of adding visualization capabilities for QuantumEspresso and CP2K.

Albert

Albert DeFusco, Ph.D.
Research Assistant Professor
Technical Director, Center for Simulation and Modeling
University of Pittsburgh
Pittsburgh, PA 15260
412-648-3094
http://www.pitt.edu/~defusco
http://www.sam.pitt.edu

On Dec 8, 2014, at 5:32 PM, avogadro-devel-request@lists.sourceforge.net wrote:

Personally, I’d like to see more interoperability between the
open-source chemistry apps, including avogadro, openbabel and cclib

Indeed, I think one big push is for Avogadro v2 to use cclib to read QM file formats (e.g., MO coefficients, basis set, etc.) rather than implementing them all in C++.

As for Open Babel and cclib, I think some of that is simply a matter of not repeating the wheel - i.e., leaving QM-specific data in cclib, but certainly a lot more is important here.

I think these are good ideas. I?ll go create a wiki page somewhere to start storing some of them.

-Geoff

P.S. I don?t think it would be hard for Avogadro as a whole to get approved, since we?ve had 3 students working on Avogadro-related code in previous years. I do agree that an umbrella organization might be helpful.

Albert DeFusco, Ph.D.
Research Assistant Professor
Technical Director, Center for Simulation and Modeling
University of Pittsburgh
Pittsburgh, PA 15260
412-648-3094
http://www.pitt.edu/~defusco
http://www.sam.pitt.edu

3

On Thu, Dec 11, 2014 at 4:14 PM, Defusco III, Albert A defusco@pitt.edu wrote:

Hi guys,

Would good project be to re-wire Avogadro to use cclib instead of relying on the quantumio in Avogadro2? I’m very much in favor of adding visualization capabilities for QuantumEspresso and CP2K.

You don’t need to rewire, the Open Babel plugin reuses all of the
readers/writers advertised. That pattern could be used to reuse the
cclib readers/writers, offering the option of what reader to use if
there is more than one. I think it would be great to add that
capability.

Marcus

4

On Thu, Dec 11, 2014 at 11:36 PM, Geoffrey Hutchison
geoff.hutchison@gmail.com wrote:

I think Albert was talking about a “glue” layer for quantum io, not for
“regular” input. Regular input is probably best handled through Open Babel,
since that already handles bond perception, typing, etc.

Right now, Avogadro v1 and v2 have separate code for reading basis set and
MO information from various formats. Instead, such information (which is
only performed when computing orbitals, etc) could be handled through a
python call and cclib parsing.

It sounds like you think of these things as exclusive, and I don’t see
why they should be. Maybe we just need to chat, and flesh out what is
meant a little more. If what was done for Open Babel is considered a
“glue” layer for “regular” input, then what I meant in my reply was
that it sounded like a great idea and that we even have a template for
such a layer.

We could certainly expand what can be brought in by such a layer, but
I have some motivation to keep some of the other IO work present as it
is demonstrably much more efficient than going through Open Babel for
“regular” input for example. We can certainly tweak defaults, so the
richest approach would be offered automatically.

Marcus

5

It sounds like you think of these things as exclusive, and I don’t see
why they should be.

The current state of the code is avogadrolibs/avogadro/quantumio at master · OpenChemistry/avogadrolibs · GitHub

That is, these things are separate from “regular” IO. Reading files and finding quantum data are currently in different parts of the code.

Now, one may question whether “regular” and quantum IO should be separate. But I’m not talking about throwing away existing code - I believe Albert was saying that rather than adding X new implementations to avogadrolibs/avogadro/quantumio, it would be helpful to have an interface to cclib for parsing quantum data.

is demonstrably much more efficient than going through Open Babel for
“regular” input for example. We can certainly tweak defaults, so the

I certainly wasn’t talking about changing the current pattern for regular IO, although I’d certainly suggest that the interface could merge “import” and “open” commands. In the case of CML or other formats that Avogadro directly handles, preference can go to the internal implementation, and other formats could be handled through Open Babel.

I’d be happy to make that change.

I thought the discussion was about Summer of Code projects, and certainly improving quantum IO would be great. (Adding features to read and visualize other “cube” formats would be nice too.)

-Geoff

6

Marcus,

Yes, I agree. There are also plenty of other glue to work on like alpha/beta orbitals, vibrations, electronic properties, etc that can be grabbed from cclib without writing new file parsers.

Albert

On Dec 12, 2014, at 12:33 PM, Geoffrey Hutchison geoff.hutchison@gmail.com wrote:

It sounds like you think of these things as exclusive, and I don’t see
why they should be.

The current state of the code is avogadrolibs/avogadro/quantumio at master · OpenChemistry/avogadrolibs · GitHub

That is, these things are separate from “regular” IO. Reading files and finding quantum data are currently in different parts of the code.

Now, one may question whether “regular” and quantum IO should be separate. But I’m not talking about throwing away existing code - I believe Albert was saying that rather than adding X new implementations to avogadrolibs/avogadro/quantumio, it would be helpful to have an interface to cclib for parsing quantum data.

is demonstrably much more efficient than going through Open Babel for
“regular” input for example. We can certainly tweak defaults, so the

I certainly wasn’t talking about changing the current pattern for regular IO, although I’d certainly suggest that the interface could merge “import” and “open” commands. In the case of CML or other formats that Avogadro directly handles, preference can go to the internal implementation, and other formats could be handled through Open Babel.

I’d be happy to make that change.

I thought the discussion was about Summer of Code projects, and certainly improving quantum IO would be great. (Adding features to read and visualize other “cube” formats would be nice too.)

-Geoff

7

One of the things I want to do soon is give cclib the ability to output
CML. That would be an easy way to communicate between programs in a
standard format.

Karol

On Fri, Dec 12, 2014 at 12:33 PM, Geoffrey Hutchison <
geoff.hutchison@gmail.com> wrote:

It sounds like you think of these things as exclusive, and I don’t see
why they should be.

The current state of the code is
avogadrolibs/avogadro/quantumio at master · OpenChemistry/avogadrolibs · GitHub

That is, these things are separate from “regular” IO. Reading files and
finding quantum data are currently in different parts of the code.

Now, one may question whether “regular” and quantum IO should be
separate. But I’m not talking about throwing away existing code - I believe
Albert was saying that rather than adding X new implementations to
avogadrolibs/avogadro/quantumio, it would be helpful to have an interface
to cclib for parsing quantum data.

is demonstrably much more efficient than going through Open Babel for
“regular” input for example. We can certainly tweak defaults, so the

I certainly wasn’t talking about changing the current pattern for regular
IO, although I’d certainly suggest that the interface could merge “import”
and “open” commands. In the case of CML or other formats that Avogadro
directly handles, preference can go to the internal implementation, and
other formats could be handled through Open Babel.

I’d be happy to make that change.

I thought the discussion was about Summer of Code projects, and certainly
improving quantum IO would be great. (Adding features to read and visualize
other “cube” formats would be nice too.)

-Geoff

Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE

http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

8

Hi Karol,

It looks Avogadro2 will be using Chemical JSON whenever possible to transfer data. Do you think this would be possible with cclib?

http://wiki.openchemistry.org/Chemical_JSON

Albert

Albert DeFusco, Ph.D.
Research Assistant Professor
Technical Director, Center for Simulation and Modeling
University of Pittsburgh
Pittsburgh, PA 15260
412-648-3094
http://www.pitt.edu/~defusco
http://www.sam.pitt.edu

On Dec 17, 2014, at 11:22 PM, Karol Langner karol.langner@gmail.com wrote:

One of the things I want to do soon is give cclib the ability to output CML. That would be an easy way to communicate between programs in a standard format.

Karol

On Fri, Dec 12, 2014 at 12:33 PM, Geoffrey Hutchison geoff.hutchison@gmail.com wrote:

It sounds like you think of these things as exclusive, and I don’t see
why they should be.

The current state of the code is avogadrolibs/avogadro/quantumio at master · OpenChemistry/avogadrolibs · GitHub

That is, these things are separate from “regular” IO. Reading files and finding quantum data are currently in different parts of the code.

Now, one may question whether “regular” and quantum IO should be separate. But I’m not talking about throwing away existing code - I believe Albert was saying that rather than adding X new implementations to avogadrolibs/avogadro/quantumio, it would be helpful to have an interface to cclib for parsing quantum data.

is demonstrably much more efficient than going through Open Babel for
“regular” input for example. We can certainly tweak defaults, so the

I certainly wasn’t talking about changing the current pattern for regular IO, although I’d certainly suggest that the interface could merge “import” and “open” commands. In the case of CML or other formats that Avogadro directly handles, preference can go to the internal implementation, and other formats could be handled through Open Babel.

I’d be happy to make that change.

I thought the discussion was about Summer of Code projects, and certainly improving quantum IO would be great. (Adding features to read and visualize other “cube” formats would be nice too.)

-Geoff

Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

9

It looks Avogadro2 will be using Chemical JSON whenever possible to transfer data. Do you think this would be possible with cclib?
Chemical JSON - wiki.openchemistry.org

Right now, there aren’t really specifications for computational data (MO, basis, etc.) in Chemical JSON. So CML would probably be fine, or some push to standardize these data representations in Chemical JSON.

(I’d be happy to help with either of these.)

-Geoff

10

Albert,

I think CML will continue to be very much a first class citizen too.
JSON feels much easier to change/augment, and Python support for JSON
is very good - it would be great to add it, but I don’t think it is
critical. We could add some simple Python glue too, the format is
super-simple. With Open Babel we ended up using CML, MDL and XYZ to
get data into Avogadro 2.

Marcus

On Thu, Dec 18, 2014 at 9:59 AM, Defusco III, Albert A defusco@pitt.edu wrote:

Hi Karol,

It looks Avogadro2 will be using Chemical JSON whenever possible to transfer data. Do you think this would be possible with cclib?

Chemical JSON - wiki.openchemistry.org

Albert

Albert DeFusco, Ph.D.
Research Assistant Professor
Technical Director, Center for Simulation and Modeling
University of Pittsburgh
Pittsburgh, PA 15260
412-648-3094
http://www.pitt.edu/~defusco
http://www.sam.pitt.edu

On Dec 17, 2014, at 11:22 PM, Karol Langner karol.langner@gmail.com wrote:

One of the things I want to do soon is give cclib the ability to output CML. That would be an easy way to communicate between programs in a standard format.

Karol

On Fri, Dec 12, 2014 at 12:33 PM, Geoffrey Hutchison geoff.hutchison@gmail.com wrote:

It sounds like you think of these things as exclusive, and I don’t see
why they should be.

The current state of the code is avogadrolibs/avogadro/quantumio at master · OpenChemistry/avogadrolibs · GitHub

That is, these things are separate from “regular” IO. Reading files and finding quantum data are currently in different parts of the code.

Now, one may question whether “regular” and quantum IO should be separate. But I’m not talking about throwing away existing code - I believe Albert was saying that rather than adding X new implementations to avogadrolibs/avogadro/quantumio, it would be helpful to have an interface to cclib for parsing quantum data.

is demonstrably much more efficient than going through Open Babel for
“regular” input for example. We can certainly tweak defaults, so the

I certainly wasn’t talking about changing the current pattern for regular IO, although I’d certainly suggest that the interface could merge “import” and “open” commands. In the case of CML or other formats that Avogadro directly handles, preference can go to the internal implementation, and other formats could be handled through Open Babel.

I’d be happy to make that change.

I thought the discussion was about Summer of Code projects, and certainly improving quantum IO would be great. (Adding features to read and visualize other “cube” formats would be nice too.)

-Geoff

Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

11

JSON might be more realistic due to excellent Python support. Created a
cclib issue for that, too: Chemical JSON support · Issue #156 · cclib/cclib · GitHub

I think both CML and chemical JSON will still change with time, and it’s
not clear what will emerge as the standard in compchem. So it would be
great to support both in some way. Nonetheless, the two can pretty much be
converted between each other, right?

On Thu, Dec 18, 2014 at 10:31 AM, Marcus D. Hanwell <
mhanwell@gmail.com> wrote:

Albert,

I think CML will continue to be very much a first class citizen too.
JSON feels much easier to change/augment, and Python support for JSON
is very good - it would be great to add it, but I don’t think it is
critical. We could add some simple Python glue too, the format is
super-simple. With Open Babel we ended up using CML, MDL and XYZ to
get data into Avogadro 2.

Marcus

On Thu, Dec 18, 2014 at 9:59 AM, Defusco III, Albert A defusco@pitt.edu
wrote:

Hi Karol,

It looks Avogadro2 will be using Chemical JSON whenever possible to
transfer data. Do you think this would be possible with cclib?

Chemical JSON - wiki.openchemistry.org

Albert

Albert DeFusco, Ph.D.
Research Assistant Professor
Technical Director, Center for Simulation and Modeling
University of Pittsburgh
Pittsburgh, PA 15260
412-648-3094
http://www.pitt.edu/~defusco
http://www.sam.pitt.edu

On Dec 17, 2014, at 11:22 PM, Karol Langner karol.langner@gmail.com
wrote:

One of the things I want to do soon is give cclib the ability to output
CML. That would be an easy way to communicate between programs in a
standard format.

Karol

On Fri, Dec 12, 2014 at 12:33 PM, Geoffrey Hutchison <
geoff.hutchison@gmail.com> wrote:

It sounds like you think of these things as exclusive, and I don’t see
why they should be.

The current state of the code is
avogadrolibs/avogadro/quantumio at master · OpenChemistry/avogadrolibs · GitHub

That is, these things are separate from “regular” IO. Reading files
and finding quantum data are currently in different parts of the code.

Now, one may question whether “regular” and quantum IO should be
separate. But I’m not talking about throwing away existing code - I believe
Albert was saying that rather than adding X new implementations to
avogadrolibs/avogadro/quantumio, it would be helpful to have an interface
to cclib for parsing quantum data.

is demonstrably much more efficient than going through Open Babel for
“regular” input for example. We can certainly tweak defaults, so the

I certainly wasn’t talking about changing the current pattern for
regular IO, although I’d certainly suggest that the interface could merge
“import” and “open” commands. In the case of CML or other formats that
Avogadro directly handles, preference can go to the internal
implementation, and other formats could be handled through Open Babel.

I’d be happy to make that change.

I thought the discussion was about Summer of Code projects, and
certainly improving quantum IO would be great. (Adding features to read and
visualize other “cube” formats would be nice too.)

-Geoff

Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration &
more
Get technology previously reserved for billion-dollar corporations, FREE

http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration &
more
Get technology previously reserved for billion-dollar corporations, FREE

http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk_______________________________________________

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options

Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE

http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk

Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
avogadro-devel List Signup and Options