Guys,
As far as I know, we are incredibly loose on design change at interfaces
issues. However, we absolutely cannot be cavalier about changing things
like the prmtop or inpcrd, unless we are trying to sabotage ourselves.
File
format changes should be 1) backward compatible, somehow (ie., your code
should be able to deal with old formats and at least die intelligently if
you are asked to do the impossible), 2) subject to design review by the
whole bloody team, so that you don't blow somebody out of the water, and
3)
thoroughly, thoroughly documented. We are talking interfaces here when we
are talking common file formats, and when you break interfaces you cause
yourself and your colleagues endless grief. Just a strong opinion, based
on
strong experiences. You would get crucified for breaking something like
this in any serious s/w dev organization I have ever been part of. The
other part of this whole issue is that things that end up codified in file
formats should be designed with an eye to the future. That way you don't
end up mucking about trying to figure out whether the atom count is in 5
or
6 digits, etc. etc. I know there has been some effort in this direction
with the new prmtop, and I applaud it. Let's be careful to not lose sight
of the importance of this.
Regards - Bob
----- Original Message -----
From: "Yong Duan" <duan.ucdavis.edu>
To: <amber-developers.scripps.edu>
Sent: Thursday, November 10, 2005 7:26 PM
Subject: amber-developers: Excluded list ?
>
> Just realized that sander actually re-constitutes the excluded list from
> bond, angle, dihedral lists. Any insightful comments why it has to be
done
> this way? What will happen if I disable this (i.e., remove the code)? I
> need
> some flexibility in the excluded list but don't like to break too many
> things :(.
>
>
> yong
>
>
Received on Wed Apr 05 2006 - 23:49:50 PDT
