Re: [AMBER-Developers] Experiences with sleap

From: Jodi Ann Hadden <>
Date: Sat, 5 Nov 2011 00:09:01 +0000

Maybe it boils down to how "AMBER development" is defined. I guess I define it as working on the code that is already there, that is "AMBER" to me. Fixing the bugs, optimizing it, adding new functionality, adding new modules to accommodate new functionality when augmentation/expansion of the code warrants it, and also rewriting some modules from scratch if that is the best way for the code to move forward. The brand you discuss seems to be more of writing your own AMBER-compatible code for your own purposes, adding it to the AMBER directory without regard to what functionality is already present, and then calling it part of AMBER.
I guess I just find it somewhat hypocritical to make the point you are an active developer and then turn around and state that you would not have contributed functionality if you had been asked to implement it in the existing code. Your arguments about flexibility seem to suggest you will only contribute to AMBER if it can be on your own terms, and I just don't think that is a good attitude to have when working on software maintained by a dynamic community. I am not trying to sound mean or otherwise ungrateful for all your generous contributions, but I have bothered to write because I think this debate is useful -- How development should be handled just seems like an important issue that should be clarified moving forward, for the sake of AMBER.

"I hope there will be forgiveness for me."

P.S. -- The excuse of "GROMACS is worse" is not at all a comfort... :-P

On Nov 4, 2011, at 6:52 PM, Jason Swails wrote:

> On Fri, Nov 4, 2011 at 3:36 PM, Jodi Ann Hadden <> wrote:
>> I don't know what the "official" AMBER development model is, but I feel
>> the model as Jason describes it is in some ways unacceptable. I understand
>> everyone is limited by time and resources and that the basic generosity of
>> people who contribute code is what allows progress and helps to increase
>> functionality in AMBER, but I feel failure of contributors to take into
>> account the "big picture" is detrimental to the software in the long term.
>> I get the impression from Jason that much contribution is coming from
>> independent users on a "crisis to crisis" basis. Basically that someone
>> requires some functionality that is not present in AMBER and so writes
>> their own code to do it, and because their concern is primarily toward
>> their own work and not AMBER overall, they perform this task in whatever
>> way is most convenient for them, in whatever language they know without the
>> extra effort of trying to incorporate it into an existing module. I'm not
>> necessarily calling that lazy because I know everyone has limited amounts
>> of time to donate, and I do find it generous that users would share their
>> code with AMBER, but I also think accepting so many standalone programs
>> with overlapping functionality constitutes a poor development model as it
>> encourages a "cobbled" consistency to the software.
> Yes. But my point is that we are not all software developers -- most of us
> are computational scientists, and the software development is a means to an
> end (doing our science). We are hardly the most "cobbled-together" package
> in our field -- look at gromacs. The reality is that we make a
> compromise. As an example, I'll use myself and parmed. I would say that
> I'm fairly committed to Amber development (more so than Adrian would
> probably like, since it slows my research down). I've done several things
> motivated only by Amber maintenance with no benefit to my research.
> However, if you were to tell me that parmed has no place in Amber because
> it overlaps with rdparm, and that I'd have to implement my ideas in rdparm
> to distribute it, I will continue using parmed extensively for my work and
> be content as the only person that has access to it.
> I don't think rules calling for "less flexibility" in development are a bad
>> idea. It seems to me that restricting the languages that AMBER modules
>> should be written in would be quite a good policy, actually, making
>> everything easier to maintain in the long run, easier to condense and
>> consolidate modules or transfer functionality between them when necessary,
>> easier for developers to contribute to multiple modules, etc. Having a
>> prmtop parser for every possible language is silly as it only encourages
>> cobbling. An excess of code where subsets of users only understand subsets
>> of the code due to a "language barrier" seems utterly detrimental to
>> progress, whereas a few common languages could have a unifying effect on
>> the code and improve communication among developers/contributors.
> I'm not suggesting infinite flexibility. But infinite rigidity will hinder
> and frustrate development (not to mention drastically increasing
> politicking, which is science's mortal enemy) -- there needs to be a
> compromise. And based on why we (as a collective) contribute to Amber, we
> need to be more flexible than the software engineering perspective would
> like.
> I think Dave understands this tradeoff well, which makes him an effective
> leader. We are rather free to do what we want, but the code is subject to
> the occasional "cleaning house" to trim it back down. His is a unique
> perspective on both the scientific advance and the software maintenance.
> As for the languages, Amber consists of Fortran, C, C++, csh, awk, sh,
> perl, and Python (and I was not the first to contribute a Python program to
> the tree). Different languages lend themselves to different tasks (it'd be
> ridiculous to try and write leap in Fortran, for instance, and as Wei
> stated, it wants to be C++, but only C was around when it was written).
> While some restrictions make sense (don't use languages that aren't
> generally supported on most systems, for instance), to preclude any of the
> ones we use above is foolish. But OK, if we need restrictions: No Java, no
> LISP, no Ruby, no C# :)
> And I don't think such a restriction would discourage contributed
>> development. There are plenty of people with enough passion for the science
>> and the software who want to be involved in something bigger than their own
>> work who will still be interested in contributing directly to AMBER -- in
>> terms of the existing software as well as new modules with novel
>> functionality -- even if it does mean learning a new language. What is so
>> wrong with that? I relish an excuse to learn a new language! That people
>> have a desire to be involved is evidenced by the fact that they share their
>> code at all.
> It wouldn't eliminate it, but it would certainly discourage it, at least
> for me (and I'd like to point out that I'm a fairly active developer). I
> have nothing against learning a new language, but I have no interest in
> trying to coerce a language to do what I want it to do when another one is
> tailored better to the problem (i.e. trying to write leap in C or ptraj in
> C). It also doesn't make sense to write something like MM/PBSA in a
> compiled language -- perl or Python are much better choices.
>> I guess I think, based on the impression I got from Jason's email, that
>> perhaps development is being encouraged in the wrong way. If users want to
>> contribute, they should be encouraged to work with other AMBER developers
>> to incorporate their ideas into existing AMBER or design a coherent,
>> foresighted new module in AMBER to accommodate it, instead of just cobble
>> something else on that is of limited use due to overlap, language barriers,
>> hard to read/poorly documented, etc. That way, the devs already familiar
>> with the code get a handle on the new functionality, and the new
>> contributor gains knowledge of how the existing code works.
> It's a fantastic policy on paper. It's not detailed, though. As Ben put
> it so succinctly, this is "making the perfect the enemy of the
> achievable". The multiplicity isn't as bad as it's being made out to be,
> so it'll be easy to address each case individually at the meeting, after we
> make our case for its inclusion.
>> This cross-communication and redundancy, not in the code but in the people
>> who understand the code, seems the best way to manage streamlined software
>> maintained by a community. "Rip it out if you can't maintain it after I'm
>> gone" is unacceptable.
> It's not unacceptable, it's experimentation. If it doesn't catch on, it's
> not maintainable, so it dies. If it does catch on, there's interest in it,
> so it continues to be maintained and developed. In the previous case, it's
> as though it was never there. In the latter case, Amber benefits from a
> good program.
> All the best,
> Jason
> --
> Jason M. Swails
> Quantum Theory Project,
> University of Florida
> Ph.D. Candidate
> 352-392-4032
> _______________________________________________
> AMBER-Developers mailing list

AMBER-Developers mailing list
Received on Fri Nov 04 2011 - 17:30:04 PDT
Custom Search