Implement local force capping

[J-Hizzle]

Solves #72.

I introduced a BinaryPred in analogy to the UnaryPred that was introduced in ThermodynamicForce.hpp:89.

The BinaryPred is not immediately necessary. It would also be possible to realize a local capping with a UnaryPred that would be checked once for the outer loop of LennardJones.apply_if over the atoms and once for the inner loop over the neighbor list. However, this way, the partition into AT + near Delta (= no capping), far Delta (= capping) and TR (= no interaction) is straight forward as well, since the user can have AND and OR conditions on the positions of the two particles.

At least during testing on my desktop computer, the changes did not impair the observed performance.

[J-Hizzle]

On a side note: When running a simulation with multiple potentials applied (such as LennardJones and DSF), the current implementation loops over the views contained in the atoms class for each potential individually. This means that there is as many loops over the atoms as there are different potentials applied. Would it be more performant to have one loop and call the potential functions requested from the user within this loop?

So, rather than:
apply LJ {
for atoms {
for neighbors {
apply LJ forces
}
}
}
apply DSF {
for atoms {
for neighbors {
apply DSF forces
}
}
};

One could do:
apply potentials {
for atoms {
for neighbors {
apply LJ forces
apply DSF forces
}
}
}.

[XzzX]

On a side note: When running a simulation with multiple potentials applied (such as LennardJones and DSF), the current implementation loops over the views contained in the atoms class for each potential individually. This means that there is as many loops over the atoms as there are different potentials applied. Would it be more performant to have one loop and call the potential functions requested from the user within this loop?

So, rather than: apply LJ { for atoms { for neighbors { apply LJ forces } } } apply DSF { for atoms { for neighbors { apply DSF forces } } };

One could do: apply potentials { for atoms { for neighbors { apply LJ forces apply DSF forces } } }.

yes.

[XzzX]

Can we separate the LJ change from the example, aka two PRs?

[XzzX]

I do not know if it is clear what the predicate takes as Arguments. What about

using TwoPositionsPredicate = std::predicate<
                         const real_t, //< pos 1 x
                         const real_t, //< pos 1 y
                         const real_t, //< pos 1 z
                         const real_t, //< pos 2 x
                         const real_t, //< pos 2 y
                         const real_t  //< pos 2 z
>;

?
Not sure if I like the name.

[XzzX]

We can make this a member of the Subdomain, aka subdomain.getVolume();

[J-Hizzle]

Good idea. On it.

[XzzX]

I like the simulation script. I think it is very readable and understandable.

[XzzX]

However, it is not doing multi res, so perhaps we should remove it from the name.

[J-Hizzle]

However, it is not doing multi res, so perhaps we should remove it from the name.

Good point. What about "02_tracerArgon_localCap"?

[J-Hizzle]

Can we separate the LJ change from the example, aka two PRs?

Yes, I did that in #80.

[J-Hizzle]

I do not know if it is clear what the predicate takes as Arguments. What about

using TwoPositionsPredicate = std::predicate<
                         const real_t, //< pos 1 x
                         const real_t, //< pos 1 y
                         const real_t, //< pos 1 z
                         const real_t, //< pos 2 x
                         const real_t, //< pos 2 y
                         const real_t  //< pos 2 z
>;

? Not sure if I like the name.

Hmm, I see the point. We can change it.

[J-Hizzle]

I do not know if it is clear what the predicate takes as Arguments. What about

using TwoPositionsPredicate = std::predicate<
                         const real_t, //< pos 1 x
                         const real_t, //< pos 1 y
                         const real_t, //< pos 1 z
                         const real_t, //< pos 2 x
                         const real_t, //< pos 2 y
                         const real_t  //< pos 2 z
>;

? Not sure if I like the name.

I think I solved this in 2fbbabb on PR #80. I had to generalize the predicates to concepts and I did it in datatypes.hpp.