> 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
I am sorry Jason but I have to disagree here. Using the excuse that one is
not a software developer as an excuse to be sloppy. If you want to
contribute to AMBER and have other people use your code, and in return you
benefit by being associated with the AMBER project then I think it is quite
reasonable for people to expect you to stick to a defined set of rules and
approaches. If you look at the reason a lot of people use AMBER it is
because it is not as cobbled together as others. With the current approach
that is going on here, with people hiding behind the premise that 'we are
scientists, not programmers so we can be lazy and do what we want' then we
run the risk of just going further down the anarchy route we have started
on.
> 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.
This is good and everyone is happy for this. I would encourage others to do
this as well. I know we are all very busy but everyone associated with AMBER
benefits from that so I think people should try to take some more of their
time to give back.
> 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.
This is NOT what you are being told. What is being suggested is that right
now we have a bunch of people developing random tools, most of which are
useful but they are all totally disjoint and essentially random.. I think it
is perfectly reasonable to assert we should try to make AMBER as coherent as
possible. With parmed you have proven a concept. That prmtops can be
modified. The next step should be, if you want such a thing to be part of
AMBER, and thus benefit from the citations etc AMBER brings then you should
consider how to incorporate this into a more coherent package. In my opinion
this means it should be incorporated into ptraj or cpptraj. Depending on
which we decide should be the definitive package moving forward. Otherwise
we continue to encourage people making their own little tools hacked up for
this or that, and AMBERTools just becomes a dumping ground for everyone's
pet project. I think this is bad for AMBER and will come back to bite us all
in the arse later.
> 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,
Exactly. We need some leadership here. I propose that we have a subset of
developers meet at the AMBER meeting and define a set of rules about what
should and shouldn't be allowed in AMBER. Since with a project as large as
AMBER it is vital that there are a decent set of rules, and somewhat of a
dictatorship control at the top or we just end up with a total mess like we
have now.
> we
> need to be more flexible than the software engineering perspective
> would
> like.
I do not think we do. That is just catering to the fact that people do not
want to necessarily take the effort to do things in a way that is consistent
with the rest of the code.
> 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
It would be great. If we actually had a cleaning of the house! But look at
what has happened to things over the last couple of years. It has turned
into a complete disaster. It would be much easier if we had kept the house
clean in the first place.
> perspective on both the scientific advance and the software
> maintenance.
In my opinion the experiment that is AMBERTools is heading rapidly for
failure and we need to do something radical quickly to stop it turning into
a complete unmaintainable mess. I am certainly getting ready to totally wash
my hands with most of it.
> 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
Actually no, I disagree. I think it is perfectly reasonable and in fact
REQUIRED for a large size project to place severe restrictions on the
languages that can be used. This makes maintenance significantly easier, it
makes portability much better and it makes it easier to have sustainable
code once whichever grad student who wrote 'cool module x' has disappeared
off into the great blue yonder. Sure it might not be 'the perfect' tool for
XYZ but it maintains consistency. I think it is about time some of the PIs
involved here started enforcing such restrictions on their graduate students
since this is the only way we are going to maintain broad support moving
forward. The resolution is that "You might not like it, you might think this
is painful and tedious but if you want your work to benefit from having your
code used by many other people as part of AMBER then this is how you are
going to do it." If the person whines to much then it is their loss since
their contribution doesn't end up being incorporated.
> Java, no
> LISP, no Ruby, no C# :)
I think we need more restrictions. Ideally we should have something like:
Fortran 90 (or a version we decide on), C, C++, sh (I concede to Dave we
should not require bash. No csh either). Perl and awk should be restricted
to utility scripts only. Python we could consider EXCEPT it has all the
issues associated with versioning etc that C, C++ etc do not and it is a
pain in the arse to interface it with the codes written in Fortran, C, C++
etc - which I might note can all be linked together if need be - probably
the best way to parse prmtops in C would be to have a fortran prmtop reading
library written. Thus I also think we should steer away from python. By all
means prototype in it but if you want it included in AMBER you should
convert it to something like C++ so it can be incorporated in the main
programs.
> 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.
But again I make my point. AMBER is a package that we VERY widely
distribute. For this reason it is not necessarily appropriate for you to
have your choice of "this language is xx% better than this one etc". At the
end of the day, tough shit. These are the choices you have because we should
focus on making sure it runs on everything, can be maintained by as many
people as possible etc and therefore you might have to take the sacrifice of
writing your chosen idea in an non-ideal language.
> > 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
You are confusing the development of AMBER here with your own research. They
are actually distinctly different things. What you are thinking, I believe,
is that the policy would restrict how one would do their research. This is
not the case. If you want to write tools for your research fine. But AMBER
should not become a dumping ground for every little script people write. If
the functionality is useful one should take the time to carefully add it to
one of the existing tools to maintain the feel and usability of AMBER.
> 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.
I disagree - the multiplicity right now is terrible. Look at what a pain in
the arse things have become. Go try compiling AMBER Tools on an IBM AIX
machine. Try a Blue Gene. Try a machine that only has GCC4.1 in fact. What
if the machine doesn't have the version of python we want etc etc. I think
people forget that there machines for running AMBER don't end at ones
desktop where one has root and can install anything they want. Hence
simplicity and a lack of dependency on things is critical. Some of these
people might not realize. For example I didn't realize you don't have bash
on freebsd but now I do. But, for example the GCC4.1 issue - that should get
fixed. Not the copout of saying - oh you need GCC 4.4 or later... Great!!
Now please go and do all the paperwork and bureaucracy involved in getting
supercomputer XYZ which runs REDHAT 5 - perfectly modern in the server arena
- updated. I think people need to start thinking beyond their linux / mac
osX desktop when they develop things here and one way of maximizing the
chances of things working widely is to reduce the complexity.
> 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,
Great... So we are continually experimenting in what most people consider a
production package for scientific research. Ugh!!! Great idea... :-(
And I believe your premise about the maintained and developed if it is
interesting is wrong. What you are effectively saying is.. I made this great
tool and look it does this cool stuff and people decide they like it. Then
you disappear off and some poor other bugger has to try to incorporate that
into the main programs to give some consistency. This is something YOU
should have done in the first place.
All the best
Ross
/\
\/
|\oss Walker
---------------------------------------------------------
| Assistant Research Professor |
| San Diego Supercomputer Center |
| Adjunct Assistant Professor |
| Dept. of Chemistry and Biochemistry |
| University of California San Diego |
| NVIDIA Fellow |
|
http://www.rosswalker.co.uk |
http://www.wmd-lab.org/ |
| Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
---------------------------------------------------------
Note: Electronic Mail is not secure, has no guarantee of delivery, may not
be read every day, and should not be used for urgent or sensitive issues.
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Fri Nov 04 2011 - 17:00:03 PDT
