Support for the PLT file format

Hi,

First of all: I’m not sure if I should post this to the Avogadro or the
OpenBabel mailing lists. Perhaps both. Anyway, if I’m wrong here, just
point me to the right direction.

I’m doing ab initio DFT calculations with the Turbomole quantum
chemistry package [1] and am interested in using Avogadro to visualize
molecular geometry and orbitals - and then export to povray, for
example. The geometry files Turbomole uses are already supported by
Avogadro/OpenBabel and so I’ve no problems importing them and displaying
the geometry itself. [2]

However, Turbomole also possesses the ability to calculate orbitals on a
grid that then allow visualization. Current versions of Turbomole save
that data in the gOpenMol binary PLT file format. The format is very
simple and described in the gOpenMol documentation [3]. Since it is so
simple, I decided I could try to implement that myself. But while trying
to do so, I realized that either my understanding of the basic concepts
behind OpenBabel/Avogadro is severely lacking or both currently don’t
have the necessary infrastructure to use a workflow compatible with the
output of Turbomole.

Let me explain in details: In order to do ab initio calculations, you
provide Turbomole with a geometry file which contains the positions of
the atoms (you can also use Turbomole to relax the geometry but that’s
irrelevant for this discussion). Using DFT Turbomole then calculates
(iteratively) the orbitals which describe the electronic structure of
that molecule. After the DFT cycle you can have Turbomole calculate the
values of those orbitals on a grid. The orbitals are then saved in files
called .plt, i.e. 312.plt for the orbital #312 and so on
and so forth for every orbital you wanted to calculate.

This plt file contains only the orbital data on the grid, it does
not contain any information on atomar geometry. The geometry is only
available in the coordinate file you supplied Turbomole with - not
anywhere else. Programs that can import these orbitals (I know of
gOpenMol and VMD, there are probably others) provide the following
workflow: First one imports the geometry data and then one starts to add
the orbitals to the current state of the molecule by importing the PLT
files one by one.

Now, as far as I’ve understood it, Avogadro and/or OpenBabel can only
deal with files that contain all data at once or at least contain
pointers to other files, so you only select one file to import. Am I
correct in this or did I simply miss something?

If I missed something, please point me in the right direction.

If I’m correct with my assessment, how would you want to implement this?
The simplest thing for now would probably be some kind of "summary file"
which points to the coordinate files and the orbitals one wants to plot
that causes OpenBabel/Avogadro to read those files all-in-one. This is
however not very user-friendly and I’d prefer some solution similar to
the one other software that can import this already has.

Anyway, if it’s not extremely complicated I’d be willing to implement
support for this in Avogadro/OpenBabel once I know which way would be
best to do so.

[1] http://turbomole.de/
[2] Oh, by the way, unrelated to this issue, a minor annoyance: In the
import dialog there’s a checkbox “Coordinates are in Angstrom” or
similar which is checked by defaults. However, Turbomole coord files are
always in Bohr so the checkbox doesn’t make sense and atomic positions
are incorrect if I forget to uncheck it.
[3] http://www.csc.fi/english/pages/g0penMol/tutorials/gopenmol.pdf
(Appendix 2)

Best regards and thanks in advance,
Christian

Christian,

Sorry I forgot to “reply-all”, I’m going to blame it on lack of sleep
and the 3-week old daughter. :slight_smile: I’m including both messages below for
others to follow.

You almost have the workflow right. Currently, Avogadro opens a
structure file (e.g., the output from Gaussian or Q-Chem) and then the
"Create Surfaces" command (orbitalextension.cpp) scans for related
files in the directory. So what I was saying is that the
orbitalextension could be changed to look for other files,
like .PLT, .DX or .CUBE – files which already have volumetric data in
them.

Does that make sense? I can give you an example if it would help.

Cheers,
-Geoff

On Mar 29, 2009, at 3:30 PM, Christian Seiler wrote:

Hi,

First of all: Thanks for the really quick response!

By the way: Is there any reason you answered off-list?

If I missed something, please point me in the right direction.

Well, it’s not complete. We “cheat” with Avogadro. If you look at the
code in the orbital extension, it will look for files with particular
extensions, like .fchk (for Gaussian or Q-Chem) or .aux (for MOPAC).

So it should be fairly easy to amend the code in
orbitalextension.cpp to
look for “.PLT” files and add appropriate Cube objects. The same
thing
should probably happen if we see .dx or .cube or other files too.

So, if I understand this correctly: If do File -> Import -> Molecule
and
then select the Turbomole ‘coord’ file, Avogadro scans the directory
that contains the ‘coord’ file for orbital files (with extensions you
can specify in orbitalextension.cpp) - and if there are any, they are
then imported into Avogadro?

[2] Oh, by the way, unrelated to this issue, a minor annoyance: In
the
import dialog there’s a checkbox “Coordinates are in Angstrom” or
similar which is checked by defaults. However, Turbomole coord
files are
always in Bohr so the checkbox doesn’t make sense and atomic
positions
are incorrect if I forget to uncheck it.

Oh. This would definitely be an Open Babel bug. I didn’t add the
Turbomole code, but it was added with that option. If coordinates are
always in Bohr, then Open Babel needs a patch to rip out the option
and
always read coords in Bohr.

I’ll re-read the Turbomole documentation to make sure I have this
correct in mind. If so, I’ll open a bug report for the Open Babel
project.

So my suggestion is this:

  1. Add support in orbitalextension for finding PLT files.
  2. Implement the PLT importer in Avogadro to add new Cubes for each
    PLT
    file you find.
  3. If you want, consider adding support in Open Babel for
    reading/translating PLT cubes. (We’re hoping that Babel can help with
    debugging since you could directly compare cubes from different QM
    files.)

I’ll look into that and either send you patches with a working version
or ask further questions on this issue. :slight_smile:

Best regards,
Christian

Hi Geoffrey,

You almost have the workflow right. Currently, Avogadro opens a
structure file (e.g., the output from Gaussian or Q-Chem) and then the
"Create Surfaces" command (orbitalextension.cpp) scans for related files
in the directory. So what I was saying is that the orbitalextension
could be changed to look for other files, like .PLT, .DX or .CUBE –
files which already have volumetric data in them.

Does that make sense?

Ah, now everything falls into place in my head. :slight_smile:

Ok, great, then I’ll try to implement that during this or the next week.

Best regards,
Christian

Hi,

On Mar 29, 2009, at 3:30 PM, Christian Seiler wrote:

Hi,

First of all: Thanks for the really quick response!

By the way: Is there any reason you answered off-list?

If I missed something, please point me in the right direction.

Well, it’s not complete. We “cheat” with Avogadro. If you look at the
code in the orbital extension, it will look for files with particular
extensions, like .fchk (for Gaussian or Q-Chem) or .aux (for MOPAC).

So it should be fairly easy to amend the code in
orbitalextension.cpp to
look for “.PLT” files and add appropriate Cube objects. The same
thing
should probably happen if we see .dx or .cube or other files too.

So, if I understand this correctly: If do File -> Import -> Molecule
and
then select the Turbomole ‘coord’ file, Avogadro scans the directory
that contains the ‘coord’ file for orbital files (with extensions you
can specify in orbitalextension.cpp) - and if there are any, they are
then imported into Avogadro?

There is no reason why you couldn’t write an extension that would allow
the user to select the corresponding cube files. This is something I
have been thinking about adding - file imports that add to the currently
loaded molecule. By default we open a new window but that is just the
convention we are using.

A new extension could be added that simply added whatever was in the
loaded file to the Molecule instance in the current window. That would
allow the addition of multiple conformers from a series of files for
example, or multiple cubes from a series of cube files. I need to tidy
up a few examples, but one of the other extensions I wrote loads an xyz
for molecule coordinates and then loads up a parm file to get connectivity.

[2] Oh, by the way, unrelated to this issue, a minor annoyance: In
the
import dialog there’s a checkbox “Coordinates are in Angstrom” or
similar which is checked by defaults. However, Turbomole coord
files are
always in Bohr so the checkbox doesn’t make sense and atomic
positions
are incorrect if I forget to uncheck it.

Oh. This would definitely be an Open Babel bug. I didn’t add the
Turbomole code, but it was added with that option. If coordinates are
always in Bohr, then Open Babel needs a patch to rip out the option
and
always read coords in Bohr.

I’ll re-read the Turbomole documentation to make sure I have this
correct in mind. If so, I’ll open a bug report for the Open Babel
project.

So my suggestion is this:

  1. Add support in orbitalextension for finding PLT files.
  2. Implement the PLT importer in Avogadro to add new Cubes for each
    PLT
    file you find.
  3. If you want, consider adding support in Open Babel for
    reading/translating PLT cubes. (We’re hoping that Babel can help with
    debugging since you could directly compare cubes from different QM
    files.)

I’ll look into that and either send you patches with a working version
or ask further questions on this issue. :slight_smile:

I wrote a lot of the cube import code in OpenBabel, along with the
orbital extension code and mesh generation. Please feel free to ask if
you have any questions at all. Some of this code could do with a little
spring cleaning when I find some time.

Thanks,

Marcus