Non-affine mean displacements calculations

[justaguy]

Dear Alexander and rest of the ovito users,

First of all I would like to thank you for your work, which has deeply helped a lot of us.

Second, I would like to ask you some stuff about the atomic strain modifier. Especifically about the non-affine displacements of Falk and Langer. The thing is that with your program I am getting values 10 times higher than the ones I obtain when performing and MSD. And I wonder why.

When I calculate the avg D^2 min in my system, I get and average of 1.2 A just after a 0.12 ps have passed from the reference (after 20 snapshots). Which I believe, is huge... I also tried without the option "detect reduced coordinates" and I got and average of 1.4 A after the same time.
Any idea why this is happening? The MSD I calculate in my system (removing the affine displacements) is approximately 0.1 A at that time delay...

(I have also searched the web and the forum but I havent found much...)
Any help would be appreciated.
Best regards,
Pablo.

Specific details:
I am loading a trajectory in a XYZ file. (Cu65Zr35) of a uniaxial tensile process (strain rate = 1E8 s^-1. 31250 atoms. PBC in the 3 axis. Poison ratio 0.34. Trajectory saved every 6 fs.
for the modifier I use the options:
- Eliminate the cell deformation (seems logical since I am straining the box)
- Output  D^2 min
- Cutoff of 4 A.
- Fixed reference (I load the first snap of my trajectory)
- Detect reduced coordinates (which I assume means the detect if my coordinated are in Angstrong of if they refer to the box proportion (xs,ys and zs in Lammps).

[Alexander Stukowski]

Dear Pablo,

I'm not sure whether (and why) the system-average D^2 value and the MSD value should really match as you claim, but I can imagine that under certain circumstances the two quantities should correlate and show a similar magnitude.

One detail that may not become clear from the documentation of the Atomic Strain modifier is that the D^2 value computed by OVITO does not get normalised by the number of neighbors of an atom. The D^2 value of one atom is simply the sum over the squared non-affine relative displacements of all its neighbors.  If you increase the cutoff radius parameter, more neighbors will contribute and the resulting D^2 value will naturally rise.

I think this might provide an explanation why the D^2 values you observe are so much higher than the per-atom MSD values. To correct them, you need to divide the D^2 values by the number of neighbors within the cutoff range, basically to avoid double counting displacements. the number of neighbors in the reference configuration can be determined using the Coordination Analysis modifier and a Freeze Property modifier.

-Alex

[Alexander Stukowski]

... And thank you for the positive feedback on OVITO. I really appreciate it and I'm glad you find the program useful.

[justaguy]

Dear Alexander,

To follow up with our discussion:

I think the D2min and the MSD (once the affine displacements have been removed should be similar because we are actually talking about mean squared displacements in both situations. D2min takes the neighbouring stresses into account, which I considered kind of a "correction" to the MSD. That is why I wasnt expecting such differences. Once again, to get an average 1.2 A D2min (1.2 mean squared distance) in a solid system at room temperature after just 0.12 ps from the starting of the simulation sounds excesive to me, but I could also be totally wrong

The value of the D2min is the same with or without the option "detect reduced coordinates" as it should be. That was an error from my side.

I actually was going to make a post stating that the D2min value increases considerable with the length of the cutoff, but I didn't have the time and now it is no neccesary because you explanation covers it perfectly.

Now my question is: from a scientific point of view, shouldnt the D2min in the output be already normalized by the number of neighbours taken into account during the calculations? What do you think? I mean, I dont see an "average between neigbours" in the Falk and Langer paper, but I dont know, I wasnt expecting such big variations depending on the cutoff and my point is that the D2min should be more or less independent of the cutoff (from a logical minimum cutoff onwards). I would really appreciate your opinion on this one

On the other hand, I would really like to try and normalize the D2min with the number of neighbours taken into account. I appreciate that you explained me how to do it, but it is still not 100% clear to me. When you say "the number of neighbors in the reference configuration can be determined using the Coordination Analysis modifier and a Freeze Property modifier." I get confused. Do you mean that I should calculate once the number of neighbours for each atom inside the cutoff using the reference snapshot and then apply those numbers along the rest of the trajectory? From my point of view, the number of neighbours will change along the trajectory so I will need to recalculate them in each snapshot, right? I would also appreciate a lot some more insight on this issue.

In any case, thanks for your response and once again thanks for OVITO. I am getting the hang of it and it is really great!
Pablo.

[Alexander Stukowski]

Hi Pablo,

Yes I agree, it would make more sense if the D2min were normalised (i.e. divided by) the number of neighbors that were included in the summation. OVITO doesn't do it for historic reason. The code for calculating D2min was contributed by somebody else, and he strictly followed the formulation given by Falk and Langer in their paper, which doesn't include a division by the number of neighbors. When I realised that it would be useful to automatically do the normalization, it was much to late to change the behaviour of OVITO.

So if you want to do the normalization yourself, you first need to determine the number of neighbors of each particle that enter into the calculation of the atomic deformation gradient and the D2min value. It's important to note that the set of neighbors that enters into this calculation is always determined in the undeformed configuration, which is static. On the other hand, the actual calculation of D2min happens in the deformed configurations. This distinction makes it somewhat cumbersome to do the normalization, because we need to perform the neighbor counting in the undeformed configuration, store the neighbor count of each atom, and use this information later when the actual D2min calculation is performed in the deformed configuration, i.e. in a later frame of the simulation.

OVITO allows you to do this using the following sequence of modifiers (listed in bottom-up order, like in the user interface):

4. Compute Property: The expression should be set to "NonaffineSquaredDisplacement/Coordination". So this modifier performs the actual normalization by dividing the D2min value calculated by the Atom Strain modifier by the "Coordination" property calculated by the Coordination Analysis modifier. The results of that calculation get stored in a new output particle property by the modifier.

3. Atomic Strain: That's the modifier calculating the D2min value for each atom.

2. Freeze Property: This modifier lets you preserve the values of the "Coordination" particle property computed at frame 0 (i.e. in the undeformed config). Once this modifier has been inserted into the data pipeline, the frozen property values will no longer change at the later simulation frames (which they would otherwise do, because particles are moving around and their coordinations dynamically change)

1. Coordination analysis (this modifier counts the number of neighbours that are within a given cutoff radius and stores the results as a new particle property named "Coordination". Make sure the cutoff radius parameter exactly matches the one used for the Atomic Strain modifier above.)

[justaguy]

Hi Alexander,

Your answer is simply awesome. Thanks a lot for taking the time to write it.

Best regards,

Pablo.