Re: [AMBER-Developers] Ideas about a reorganization of the Amber manuals

From: Jason Swails <>
Date: Sun, 26 Jan 2014 16:33:19 -0500

On Sun, Jan 26, 2014 at 1:48 PM, David A Case <>wrote:

> Hi everyone: I want to expand here on some ideas about documentation that
> came up at the recent Amber Developers' Meeting.
> The current Amber manuals (Amber12.pdf and AmberTools13.pdf) are divided
> that
> way to reflect licensing distinctions between the two parts of the code.
> This never really made a lot of sense, and will be less important now that
> we are changing the licensing of sander.
> In my own thinking, I decided start over, hypothetically merging everything
> into one manual. We can decide later how it might be divided, e.g. for
> printing or other purposes. Below is a tentative table of contents for
> this
> merged Manual.
> [NOTE: we won't be actually doing anything to files in the git repo for a
> while; please continue to proofread and update the Manual files as you have
> been doing.]
> Amber 14 Manual
> Part I. Introduction, installation and testing
> combines chap. 1 of AmberTools and Chapter 1 of Amber
> Part II. Amber force fields
> Molecular mechanics force fields (expanded from Chap 2 of AmberTools;
> add Amoeba material from Amber manual)
> Implicit solvent models (to contain the relevant parts of Chap 3 from
> the Amber manual (for GB) , plus Chap. 10 (PBSA) and Chap. 11 (RISM)
> from AmberTools
> QM/MM (Chaps 3.6 to 3.8 of current Amber manual, plus Chap 7 on sqm
> from
> AmberTools)
> EVB (Chap. 3.4 of Amber manual)
> GAFF and antechamber (Chap. 5.1 to 5.5 from AmberTools)
> MCPB (Chap. 5.6 from AmberTools)
> Part III. System preparation
> Chaps 3 and 4 of AmberTools (LEaP and parmed, etc.)

I think MCPB belongs more in this part than Part II (or wherever we put
antechamber, parmchk, etc.)

> Part IV. Running simulations
> Chapters 2,4,5,6,7,8 from current Amber manual;
> Chapter 13 on mdgx from AmberTools
> Chapters 15-20 on NAB from current AmberTools manual;
> Part V. Analysis
> cpptraj (Chap 8 from AmberTools)
> (Chap. 12 from AmberTools)
> MMPBSA/FEW (Adapted/expanded from Appendix D of Amber manual)
> AmberLite (Chap. 6 of AmberTools)
> Crystal analysis (mostly new)
> etc.
> Appendices, etc.
> As discussed at the meeting, it might make good sense to split out Part II
> above (on force fields) into a separate document, and add to it info about
> using the Amber force field in other programs. If we do go back to
> physically
> printing and binding the Manuals, a spiral-bound book (which is the only
> kind
> that really works) has a maximum of about 400 pages.

I wonder if we have enough material to split out another manual (or section
of a manual). I think that Amber is beginning to become a little more
programmer-friendly, and it may be worthwhile to put API and programming
documentation in a separate manual that is appropriately labeled. Examples
of what would go in here would be the NAB language reference and
programming guide (Ch. 15 - 20 of AmberTools), the cpptraj developer's
manual (if it's still relevant to the current version), the ParmEd and Python APIs (section 12.4 and most of subsection 3.2.5 in the
AmberTools manual), and documentation about some of the other Python
classes that are present in the code, and the MDGX API (this last part
would be a WIP since Pawel is going to clean this up quite a bit).

While programmers probably make up a small fraction of our total user base,
I think it might be helpful to split this part out. That way it won't
clutter the user's manual with programming details for non-programmers and
it will give programmers an easy way to find out how they can interact with
Amber's functionality in their own programs.

Just a thought...

All the best,

P.S. I think it's worth trying to keep the manuals small enough that it can
be bound, IMO (I like hard copies).

Jason M. Swails
Rutgers University
Postdoctoral Researcher
AMBER-Developers mailing list
Received on Sun Jan 26 2014 - 14:00:02 PST
Custom Search