Hi Jason,
I agree the new approach is SOOOO much better than the old one. Given your
explanations my vote is that we just silently replace the configure with an
ever so slightly modified configure in the AmberTools tar file, update the
md5sum and then not worry about it. I know this goes against our normal
approach to things but it seems an easy way to do it. Could we perhaps
release this as a bugfix for configure? Then effectively include that bugfix
within the AmberTools tar file and that way patch_amber.py would detect that
the configure is already applied but people without the updated AmberTools
tar file would automatically get their distribution patched such that it
would have the same configure as the one in the new tar file?
That way we also avoid the issue if we have to have an additional patch to
patch_amber.py which would mean people running configure 3 times using the
current approach.
What do you think? - Would that work?
ps. As for the GPU code being 'advanced and experimental', I have totally
given up on saying that - people really just don't care an plough on anyway
irrespective of what is said. ;-)
All the best
Ross
> -----Original Message-----
> From: Jason Swails [mailto:jason.swails.gmail.com]
> Sent: Thursday, June 28, 2012 1:35 PM
> To: AMBER Developers Mailing List
> Subject: Re: [AMBER-Developers] Having to run configure multiple times
>
> I'll contribute my 2c, since this situation is an unfortunate result of
> my
> oversight (though I will try to keep this brief and omit excuses).
>
> patch_amber.py *must* quit if it detects a patch to itself, since later
> patches assume they will be applied with the *fixed* script (I actually
> considered this decent foresight at the time). The appropriate
> solution
> (currently in the git tree for 13), is to have configure continue to
> run
> patch_amber.py until it is done applying patches, but this is not the
> case
> for AmberTools 12.
>
> Also, because of how patch_amber.py does bookkeeping, patches should
> never
> be changed or re-ordered.*
>
> Options are:
>
> 1) We could change the AmberTools 12 release tarball to include this
> new
> configure script so that when new users download AT12, it will
> automagically work. Existing users, in all likelihood, have already
> applied bugfix.3 (since they configured at least once already), so this
> issue doesn't apply to them anymore.
>
> 2) Not worry about it for reasons below:
>
> --There is only one patch that fixes patch_amber.py, which means
> patch_amber.py will stop only once. Therefore, you don't have to run
> configure twice each time you want to build. Once AT bugfix.3 is
> applied,
> this will never happen again. Only if you have a regular habit of
> building
> a completely fresh tree each time you want to try something will
> 'forgetting' be an issue.
>
> --If you install more than one Amber variant, (e.g., serial and CUDA
> and/or
> MPI and/or cuda.MPI), the second build you do will pull in the
> remaining
> patches (very verbosely, and interactively so there's no chance you'll
> miss
> it).
>
> --We already tell people that pmemd.cuda is an advanced program for use
> only when you have the CPU code working well for your system. Ergo, if
> people build the CPU code first, the GPU build will pull in all
> necessary
> patches.
>
> --The instructions on the bugfix12.html page provide instructions about
> running patch_amber.py (currently it just redirects to my Wiki
> discussion
> about it, but I will add brief, explicit instructions there).
>
> --"./patch_amber.py --patch-level" will report the applied bug fixes,
> so
> there is little chance that users will be confused about which patches
> they
> have applied.
>
> --In the release email sent out to the list, say "<press release about
> GPU
> patch>, to obtain this update, run "patch_amber.py --update" to
> automatically download and apply this patch (maybe a note about looking
> at
> the output to see if you have to run it twice, although since configure
> runs it, it really only has to be done once)"
>
> IMO, this is still easier than the past approaches, and patch_amber.py
> also
> has a helpful AMBERHOME check built in to make sure it's set correctly.
>
> I realize that it's not ideal, and I'm sorry (and frustrated) I
> overlooked
> this. Regardless of which avenue we decide to pursue (i.e., option 1
> or
> option 2), the work will be minimal on our part (if we opt for #2, I'll
> go
> ahead and do that now ;)).
>
> Thoughts?
> --Jason
>
> *The only time we should change a patch is if we immediately realize it
> was
> placed in the wrong repository, then it should be switched soon before
> (many) people have a chance to apply it. check_patches.py is there to
> catch as many mistakes as possible, so please try and use it.
>
> On Thu, Jun 28, 2012 at 3:46 PM, Ross Walker <ross.rosswalker.co.uk>
> wrote:
>
> > Hi All,
> >
> > With regards to the patch_amber.py script and configure automatically
> > applying bugfixes. Right now one has to always run configure twice
> (for a
> > clean tree) in order to make sure all the bugfixes are applied. This
> is not
> > obvious to most users - even I forget to do it most of the time and
> so only
> > get the first 3 AmberTools bugfixes apply and a message from
> patch_amber.py
> > saying it will quit - which makes me thing configure will quit but of
> > course
> > it doesn't.
> >
> > It would nice if we could figure out a workaround for this so users
> don't
> > have to worry about it. The issue is, I assume that we can't fix
> configure
> > retroactively in the release to check the return status of
> patch_amber.py
> > and we similarly can't patch patch_amber.py in an automated fashion
> such
> > that it keeps applying the bugfixes.
> >
> > On idea I had that might work is to move bugfix.3 to always be the
> LAST
> > bugfix applied. This would mean moving it to the AMBER bugfixes and
> > continually updating it when we add new bugfixes but at least that
> would
> > work around this problem. I guess we could call it bugfix.999 so it
> is
> > always the last one (although I haven't looked at patch_amber.py to
> see if
> > it can handle gaps in the bugfix numbering.)
> >
> > If we can find a reasonable way around this though I think it would
> be
> > helpful. I suspect right now that a LOT of people (I know I do it all
> the
> > time) are building their serial CPU code with just the AMBER Tools
> bugfixes
> > 1 to 3 applied and it is only when they run configure again for
> parallel or
> > cuda that they actually get all the bugfixes. The issue will be when
> we
> > release the very large kepler patch shortly since I am also betting
> there
> > are a lot of people who only build the GPU code and so their serial
> CUDA
> > build from a clean tree will not get the new bugfix unless they run
> > configure twice.
> >
> > I know Jason's wiki says to run the patch_amber.py script before
> configure
> > but since configure supposedly runs this anyway I am betting a lot of
> > people
> > skip / don't know they need that additional step.
> >
> > Comments or suggestions?
> >
> > 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
> >
>
>
>
> --
> Jason M. Swails
> Quantum Theory Project,
> University of Florida
> Ph.D. Candidate
> 352-392-4032
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Jun 28 2012 - 14:00:05 PDT
