Re: [ESPResSo-users] Weird results from P3M interaction?

[Clemens Jochum]

Dear Rudolf,

thanks for your quick and thorough response.

I re-ran some simulations without Coulomb interaction and there the
clustering does not occur, so it seems that the P3M method is indeed the
cause. I will try to provide suitable mesh parameters to circumvent the
tuning and see if that helps.
> The k-space part seems to be included, but looking at the code (e.g., in 
> src/core/verlet.cpp:build_verlet_lsit()), my impression is that the 
> short-range part (which is up to ~2.5 Bjerrum lengths in your system) is not.
> Note that the short range part of p3m is implemented as a non-bonded 
> interaction (sr/core/forces_inline.hpp:add_non_bonded_pair_force()).
> What are the exclusions needed for? 
I need the exclusions for the dendrimer: the LJ-interaction has an
offset, that is a couple of times larger than the bond length. So I need
to exclude the neighbouring particles from the LJ-interaction. I want
them to keep interacting via Coulomb potential, though. Is there a way
to do this?

Best,
Clemens

On 22.05.2017 21:11, Rudolf Weeber wrote:
> Hi Clemens,
>> I get some weird (unphysical?) results from my simulation. Therefore I
>> have a couple of questions:
>>
>>
>> 1) I have a system with one large charged dendrimer and counter-ions.
>> Additionally, there are charged salt ions. All particles interact via
>> LJ-interaction and Coulomb interaction (P3M). I attached some snapshots
>> of the resulting system at the end. In the snapshot the large dendrimer
>> is at the center of the particles. And (this is the confusing part) the
>> free ions seem to cluster with the clusters forming a regular lattice.
>> This does not seem right. My first guess is that the Coulomb interaction
>> and therefore the P3M method is the cause. Does anyone have an idea?
>>
>> This is the output of the P3M tuning method:
>>
>> P3M tune parameters: Accuracy goal = 1.00000e-04 Bjerrum Length =
>> 7.00052e+00
>> System: box_l = 1.27568e+03 # charged part = 3326 Sum[q_i^2] = 3.32600e+03
>> mesh cao r_cut_iL     alpha_L      err          rs_err     ks_err    
>> time [ms]
>> 16   3   1.79754e-01 1.07208e+01 9.97082e-05 7.071e-05 7.030e-05 3.63
>> 16   2   2.46081e-01 7.66386e+00 1.19662e-04 7.071e-05 9.654e-05
>> accuracy not achieved
>> 16   4   1.57645e-01 1.23319e+01 9.92441e-05 7.071e-05 6.964e-05 2.65
>> 16   5   1.48033e-01 1.31872e+01 9.97046e-05 7.071e-05 7.029e-05 2.51
>> 16   6   1.43227e-01 1.36592e+01 9.84446e-05 7.071e-05 6.849e-05 2.55
>> 16   7   1.39382e-01 1.40609e+01 9.93436e-05 7.071e-05 6.978e-05 2.71
>> 142  5   2.19736e-02 9.93374e+01 9.98180e-05 7.071e-05 7.045e-05 136.16
>> 142  4   2.42866e-02 8.94035e+01 9.40771e-05 7.071e-05 6.205e-05 134.00
>> 142  6   2.13954e-02 1.02165e+02 9.39748e-05 7.071e-05 6.190e-05 136.81
>> 142  3   2.94909e-02 7.28644e+01 9.67037e-05 7.071e-05 6.597e-05 132.60
>> 142  2   5.26210e-02 3.95352e+01 9.90264e-05 7.071e-05 6.933e-05 131.29
>> 142  1   1.48033e-01 1.31872e+01 2.75994e-04 7.071e-05 2.668e-04
>> accuracy not achieved
>>
>> resulting parameters:
>> 16   16   16   5   1.48033e-01 1.31872e+01 9.97046e-05 2.51
> Your system is very dilute (number density below 0.002). 
> Hence, the parameters chosen are a low number of mesh points and a large real 
> space cut-off.
> I'm not sure, why meshes between 16 and 142 are not tested. Maybe someone 
> with detailed knowledge about the tuning can comment?
> On a different note: The accuracy estimates in a highly inhomogeneous system 
> are to be taken with a grain of salt.
>
>
>
>> 2) When using the P3M method I sometimes get the warning "Statistics of
>> tuning samples is very bad" (But not for the simulation, which I used
>> for the snapshots). Is this a problem and on which parameters does this
>> depend on? Box size and accuracy?
> The P3M tuning times the actual force measurement (src/core/tuning.cpp). 
> These could fluctuate, e.g., because of other processes running on the same 
> system. If the fluctuation is too large, this may lead to a set of parameters 
> which gives slower calculations.
>
>> 3) The description of the "exclude" feature of particles says:"no
>> nonbonded interactions arecalculated". This means Coulomb interaction
>> for excluded particles are still calculated, correct?
> The k-space part seems to be included, but looking at the code (e.g., in 
> src/core/verlet.cpp:build_verlet_lsit()), my impression is that the 
> short-range part (which is up to ~2.5 Bjerrum lengths in your system) is not.
> Note that the short range part of p3m is implemented as a non-bonded 
> interaction (sr/core/forces_inline.hpp:add_non_bonded_pair_force()).
> What are the exclusions needed for? 
>
>
>> 4) I have several types of ions in my solvent, which I interact via the
>> same LJ-interaction, but I want them to have different LJ interactions
>> later on. So I want them as different types, which leads to 10 instead
>> of 3 LJ-interaction definitions. Is the computational cost for having 10
>> instead of 3 defined LJ-interactions very high? Keep in mind that the
>> actual number of interacting particles stays the same.
> Each pair of particles is considered once, whatever the number of particle 
> types. However, you'll loose some cache efficiency, as different interaction 
> parameters will have to be loaded for different pairs of particles. Probably 
> noticable but not huge difference.
>
> Hope that helps
> Regards, Rudolf
>
>
>