Re: mol2 file format in the future of amber

From: M. L. Dodson <bdodson_at_scms.utmb.EDU>
Date: Sun 22 Sep 2002 10:34:06 -0500 (CDT)

On 22 Sep, David A. Case wrote:
> On Fri, Sep 20, 2002, M. L. Dodson wrote:
>> I have seen sporadic references to the use of the mol2 file format in
>> amber future development (in place of prep and frcmod files, IIRC).
>> Would anyone be able to furnish a paragraph or so of explanation of how
>> this would work? I do some special residue description development for
>> my work, and would like to make sure the scripts, etc. I write will not
>> need to be rewritten for the next version. For example, is there/will
>> there be a "prep2mol2" program available (other than the capabilities
>> built into antechamber or tleap)? Does this question even make sense?
>> :-)
> Basically, even in Amber7 one can use mol2 files for most things. You
> have to use "mol2_to_off" to convert those to something LEaP can read;
> the next version of LEaP will read mol2 files natively.
> Antechamber can already read and write mol2 files, although there are some
> minor glithces and annoyances that will be fixed up. In addition, antechamber
> can convert prep to mol2 files already, so I don't see any need for a separate
> "prep2mol2" program.

That was what I thought was the situation. I just wanted to confirm
that was the case so I could confidently write scripts using that
functionality rather than a stand alone program. Thanks for the reply.

Glad to hear about the future improvements for antechamber. The idea
is great, but it does have some, hmmmmm, peculiarities. :-)

> We will probably continue to support the "prepi" format, for backwards
> compatibility, but I would prefer to retire that file format, since it is
> not all that well documented, and it really offers nothing not available for
> mol2.

:-) Actually, I like the prep format (it seems substantially
selfdocumenting), but I see your point.

> The "off" format will continue to be used for libraries in LEaP, and is needed
> for free energy perturbation, where there is a need to store both the
> perturbed and unperturbed atom types and charges.

That gives me some cause for new thought. I have mostly tried to ignore
the off format before now for substantially trivial reasons: early on,
the off format did not work with FreeBSD, the OS I prefer, so my efforts
were focused on workarounds for that situation. Now that it works fine
on FreeBSD, I'll need to consider that a more viable option than I have
in the past.

> ..hope this helps...dac

Thanks again.
Bud Dodson

M. L. Dodson                      
409-772-2178                                FAX: 409-772-1790
Received on Sun Sep 22 2002 - 08:34:06 PDT
Custom Search