possible FAILURE: check md_A.o.dif
/media/work/slegrand/amber/test/cuda/gti/NMR_Restraint/SimpleTorsion
477c477
< NSTEP = 4 TIME(PS) = 0.004 TEMP(K) = 138.26 PRESS =
0.
> NSTEP = 4 TIME(PS) = 0.004 TEMP(K) = 138.08 PRESS =
0.
478c478
< Etot = -17372.9220 EKtot = 1435.5677 EPtot =
-18808.4897
> Etot = -17374.8225 EKtot = 1433.6672 EPtot =
-18808.4897
possible FAILURE: check md_B.o.dif
/media/work/slegrand/amber/test/cuda/gti/NMR_Restraint/SimpleTorsion
505c505
< NSTEP = 4 TIME(PS) = 0.004 TEMP(K) = 138.26 PRESS =
0.
> NSTEP = 4 TIME(PS) = 0.004 TEMP(K) = 138.08 PRESS =
0.
506c506
< Etot = -17372.9220 EKtot = 1435.5677 EPtot =
-18808.4897
> Etot = -17374.8225 EKtot = 1433.6672 EPtot =
-18808.4897
possible FAILURE: check md_C.o.dif
/media/work/slegrand/amber/test/cuda/gti/NMR_Restraint/SimpleTorsion
506c506
< Etot = -17617.4773 EKtot = 1279.9654 EPtot =
-18897.4427
> Etot = -17617.4914 EKtot = 1279.9513 EPtot =
-18897.4427
516c516
< Etot = -17617.4773 EKtot = 1279.9654 EPtot =
-18897.4427
> Etot = -17617.4914 EKtot = 1279.9513 EPtot =
-18897.4427
On Tue, Nov 10, 2020 at 3:20 PM David Cerutti <dscerutti.gmail.com> wrote:
> None from me--how many steps in do the changes appear?
>
> On Tue, Nov 10, 2020 at 5:54 PM Scott Le Grand <varelse2005.gmail.com>
> wrote:
>
> > So, not surprisingly, *fixing* this GTI-dependent change, breaks 3 GTI
> > tests in DPFP suggesting that this is not a valid optimization to me.
> > Looking at the diffs, I propose updating the reference outputs. Any
> > objections?
> >
> > On Tue, Nov 10, 2020 at 12:57 PM Scott Le Grand <varelse2005.gmail.com>
> > wrote:
> >
> > > I suspect we could calculate a safe number of steps past a rebuild to
> > skip
> > > in your turbo mode. But that's for another day. This code needs to
> go...
> > >
> > >
> > > On Tue, Nov 10, 2020 at 12:56 PM David Cerutti <dscerutti.gmail.com>
> > > wrote:
> > >
> > >> Yep. skin_permit should avoid rebuilds if the test passes the more
> > >> permissive threshold. And I do actually seem to remember seeing that
> > >> code,
> > >> or something to the effect "don't rebuild pair list if we just created
> > it"
> > >> in the comments as I was working on the turbo mode. So whatever that
> > code
> > >> is, it is pretty ancient and may affect test cases if we purge it,
> even
> > >> though that is probably a good idea.
> > >>
> > >> Dave
> > >>
> > >>
> > >> On Tue, Nov 10, 2020 at 3:51 PM Scott Le Grand <varelse2005.gmail.com
> >
> > >> wrote:
> > >>
> > >> > So looking at skin_permit, it looks like I can blow away this junk
> and
> > >> > skin_permit will do the rest?
> > >> >
> > >> > On Tue, Nov 10, 2020 at 12:16 PM Scott Le Grand <
> > varelse2005.gmail.com>
> > >> > wrote:
> > >> >
> > >> > > ~line 2000 of kNeighborList.cu:
> > >> > >
> > >> > > extern "C" void kNLSkinTest(gpuContext gpu)
> > >> > > {
> > >> > > static unsigned counter = 0;
> > >> > > static unsigned lastCounter = gpu->sim.skinnb * 14;
> > >> > >
> > >> > > int counterCut = lastCounter*0.2;
> > >> > > unsigned interval = 1;
> > >> > > if (counter++ > counterCut && (counter % interval) == 0) {
> > >> > >
> > >> > > etc...
> > >> > >
> > >> > > Not only is this uncool, it's done with local static variables
> which
> > >> is
> > >> > > just horrible...
> > >> > >
> > >> > > On Tue, Nov 10, 2020 at 12:07 PM David Cerutti <
> dscerutti.gmail.com
> > >
> > >> > > wrote:
> > >> > >
> > >> > >> I wasn't aware of the code doing anything like NB skin tests only
> > >> every
> > >> > >> other step. The "turbo" mode is enabled by setting skin_permit
> to
> > a
> > >> > value
> > >> > >> between 0.5 and 1.0. See here:
> > >> > >>
> > >> > >> http://ambermd.org/GPUPerformance.php
> > >> > >>
> > >> > >> Where in the code is the call to the pairlist check being skipped
> > on
> > >> > half
> > >> > >> the steps?
> > >> > >>
> > >> > >> Dave
> > >> > >>
> > >> > >>
> > >> > >> On Tue, Nov 10, 2020 at 2:03 PM Scott Le Grand <
> > >> varelse2005.gmail.com>
> > >> > >> wrote:
> > >> > >>
> > >> > >> > At some point, PMEMD stopped doing NB skin tests every step and
> > it
> > >> now
> > >> > >> does
> > >> > >> > them every other step. No matter what your view on the validity
> > of
> > >> > doing
> > >> > >> > so, doing this under the hood all the time without informing
> the
> > >> user
> > >> > is
> > >> > >> > uncool to the max.
> > >> > >> >
> > >> > >> > I am turning this off by default. Any objections? Dave, how
> does
> > >> one
> > >> > >> enable
> > >> > >> > your turbo mode? Because this seems cool there, just not on
> 100%
> > of
> > >> > the
> > >> > >> > time with no option to turn it off.
> > >> > >> >
> > >> > >> > Scott
> > >> > >> > _______________________________________________
> > >> > >> > 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
> > >> > >>
> > >> > >
> > >> > _______________________________________________
> > >> > 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
> > >>
> > >
> > _______________________________________________
> > 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
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Tue Nov 10 2020 - 15:30:02 PST
