Basic functions of rotation implementation

[alexandrosvasi]

No description provided.

[tfamprikis]

this issue refers to something completely different

[tfamprikis]

The goal here is to keep track of the orientation of bonds and molecules throughout the simulation; and eventually quantify whether/how they might rotate.

The first thing to do is find and define what atoms are "bonded" with each other based on distances. Under the assumption that such bonds do not break during the simulation (non-reactive MD), this can be done for a single frame. Eventually, if we want to allow for reactive-MD then we need to do this every frame, but that is not priority. Our current working code works for tetrahedral molecules (e.g. methane CH4 , or a thiophosphate molecular anion, PS4^3-). We input the 'central' and 'satellite' atom types and the code finds the nearest satellite neighbors to each central atom with some arbitrary cutoff. This could be generalized by either inputting a cutoff or guessing based on a library of atomic sizes for each atom.

Then, for each bond, the orientation is calculated by considering the vector difference between satelite and central atom, for each frame. this is expressed in spherical coordinates. this is the reduced data for the following analysis/visualisation.

The orientational probability density can be calculated analogously to the spatial probability density, by dividing spherical coordinates into a grid. This can be visualized as a map (used cartopy for this). This can be transformed to a free energy in the same way as the spatial probability density as well (and eventually pathways found and barriers calculated)

The auto-correlation function (or self-correlation function) quantifies the degree and dynamics of correlation between the original orientation of a bond and its orientation in time t. The dot product between the original and current orientation is calculated for each bond, for each frame and then typically averaged for each bond in the system. This function start at 1 by definition, and then proceeds to decay. In a system where no rotation takes place it will plateau at some value (typically >0.9) indicative of modest local libration. In a system where bonds reorient, this will typically decay to 0. In the latter case we can fit an exponential decay and extract a characteristic (de)correlation time which quantifies the rotational/reorientational speed and is a main observable for the study of such systems. In order to quantify the error in this analysis, we can apply a similar approach to the error analysis of translational diffusivity from MSD, i.e. split the self-corellation function, calculate multiple correlation times and derive a standard deviation.

I will follow up with some rough code as examples - partly in matlab and partly python-, as soon as I get to clean it up, too self-consious to share it as it is rn

[stefsmeets]

Thanks for the extensive explanation, that helps a lot! I indeed mixed up the two themes.

[tfamprikis]

I've added an example analysis of an MD run here:

https://surfdrive.surf.nl/files/index.php/s/5ruIA57we0qcP5f

the first part is in matlab works as an addon to the old matlab code, it requires having run analyse_md.m first and generated a simulated_data.mat file (already provided for this example in /Li2SO4_HT_900K_gemdat)

satelllite_orb_matcher[...].m reads trajectories from the simulated_data.mat file and sets up the analysis described in the above comment. the goal is to generate, for each timestep, , vectors (and angles between vectors) that represent molecular bonds and molecular orientations. this is the variables called 'direction_cart' and 'degrees' in the current matlab code implementing this part to gemdat is the main priority.

I've added some examples of the figures generated by satelllite_orb_matcher[...].m in /matlab_generated_figures

after running satelllite_orb_matcher[...].m you can run a few python scripts that analyse/fit/plot the output (.csv) in /Li2SO4_HT_900K_gemdat

most of the code is probably written very badly and inefficiently atm... i'm not sure if you want to translate it or just straight up rewrite it.

[tfamprikis]

please do let me know if any of the above is not clear.

it would be nice to have the first part of the satelllite_orb_matcher[...].m script integrated in gemdat rather quickly, since it's the basis for alot of things.