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
Received on Thu May 21 2020 - 18:30:03 PDT
