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
Received on Thu Jun 28 2012 - 14:00:03 PDT
