strange flips of eps_zz for thin cell

[gabor1]

I'm having trouble with the atomic_strain() calculation. I am passing in a crack slab that is thin in the z direction, and then the relaxed version of it, and computing the atomic strain. Some atoms come back with eps_zz = -1, there are domains of these, and the domain walls have strange strains (and large residuals in the least squares fit). The image below shows the hydrostatic strain. The zz strain essentially looks the same.

[pastewka]

This is odd. Are the atoms reshuffled between the frames? The code needs to be able to assign a unique id to each atom, which is just the atom index presently.

If not, can you send the two configurations you are comparing?

[gabor1]

Here are the two configs. I am using the matscipy tools to apply thin strip displacements, but otherwise I'm not aware of any permutational mixup. the zip file contains the two configs, as well as the script that makes them. (the train measurements are not in the script)

crack.zip

[gabor1]

Now I have a suspicion! I think it's the "mic" call. The two neighbours are images of the same atom, and somehow the mic flips them.

[gabor1]

Taking out the mic() from the dr calculation, I get this as the hydrostatic strain.

[pastewka]

That last image looks good. The analysis however presently does not work robustly if mic cannot be applied, i.e. if the thickness of your slab is thinner than twice the cutoff.

This can only be partially fixed. I can use shift vectors (computed on the initial configuration) rather than using mic, but this assumes that no atom has passed a cell boundary and been wrapped back into the cell, which may happen for example in LAMMPS.

[pastewka]

I think the most robust solution would be to just replicate your cell in thickness direction before doing the analysis.

[gabor1]

How about issuing a warning? Optionally turning off that mic? Optionally double the unit cell in the short direction that fails the Mic test, for the purposes of doing the analysis?

…

-- Gábor

On 3 Apr 2018, at 21:27, Lars Pastewka ***@***.***> wrote: That last image looks good. The analysis however presently does not work robustly if mic cannot be applied, i.e. if the thickness of your slab is thinner than twice the cutoff. This can only be partially fixed. I can use shift vectors (computed on the initial configuration) rather than using mic, but this assumes that no atom has passed a cell boundary and been wrapped back into the cell, which may happen for example in LAMMPS. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[gabor1]

Yeah, but maybe the analysis should do that itself if asked for, and only report the deformation on the original cell. It certainly shouldn't report back rubbish without warning

…

-- Gábor

On 3 Apr 2018, at 21:29, Lars Pastewka ***@***.***> wrote: I think the most robust solution would be to just replicate your cell in thickness direction before doing the analysis. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[pastewka]

Agreed. Will implement the automatic doubling of the unit cell in periodic directions.

[jameskermode]

We have an undo_pbc_jumps() function in quip which could solve the problem of LAMMPS wrapping atoms across the pbc. It recently got ported to JuLIP, here is the discussion, which includes a Python implementation of the original Fortran unwrapping code written by @noambernstein

JuliaMolSim/JuLIP.jl#50

Perhaps we could use something like this this instead of the mic() call?

[noambernstein]

Is the mic call needed for having sensible vectors to do the strain calculation on, or is that unncessary?

…

On Wed, Apr 4, 2018 at 11:34 AM, James Kermode ***@***.***> wrote: We have an undo_pbc_jumps() function in quip which could solve the problem of LAMMPS wrapping atoms across the pbc. It recently got ported to JuLIP, here is the discussion, which includes a Python implementation of the original Fortran unwrapping code written by @noambernstein <https://github.com/noambernstein> JuliaMolSim/JuLIP.jl#50 <JuliaMolSim/JuLIP.jl#50> Perhaps we could use something like this this instead of the mic() call? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMLExiDPRAylU3U6zcC9HAjvNFj3FBVrks5tlOgegaJpZM4TFEgy> .

[pastewka]

It is unnecessary if there is no wrapping of atoms at periodic boundary conditions between the two frames. Unfortunately, that cannot be guaranteed. I realized that replicating the cell also does not work because again what is needed is the unwrapped motion of the atoms. Cell replication is only needed if an atom can occur in the neighbor list more than once; then it is still unclear, which of the replicas of the final frame belongs to which replica in the initial frame. Right now the code relies on the sorting order of the neighbor list for this. I have to admit that I am bit at a loss at how to solve this. We could use James `undo_pbc_jumps` for LAMMPS, but I’m sure this will break when someone then analyses trajectories from SuperFastMDCodeOfFormerPostdoc or whatever. Does the unwrapping work generally or do you need trajectories dumped at reasonably small intervals? LAMMPS also has the option to output unwrapped coordinates which solves the problem cleanly, but again not in a general fashion.

…

Am 04.04.2018 um 17:49 schrieb noambernstein ***@***.***>: Is the mic call needed for having sensible vectors to do the strain calculation on, or is that unncessary? On Wed, Apr 4, 2018 at 11:34 AM, James Kermode ***@***.***> wrote: > We have an undo_pbc_jumps() function in quip which could solve the > problem of LAMMPS wrapping atoms across the pbc. It recently got ported to > JuLIP, here is the discussion, which includes a Python implementation of > the original Fortran unwrapping code written by @noambernstein > <https://github.com/noambernstein> > > JuliaMolSim/JuLIP.jl#50 <JuliaMolSim/JuLIP.jl#50> > > Perhaps we could use something like this this instead of the mic() call? > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#11 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AMLExiDPRAylU3U6zcC9HAjvNFj3FBVrks5tlOgegaJpZM4TFEgy> > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[gabor1]

Can we have a temporary fix for this? I suggest allowing an option to atomic_strain() to turn off the mic()