Fwd: A user report of Avogadro

I think we need to spend some time working on default force-fields.
Most users don’t know UFF from MMFF94 and will see errors like allene
and blame Avogadro (not the force field).

Cheers,
-Geoff

Begin forwarded message:

From: xis19+@pitt.edu
Date: September 7, 2008 11:15:17 PM EDT
Subject: A user report of Avogadro

Dear Prof. Hutchison,
I have been looked for a organic molecule draw tool in Linux/KDE for a
long time, and your Avogadro really impressed me a lot. It seems used
quantum chemistry calculation to optimize the structure of the
molecule,
and it works very well for me. However, I found a few (possible)
bugs. One
of them is, I tried to draw CH_2=C=CH_2, and the result is a flat
molecule: all atoms are in one plane. It is impossible as two \pi
bonds
are perpendicular. Another problem is, I also tried several inorganic
molecule, and the result is not good, sometimes even ridiculous. My
personal interest is organic and do not have plenty of computational
chemistry knowledge, but I do hope the program can be improved.
Furthermore, I myself hope Avogadro can help me draw organic
structures
like ChemDraw. I have some Qt/C++ programming skills but I do not have
sufficient time.

Best wishes
Xiaoge Su

The problem may be in some cases the drawing “strategy”.
Drawing an allene in the plane will produce a planar molecule
and the force field optimization will keep it as such. But if one
now selects a CH2 and rotate it by ~90 degrees, the optimization
will work.

On the other hand, take an hypervalent molecule like SCL5.
It shoud have a trigonalbipyramid geometry. UFF takes it to
a sqare base pyramid. All others collapse the molecule to SCL. ???

I have another query. I recently tried to draw a metal-hydrogen
bond. Avogadro does not allow this. Try for instance, drawing
a trans-(PH3)2PtClH hydride.

Cheers,

Louis

Le 8 sept. 08 à 16:13, Geoffrey Hutchison a écrit :

I think we need to spend some time working on default force-fields.
Most users don’t know UFF from MMFF94 and will see errors like
allene and blame Avogadro (not the force field).

Cheers,
-Geoff

Begin forwarded message:

From: xis19+@pitt.edu
Date: September 7, 2008 11:15:17 PM EDT
Subject: A user report of Avogadro

Dear Prof. Hutchison,
I have been looked for a organic molecule draw tool in Linux/KDE
for a
long time, and your Avogadro really impressed me a lot. It seems used
quantum chemistry calculation to optimize the structure of the
molecule,
and it works very well for me. However, I found a few (possible)
bugs. One
of them is, I tried to draw CH_2=C=CH_2, and the result is a flat
molecule: all atoms are in one plane. It is impossible as two \pi
bonds
are perpendicular. Another problem is, I also tried several inorganic
molecule, and the result is not good, sometimes even ridiculous. My
personal interest is organic and do not have plenty of computational
chemistry knowledge, but I do hope the program can be improved.
Furthermore, I myself hope Avogadro can help me draw organic
structures
like ChemDraw. I have some Qt/C++ programming skills but I do not
have
sufficient time.

Best wishes
Xiaoge Su


This SF.Net email is sponsored by the Moblin Your Move Developer’s
challenge
Build the coolest Linux based applications with Moblin SDK & win
great prizes
Grand prize is a trip for two to an Open Source event anywhere in
the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

Half-related: yesterday Gael got a crash in the Ghemical forcefield,
which was selected by default. Is there a point in keeping it the
default now that we have the other force fields ? It seems less stable
than the others.

Cheers,
Benoit

Quoting Geoffrey Hutchison geoffh+@pitt.edu:

I think we need to spend some time working on default force-fields.
Most users don’t know UFF from MMFF94 and will see errors like allene
and blame Avogadro (not the force field).

Cheers,
-Geoff

Begin forwarded message:

From: xis19+@pitt.edu
Date: September 7, 2008 11:15:17 PM EDT
Subject: A user report of Avogadro

Dear Prof. Hutchison,
I have been looked for a organic molecule draw tool in Linux/KDE for a
long time, and your Avogadro really impressed me a lot. It seems used
quantum chemistry calculation to optimize the structure of the molecule,
and it works very well for me. However, I found a few (possible) bugs. One
of them is, I tried to draw CH_2=C=CH_2, and the result is a flat
molecule: all atoms are in one plane. It is impossible as two \pi bonds
are perpendicular. Another problem is, I also tried several inorganic
molecule, and the result is not good, sometimes even ridiculous. My
personal interest is organic and do not have plenty of computational
chemistry knowledge, but I do hope the program can be improved.
Furthermore, I myself hope Avogadro can help me draw organic structures
like ChemDraw. I have some Qt/C++ programming skills but I do not have
sufficient time.

Best wishes
Xiaoge Su


This message was sent using IMP, the Internet Messaging Program.

I do not think it is half related.
The point is that we need something else.
I personally never use Ghemical.
If I did not dream, Geoff mentioned some times ago
a need to implement PM2 in Avogadro.

I tend to use forcefields as a pre-optimizing set to
quantum methods calculations. In this respect,
most optimization of organometallic species give
poor results, if they do not fail.

Louis

Le 8 sept. 08 à 21:26, jacob@math.jussieu.fr a écrit :

Half-related: yesterday Gael got a crash in the Ghemical forcefield,
which was selected by default. Is there a point in keeping it the
default now that we have the other force fields ? It seems less stable
than the others.

Cheers,
Benoit

Quoting Geoffrey Hutchison geoffh+@pitt.edu:

I think we need to spend some time working on default force-fields.
Most users don’t know UFF from MMFF94 and will see errors like allene
and blame Avogadro (not the force field).

Cheers,
-Geoff

Begin forwarded message:

From: xis19+@pitt.edu
Date: September 7, 2008 11:15:17 PM EDT
Subject: A user report of Avogadro

Dear Prof. Hutchison,
I have been looked for a organic molecule draw tool in Linux/KDE
for a
long time, and your Avogadro really impressed me a lot. It seems
used
quantum chemistry calculation to optimize the structure of the
molecule,
and it works very well for me. However, I found a few (possible)
bugs. One
of them is, I tried to draw CH_2=C=CH_2, and the result is a flat
molecule: all atoms are in one plane. It is impossible as two \pi
bonds
are perpendicular. Another problem is, I also tried several
inorganic
molecule, and the result is not good, sometimes even ridiculous. My
personal interest is organic and do not have plenty of computational
chemistry knowledge, but I do hope the program can be improved.
Furthermore, I myself hope Avogadro can help me draw organic
structures
like ChemDraw. I have some Qt/C++ programming skills but I do not
have
sufficient time.

Best wishes
Xiaoge Su


This message was sent using IMP, the Internet Messaging Program.


This SF.Net email is sponsored by the Moblin Your Move Developer’s
challenge
Build the coolest Linux based applications with Moblin SDK & win
great prizes
Grand prize is a trip for two to an Open Source event anywhere in
the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

On Sep 8, 2008, at 3:26 PM, jacob@math.jussieu.fr wrote:

Half-related: yesterday Gael got a crash in the Ghemical forcefield,
which was selected by default.

Well, I’d like to know about crashes.

But I thought I had set UFF to the default forcefield. If not, it’s
certainly in my local changes.

On Sep 8, 2008, at 1:59 PM, Louis Ricard wrote:

The problem may be in some cases the drawing “strategy”.
Drawing an allene in the plane will produce a planar molecule
and the force field optimization will keep it as such. But if one
now selects a CH2 and rotate it by ~90 degrees, the optimization
will work.

No, force fields should (in principle) correct for some of these
common cases. There’s something in UFF about allene, although I can’t
remember if I implemented the special case or not. It’s tricky, since
you’re talking about an interaction H2C=C=CH2 which is longer than a
normal dihedral.

On the other hand, take an hypervalent molecule like SCL5.
It shoud have a trigonalbipyramid geometry. UFF takes it to
a sqare base pyramid. All others collapse the molecule to SCL. ???

I do not know of a force field with correct trigonal bipyramidal
shapes. I may attempt to derive something for UFF, but it’s certainly
not published. I don’t know if our implementation of MMFF94 has
hypervalent corrections. Again, for these types of problems, please
file Open Babel bugs.

I have another query. I recently tried to draw a metal-hydrogen
bond. Avogadro does not allow this. Try for instance, drawing
a trans-(PH3)2PtClH hydride.

It’s possible, but you can’t have the auto-adjust hydrogens feature
enabled. At the moment, Open Babel cannot correctly guess the # of
missing hydrogens for metals. If you’d like to help me work out proper
rules Louis, it would really help!

Cheers,
-Geoff

On Tuesday 09 September 2008 04:58:32 Geoffrey Hutchison wrote:

On Sep 8, 2008, at 3:26 PM, jacob@math.jussieu.fr wrote:

Half-related: yesterday Gael got a crash in the Ghemical forcefield,
which was selected by default.

Well, I’d like to know about crashes.

But I thought I had set UFF to the default forcefield. If not, it’s
certainly in my local changes.

I just retried by erasing the config file, as of r1574, Ghemical is the
default.

Cheers,
Benoit

Hi.

On the other hand, take an hypervalent molecule like SCL5.
It shoud have a trigonalbipyramid geometry. UFF takes it to
a sqare base pyramid. All others collapse the molecule to SCL. ???

I do not know of a force field with correct trigonal bipyramidal
shapes. I may attempt to derive something for UFF, but it’s certainly
not published. I don’t know if our implementation of MMFF94 has
hypervalent corrections. Again, for these types of problems, please
file Open Babel bugs.

I found this today in a project I did not know about:
http://towhee.sourceforge.net/forcefields/uff.html

I am not shure that failiure of a force field can be qualified of bug.
Feature request ?

It’s possible, but you can’t have the auto-adjust hydrogens feature
enabled.

I overlooked this possiblity. One for me.

At the moment, Open Babel cannot correctly guess the # of
missing hydrogens for metals. If you’d like to help me work out proper
rules Louis, it would really help!

Cheers,
-Geoff

I am not shure I can contribute to this topic. Would it imply completing
the periodic table to include the various bonding or coordination
modes of each element? Some sort of templates for possible
geometries around a center? I first have to read the code to learn
how auto-hydrogens works.

Cheers,

Louis

On Sep 9, 2008, at 12:36 PM, Louis Ricard wrote:

I found this today in a project I did not know about:
http://towhee.sourceforge.net/forcefields/uff.html

Yes, Towhee was extremely helpful in writing my implementation of UFF.
I also worked with Bob Hanson of Jmol and Greg Landrum of RDKit.

I am not shure that failiure of a force field can be qualified of
bug.
Feature request ?

It’s a fine line. I agree that it doesn’t seem like a bug – it’s a
limitation of the force field as a technical point. But to the user…
Well, you saw this user report. They saw this as a bug in Avogadro.

It’s not “fair,” but it’s true.

I am not shure I can contribute to this topic. Would it imply
completing
the periodic table to include the various bonding or coordination
modes of each element? Some sort of templates for possible
geometries around a center?

I’ll save you the code reading. We need a few things:

  1. A set of rules for “likely valence” for all elements. For example,
    we expect Pt compounds to be 4-valent square planar, P is usually 3-
    valent pyramidal or 5-valent trigonal bipyramidal, etc.

UFF declared the types as:
1 - linear (sp)
2 - trigonal (sp2)
R - resonant/aromatic
3 - tetrahedral (sp3)
4 - square planar
5 - trigonal bipyramidal
6 - octahedral

That covers a lot of chemistry. I know there are 7-valent and 8-
coordinate, but these are rare.

  1. As you said, we need to code templates for possible geometries
    around a center. Right now, the code nicely handles sp, sp2, and sp3
    nicely. It obviously also needs to handle square planar, trigonal
    bipyramidal, and octahedral.

From my perspective, #1 is the most important – collecting a set of
expected valence and coordinate rules for all elements.

Cheers,
-Geoff

Quoting Geoffrey Hutchison geoff.hutchison@gmail.com:

I am not shure that failiure of a force field can be qualified of
bug.
Feature request ?

It’s a fine line. I agree that it doesn’t seem like a bug – it’s a
limitation of the force field as a technical point. But to the user…
Well, you saw this user report. They saw this as a bug in Avogadro.

It’s not “fair,” but it’s true.

Currently, a force field can crash avogadro. In order to be able to
claim that it’s not avogadro’s bug, the best thing to do is to have
the force-fields running in a separate process. I don’t know anything
about that stuff but:

  1. if the bandwitdth of data exchanged between avogadro and the
    forcefield is low enough, you could let them communicate with one
    another over DBus (In fact I don’t know anything about that, DBus
    might even allow passing heavy enough data structures).
  2. if the bandwidth is too high for DBus you could use shared memory.
    Qt provides cross-platform support for that.

Cheers,
Benoit

I am not shure I can contribute to this topic. Would it imply
completing
the periodic table to include the various bonding or coordination
modes of each element? Some sort of templates for possible
geometries around a center?

I’ll save you the code reading. We need a few things:

  1. A set of rules for “likely valence” for all elements. For example,
    we expect Pt compounds to be 4-valent square planar, P is usually 3-
    valent pyramidal or 5-valent trigonal bipyramidal, etc.

UFF declared the types as:
1 - linear (sp)
2 - trigonal (sp2)
R - resonant/aromatic
3 - tetrahedral (sp3)
4 - square planar
5 - trigonal bipyramidal
6 - octahedral

That covers a lot of chemistry. I know there are 7-valent and 8-
coordinate, but these are rare.

  1. As you said, we need to code templates for possible geometries
    around a center. Right now, the code nicely handles sp, sp2, and sp3
    nicely. It obviously also needs to handle square planar, trigonal
    bipyramidal, and octahedral.

From my perspective, #1 is the most important – collecting a set of
expected valence and coordinate rules for all elements.

Cheers,
-Geoff


This SF.Net email is sponsored by the Moblin Your Move Developer’s challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel


This message was sent using IMP, the Internet Messaging Program.

It came to me as an after thought that using point groups
as a basis for generating possible geometries may be a solution.
There is basic support for that in openbabel if I am wright.
It may be easier to implement than templates.

Along the same line, how to specify by hand the atom types?
Guess from the geometry may not be the best solution, although
it is “plus convivial” for some users.

Louis

Le 9 sept. 08 à 21:00, Geoffrey Hutchison a écrit :

I’ll save you the code reading. We need a few things:

  1. A set of rules for “likely valence” for all elements. For example,
    we expect Pt compounds to be 4-valent square planar, P is usually 3-
    valent pyramidal or 5-valent trigonal bipyramidal, etc.

UFF declared the types as:
1 - linear (sp)
2 - trigonal (sp2)
R - resonant/aromatic
3 - tetrahedral (sp3)
4 - square planar
5 - trigonal bipyramidal
6 - octahedral

That covers a lot of chemistry. I know there are 7-valent and 8-
coordinate, but these are rare.

  1. As you said, we need to code templates for possible geometries
    around a center. Right now, the code nicely handles sp, sp2, and sp3
    nicely. It obviously also needs to handle square planar, trigonal
    bipyramidal, and octahedral.

From my perspective, #1 is the most important – collecting a set of
expected valence and coordinate rules for all elements.

Cheers,
-Geoff


This SF.Net email is sponsored by the Moblin Your Move Developer’s
challenge
Build the coolest Linux based applications with Moblin SDK & win
great prizes
Grand prize is a trip for two to an Open Source event anywhere in
the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

Benoît,

Can you send an example file of such a crashing force field
calculation? The input file and the method used.

Louis

Le 9 sept. 08 à 21:57, jacob@math.jussieu.fr a écrit :

Quoting Geoffrey Hutchison geoff.hutchison@gmail.com:

I am not shure that failiure of a force field can be qualified of
bug.
Feature request ?

It’s a fine line. I agree that it doesn’t seem like a bug – it’s a
limitation of the force field as a technical point. But to the
user…
Well, you saw this user report. They saw this as a bug in Avogadro.

It’s not “fair,” but it’s true.

Currently, a force field can crash avogadro. In order to be able to
claim that it’s not avogadro’s bug, the best thing to do is to have
the force-fields running in a separate process. I don’t know anything
about that stuff but:

  1. if the bandwitdth of data exchanged between avogadro and the
    forcefield is low enough, you could let them communicate with one
    another over DBus (In fact I don’t know anything about that, DBus
    might even allow passing heavy enough data structures).
  2. if the bandwidth is too high for DBus you could use shared memory.
    Qt provides cross-platform support for that.

Cheers,
Benoit

Hi,

actually I’m the guy who had these crashes, but a "svn up openbabel"
fixed the problem, sorry for the noise.

gael.

On Tue, Sep 9, 2008 at 10:12 PM, Louis Ricard
louis.ricard@polytechnique.edu wrote:

Benoît,

Can you send an example file of such a crashing force field
calculation? The input file and the method used.

Louis

Le 9 sept. 08 à 21:57, jacob@math.jussieu.fr a écrit :

Quoting Geoffrey Hutchison geoff@geoffhutchison.net:

I am not shure that failiure of a force field can be qualified of
bug.
Feature request ?

It’s a fine line. I agree that it doesn’t seem like a bug – it’s a
limitation of the force field as a technical point. But to the
user…
Well, you saw this user report. They saw this as a bug in Avogadro.

It’s not “fair,” but it’s true.

Currently, a force field can crash avogadro. In order to be able to
claim that it’s not avogadro’s bug, the best thing to do is to have
the force-fields running in a separate process. I don’t know anything
about that stuff but:

  1. if the bandwitdth of data exchanged between avogadro and the
    forcefield is low enough, you could let them communicate with one
    another over DBus (In fact I don’t know anything about that, DBus
    might even allow passing heavy enough data structures).
  2. if the bandwidth is too high for DBus you could use shared memory.
    Qt provides cross-platform support for that.

Cheers,
Benoit


This SF.Net email is sponsored by the Moblin Your Move Developer’s challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

On Tue, Sep 9, 2008 at 9:00 PM, Geoffrey Hutchison
geoff.hutchison@gmail.com wrote:

On Sep 9, 2008, at 12:36 PM, Louis Ricard wrote:

I found this today in a project I did not know about:
http://towhee.sourceforge.net/forcefields/uff.html

Yes, Towhee was extremely helpful in writing my implementation of UFF.
I also worked with Bob Hanson of Jmol and Greg Landrum of RDKit.

I am not shure that failiure of a force field can be qualified of
bug.
Feature request ?

It’s a fine line. I agree that it doesn’t seem like a bug – it’s a
limitation of the force field as a technical point. But to the user…
Well, you saw this user report. They saw this as a bug in Avogadro.

It’s not “fair,” but it’s true.

Having a wiki page to explain this could help to clarify this. I added
http://avogadro.openmolecules.net/wiki/Tutorials:Force_fields. I also
wanted to add some images but keep getting an error:

Internal error
Could not create directory “public/e/ea”.

Tim

I am not shure I can contribute to this topic. Would it imply
completing
the periodic table to include the various bonding or coordination
modes of each element? Some sort of templates for possible
geometries around a center?

I’ll save you the code reading. We need a few things:

  1. A set of rules for “likely valence” for all elements. For example,
    we expect Pt compounds to be 4-valent square planar, P is usually 3-
    valent pyramidal or 5-valent trigonal bipyramidal, etc.

UFF declared the types as:
1 - linear (sp)
2 - trigonal (sp2)
R - resonant/aromatic
3 - tetrahedral (sp3)
4 - square planar
5 - trigonal bipyramidal
6 - octahedral

That covers a lot of chemistry. I know there are 7-valent and 8-
coordinate, but these are rare.

  1. As you said, we need to code templates for possible geometries
    around a center. Right now, the code nicely handles sp, sp2, and sp3
    nicely. It obviously also needs to handle square planar, trigonal
    bipyramidal, and octahedral.

From my perspective, #1 is the most important – collecting a set of
expected valence and coordinate rules for all elements.