Yes, I was just looking over the code that Scott pointed out with regard to
CPU versus GPU netfrc correction when extra points are involved. The CPU
code shifts the force on extra points along with everything else, AFTER
averaging the net force correction to apply to the number of particles with
actual mass, then obliterates the correction that has been applied to the
extra points. It's a kludge but it works, in the end (and the CPU code
does conserve energy with my new extra point frames).
All that I have done is designed to occur at the define_frames step and
then get carried forward, whether in the CPU code or into the GPU code, so
the netfrc correction will occur the same way on my new frames. One thing
I did toy with a bit was "frameon," but that was just to make sure that
frameon did get set to "ON" when even custom extra points were included.
So if you ever deal with "frameon" in your netfrc coding and you see odd
behavior, shoot me a mail.
Dave
On Fri, May 22, 2020 at 4:20 PM <cancersimulation.gmail.com> wrote:
> It is static. Usually, it should be the same as "numextra" here
>
> use prmtop_dat_mod, only : numextra
>
> I believe Dave Cerutti has implemented some extra-point stuff and I don't
> know if the above statement still holds with his stuff.
>
> Taisung
>
> -----Original Message-----
> From: Scott Le Grand [mailto:varelse2005.gmail.com]
> Sent: Friday, May 22, 2020 3:02 PM
> To: AMBER Developers Mailing List <amber-developers.ambermd.org>
> Subject: Re: [AMBER-Developers] Faster NetFrc
>
> So also...
>
> I would assume the value of "ignored" is static. How do I calculate it a
> priori? And it looks like I don't apply it to the extra points. Feel free
> to
> describe off-list, but I want to drill down deep and get this right on the
> first swing...
>
> On Thu, May 21, 2020 at 6:08 PM Scott Le Grand <varelse2005.gmail.com>
> wrote:
>
> > Excellent, that makes this much more straightforward. Should have
> > something by early next week.
> >
> > On Thu, May 21, 2020 at 6:04 PM <taisung.gmail.com> wrote:
> >
> >> The force thresholds are for those "dummies" (not the alchemical
> >> dummies but something like lone-pair points of water models). The
> >> forces of those atoms are "transferred" to other real atoms at the
> >> final force collection stage--and hence need to be kept to zero
> >> during the netfrc stage. Of course, you may find better ways to do
> >> things. For example, as Scott mentioned, the only non-conserved
> >> force part is PME reciprocal part. If the netfrc is done in the PME
> >> reciprocal part, there is no need to have such force thresholds.
> >>
> >> Taisung
> >>
> >> -----Original Message-----
> >> From: David Cerutti [mailto:dscerutti.gmail.com]
> >> Sent: Thursday, May 21, 2020 8:37 PM
> >> To: AMBER Developers Mailing List <amber-developers.ambermd.org>
> >> Subject: Re: [AMBER-Developers] Faster NetFrc
> >>
> >> As implied, the GTI code is the revision that introduced this.
> >> Taisung can comment more on his logic, but the presence of this
> >> "small" term reminds me of something he's got in the non-bonded inner
> >> loop as well. I'm not sure we ever determined why these conditionals
> >> were needed; I think the one in the non-bonded loop should just go
> >> away after some other revisions I made, but I'll wait for more input.
> >>
> >> Dave
> >>
> >>
> >> On Thu, May 21, 2020 at 8:29 PM Scott Le Grand
> >> <varelse2005.gmail.com>
> >> wrote:
> >>
> >> > Hey guys,
> >> > Back as an AMBER developer and one of the first things I'd like to
> >> > do is optimize netfrc.
> >> >
> >> > Fixed point conservative forces have no net force. They
> >> > automagically cancel out 100%. So we can ignore everything except
> >> > non-conserved
> >> forces.
> >> >
> >> > The only non-conserved force I know of is the Ewald Gradient Sum.
> >> > So if I add up the net force there, and handle it upon either force
> >> > reduction or update, I can eliminate two passes on memory and the
> >> > two kernels currently dedicated to adding and then subtracting them.
> >> >
> >> > But... Are there any other non-conserved forces?
> >> >
> >> > And... It looks like the FORTRAN and the CUDA code do different
> things.
> >> > FORTRAN simply averages the forces and subtracts. But CUDA only
> >> > averages over atoms with force thresholds above a predefined small
> >> > amount. What's up with that?
> >> >
> >> > pme_ene.F90:
> >> > if (netfrc .gt. 0 .and. onstep) then
> >> >
> >> > if (ti_mode .eq. 0) then
> >> > do i = 1, atm_cnt
> >> > net_frcs(:) = net_frcs(:) + frc(:, i)
> >> > end do
> >> >
> >> > ! Now do the correction:
> >> >
> >> > net_frcs(:) = net_frcs(:) / dble(atm_cnt - numextra)
> >> >
> >> > do i = 1, atm_cnt
> >> > frc(:, i) = frc(:, i) - net_frcs(:)
> >> > end do
> >> > else
> >> > do i = 1, atm_cnt
> >> > ti_net_frcs(1, :) = ti_net_frcs(1, :) + ti_nb_frc(1, :, i)
> >> > ti_net_frcs(2, :) = ti_net_frcs(2, :) + ti_nb_frc(2, :, i)
> >> > end do
> >> >
> >> > ti_net_frcs(1,:) =
> >> > ti_net_frcs(1,:)/dble(ti_atm_cnt(1)-ti_numextra_pts(1))
> >> > ti_net_frcs(2,:) =
> >> > ti_net_frcs(2,:)/dble(ti_atm_cnt(2)-ti_numextra_pts(2))
> >> > net_frcs(:) = ti_net_frcs(1,:) + ti_net_frcs(2,:)
> >> >
> >> > do i = 1, atm_cnt
> >> > ! This matches how sander removes netfrcs in TI runs
> >> > if (ti_lst(1,i) .ne. 0) then
> >> > frc(:, i) = frc(:, i) - ti_net_frcs(1,:)
> >> > else if (ti_lst(2,i) .ne. 0) then
> >> > frc(:, i) = frc(:, i) - ti_net_frcs(2,:)
> >> > else
> >> > frc(:, i) = frc(:, i) - net_frcs(:)
> >> > end if
> >> > end do
> >> > end if
> >> > ! Any extra points must have their 0.d0 forces reset...
> >> >
> >> > if (numextra .gt. 0 .and. frameon .ne. 0) &
> >> > call zero_extra_pnts_vec(frc, ep_frames, gbl_frame_cnt)
> >> >
> >> > end if
> >> >
> >> >
> >> > GTI path:
> >> > while (pos < cSim.atoms) {
> >> > PMEFloat fx = converter(pX[pos], ONEOVERFORCESCALE);
> >> > PMEFloat fy = converter(pY[pos], ONEOVERFORCESCALE);
> >> > PMEFloat fz = converter(pZ[pos], ONEOVERFORCESCALE);
> >> > if (abs(fx) > small || abs(fy) > small || abs(fz) > small) {
> >> > pX[pos] -= nfX;
> >> > pY[pos] -= nfY;
> >> > pZ[pos] -= nfZ;
> >> > }
> >> > pos += increment;
> >> > }
> >> >
> >> > 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
Received on Fri May 22 2020 - 13:30:02 PDT
