Dear Nicholas,
> Having a great deal of trouble trying to find a workaround to this
> issue. It's been posted about before and it's been deemed unecessary
> to fix, however I feel this bug is something that needs attending to.
I think there is no workaround; the Tripos mol2 file format is simply
used in different contexts. This might mean there are several Tripos
mol2 file formats ;-)
> Strictly speaking, mol2 files should be self-sufficient units which
> can be plugged into other tools for
> visualisation/modification/simulation. The format of the mol2 file
> output from leap is incorrect, both in terms of how it deals with
> connectivity (double/triple bonds labelled incorrectly as single
> bonds) and how it labels atoms (enters data other than the standard
> SYBYL atom types). This means that mol2 files are only useable for
> amber, which is giving me a lot of trouble (I am using the c++
> OpenBabel distributable for atomic modifications).
Several points here:
-1 The savemol2 command was originally developed at:
http://q4md-forcefieldtools.org/Tutorial/leap-mol2.php
We recently redirected this format and created the mol3 file format:
http://q4md-forcefieldtools.org/Tutorial/leap-mol3.php
-2 Historically the mol2 file format strongly connects to the Tripos
force field; But the mol2 file format has been redirected in the
context of the Amber force fields; Is the Tripos force field still
used ? I mean compared to the last Amber force field developments? I
am not sure...
-3 leap is not a 'graphical' program, it is force field oriented and
consequently amber force field oriented; thus a double or triple bond
does not exist in a force field (represented by a different force
field constant); so strictly there is no need to provide this
information in a force field library such as a mol2 file; obviously
this can be disturbing, when one is interested in visualizing a
structure in a graphical program. Thus displaying a structure in the
context of a graphical program such as vmd or in the context of a
force field tool can have different objective (in the context of a
force field library two atoms cannot share the same name in a given
residue)
> If anyone else has encountered this issue and knows of a workaround
> then please let me know! I need to be able to obtain
> self-sufficient mol2 (or any other format with well-defined
> connectivity/bond-order) in order for OpenBabel to be able to
> interpret structures correctly.
Openbabel has also its own limitations:
From what I know it does not print the "substucture" section; which
is quite painful... So here I do not like using Openbabel, but use our
q4md-forcefield tools to deal with Tripos mol2 or now mol3 files.
Just my personal opinion...
regards, Francois
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Mar 20 2014 - 01:00:03 PDT
