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