Step 3: LOTF hybrid MD simulation of fracture in Si
In the final part of this tutorial, we will be extending our previous script for classical molecular dynamics to carry out an adaptive QM/MM simulation of fracture using the ‘Learn on the Fly’ (LOTF) scheme.
You will need the run_crack_classical.py script from Step 2: Classical MD simulation of fracture in Si. If you
don’t have it, you can download it here,
and the crack.xyz input file from Step 1: Setup of the Silicon model system, which you
can also download here.
3.1 Initialisation of the QM/MM atomic system (20 minutes)
Import the relevant modules
Make a copy of your run_crack_classical.py script and name it
run_crack_lotf.py. Add the following extra import statements after those
that are already there:
from quippy.potential import ForceMixingPotential
from quippy.lotf import LOTFDynamics, update_hysteretic_qm_region
Definition of the simulation parameters
Next, we need to add some additional parameters specifically for the
QM/MM simulation. Again, insert them in run_crack_lotf.py, below the
existing parameters
qm_init_args = 'TB DFTB' # Initialisation arguments for QM potential
qm_inner_radius = 8.0*units.Ang # Inner hysteretic radius for QM region
qm_outer_radius = 10.0*units.Ang # Inner hysteretic radius for QM region
extrapolate_steps = 10 # Number of steps for predictor-corrector
# interpolation and extrapolation
The setup of the atomic structure and of the constraints is exactly the same as before, so leave these sections of your script unchanged.
Setup of the QM and QM/MM potentials
For the QM/MM simulation, we first need to initialise the classical SW potential (mm_pot) and the quantum-mechanical one (qm_pot). The two Hamiltonians then need to be combined into a hybrid QM/MM potential (qmmm_pot), which mixes the QM and MM forces.
Leave the initialisiton of the SW classical potential as it is. After this, we
want to add some lines of code to setup the QM potential. Using the same
Potential class, we initialise now the Density
functional tight binding (DFTB) potential. This is done by passing the new QM
qm_init_args as the init_args parameter and the same XML file as before for
the param_filename to the Potential constructor (note that the single file
params.xml contains parameters for both the SW and DFTB potentials):
qm_pot = ... # Initialise DFTB potential
The QM/MM potential is constructed using quippy’s
quippy.potential.ForceMixingPotential class. Here, pot1 is
the low precision, i.e. MM potential, and pot2 is the high
precision, i.e. QM potential. fit_hops is the number of hops used to
define the fitting region, lotf_spring_hops defines the length of
the springs in the LOTF adjustable potential, while the hysteretic
buffer options control the size of the hysteretic buffer
region region used for the embedded QM force calculation.
qmmm_pot = ForceMixingPotential(pot1=mm_pot,
pot2=qm_pot,
atoms=atoms,
qm_args_str='single_cluster cluster_periodic_z carve_cluster '+
'terminate cluster_hopping=F randomise_buffer=F',
fit_hops=4,
lotf_spring_hops=3,
hysteretic_buffer=True,
hysteretic_buffer_inner_radius=7.0,
hysteretic_buffer_outer_radius=9.0,
cluster_hopping_nneighb_only=False,
min_images_only=True)
The qm_args_str argument defines some parameters which control how the QM calculation is carried out: we use a single cluster, periodic in the z direction and terminated with hydrogen atoms. The positions of the outer layer of buffer atoms are not randomised.
Change the line which sets the Atoms calculator to use the new qmmm_pot Potential:
atoms. ... # Set the calculator
Set up the initial QM region
Now, we can set up the list of atoms in the initial QM region using
the update_hysteretic_qm_region() function, defined
in quippy. Here we need to provide the Atoms system, the
centre of the QM region (i.e. the position of the crack tip), and the
the inner and outer radius of the hysteretic QM
region. Note that the old_qm_list attribute must be an empty list
([]) in this initial case:
qm_list = ... # Define the list of atoms in the QM region
The list needs to be attached to the qmmm_pot using the
set_qm_atoms() method:
qmmm_pot. ... # Attach QM list to calculator
Milestone 3.1
Your run_crack_lotf.py script should look something
like run_crack_lotf_1.py.
At this point you should run your script and check the initial QM region. For testing, you should add a couple of temporary lines to force the script to finish after setting the QM region and before repeating the classical MD:
import sys
sys.exit(0)
To visualise the initial QM region, you can type the following directly into
your ipython session (remember to do a from qlab import * first if you
haven’t already):
view(atoms)
aux_property_coloring(qmmm_pot.get_qm_atoms())
In the image above, the red atoms are QM and the blue atom classical.
Internally, this list is actually saved as a property inside the Atoms object named "hybrid",
which can also be displayed with aux_property_coloring("hybrid")
3.2 Setup and run the adaptive QM/MM MD (20 minutes)
Initialising the Dynamics
The definition of the initial temperature of the system should be left as in Step 2. Don’t forget to remove the temporary lines added above which quit the script after setting up the initial QM region!
Instead of a traditional dynamics in the NVE ensemble, let’s change the code to
use LOTF predictor-corrector dynamics, using
the quippy.lotf.LOTFDynamics class instead of
the VelocityVerlet class. We need to pass the following
arguments: atoms, timestep, extrapolate_steps (see Parameters
section):
dynamics = ... # Initialise the dynamical system
The logger and crack tip movement detection functions can be left almost exactly
as before for now: we just need to make a small change to
the printstatus() function so to distinguish between extrapolation and
interpolation:
Change the line:
atoms.info['label'] = 'D' # Label for the status line
to:
atoms.info['label'] = dynamics.state_label # Label for the status line
This uses the state_label attribute to print
an "E" at the beginning of the logger lines for extrapolation and an "I"
for interpolation.
Updating the QM region
We need to define a function that updates the QM region at the
beginning of each extrapolation cycle. As before, we need to find the
position of the crack tip and then update the hysteretic QM region. Note that now a previous QM region exists and
its atoms should be passed to the
update_hysteretic_qm_region() function. The current
QM atom list can be obtained with the
quippy.potential.ForceMixingPotential.get_qm_atoms() method. To
find the crack position, use
find_crack_tip_stress_field() as before, but pass
the MM potential as the calculator used to calculated the stresses
(force mixing potentials can only calculate forces, not per-atom
stresses; we will check later that the classical stress is
sufficiently accurate for locating the crack tip):
def update_qm_region(atoms):
crack_pos = ... # Find crack tip position
qm_list = ... # Get current QM atoms
qm_list = ... # Update hysteretic QM region
qmmm_pot. ... # Set QM atoms
dynamics.set_qm_update_func(update_qm_region)
Writing the trajectory
Finally, we want to save frames to the trajectory every traj_interval time
steps but, this time, only during the interpolation phase of the
predictor-corrector cycle. To do this, we first initialise the trajectory file
(see AtomsWriter()), and then define a function that only
writes to the trajectory file if the state of the dynamical systems is
Interpolation:
trajectory = ... # Initialise trajectory using traj_file
def traj_writer(dynamics):
if dynamics.state == LOTFDynamics.Interpolation:
trajectory.write(dynamics.atoms)
As before, we attach this function to the dynamical system, passing
traj_interval and and extra argument of dynamics which gets passed along to the
traj_writer function (see the attach()
method):
dynamics. ... # Attach traj_writer to dynamics
Now, we can simply run the dynamics for nsteps steps:
dynamics. ... # Run dynamics for nsteps
If you are interested in seeing how the LOTF predictor-corrector cycle is
implemented, look at the documentation and source code for the
quippy.lotf.LOTFDynamics.step() routine.
Milestone 3.2
The finished version of the run_crack_lotf.py script should look something
like Step 3 solution — run_crack_lotf.py. To clearly show the differences with respect to the
classical MD script, here is a patch which could be used to convert the classical
script into the LOTF one.
3.3 Visualisation and Analysis (as time permits)
Predictor/corrector dynamics output file
Let’s first take a moment to look at the output of the script for the first predictor/corrector cycle. Here we go through some example output, yours should be similar. First there are a few lines about the initialisation of the system, and then we get the results of the initial LOTF adjustable potential optimisation:
Loading atoms from file crack.xyz
Fixed 240 atoms
25 atoms selected for quantum treatment
update_qm_region: QM region with 25 atoms centred on [-30.60517303 0.08401087 0. ]
Adding default springs
Got 1484 springs
Number of force components: 297
Number of parameters: 1484
Optimising 1484 adjustable parameters
RMS force component error before optimisation : .05630875465645784
Max force component error before optimisation : .34841292159055509
Using SVD for least squares fit, eigenvalue threshold = .00000000010000000
RMS force component error after optimisation : 0.27E-02
Max force component error after optimisation : 0.61E-02
Max abs spring constant after optimisation : 0.45E-01
You can see that before adjusting the parameters, the QM and classical potentials differed by a maximum of 0.35 eV/A, with an RMS difference of 0.06 eV/A - in this case the SW potential is actually doing a rather respectable job. After the fit, which is this case involved 1484 spring parameters to fit 297 force component, the force differences are of course much smaller.
Next we start the first predictor/corrector cycle. First we update the QM region, and remap the adjustable potential to take account of any changes since last time:
25 atoms selected for quantum treatment
update_qm_region: QM region with 25 atoms centred on [-30.6048418 0.08377744 0. ]
Adding default springs
Got 1484 springs
Number of force components: 297
Number of parameters: 1484
As this is the first step, there were no changes, so no re-optimisation is required. Next we carry out 10 steps of extrapolation, with constant LOTF adjustable parameters. During this time the strain is incremented as normal:
State Time/fs Temp/K Strain G/(J/m^2) CrackPos/A D(CrackPos)/A
---------------------------------------------------------------------------------
E 1.0 553.716406 0.08427 5.0012 -30.61 (-0.00)
E 2.0 547.749233 0.08428 5.0024 -30.61 (-0.01)
E 3.0 535.952151 0.08429 5.0036 -30.62 (-0.01)
E 4.0 518.731103 0.08430 5.0047 -30.63 (-0.02)
E 5.0 496.675925 0.08431 5.0059 -30.63 (-0.03)
E 6.0 470.538607 0.08432 5.0071 -30.64 (-0.04)
E 7.0 441.205418 0.08433 5.0083 -30.65 (-0.05)
E 8.0 409.663780 0.08434 5.0095 -30.66 (-0.06)
E 9.0 376.965040 0.08435 5.0107 -30.67 (-0.07)
E 10.0 344.184506 0.08436 5.0119 -30.69 (-0.08)
At the end of the extrapolation, it’s time for a QM force evaluation and another fit. Now the force errors before fitting are a little larger, but the fit is still very good:
Optimising 1484 adjustable parameters
RMS force component error before optimisation : .10494977522791650
Max force component error before optimisation : .48515966905523733
Using SVD for least squares fit, eigenvalue threshold = .00000000010000000
RMS force component error after optimisation : 0.37E-02
Max force component error after optimisation : 0.96E-02
Max abs spring constant after optimisation : 0.83E-01
We next return to the initial dynamical state and re-run the dynamics, interpolating between the optimised parameters at the two ends of the cycle. Note that the strain is also returned to the initial value at \(t = 0\), and that the temperature after one step exactly matches the interpolation phase (since the forces and velocities at \(t = 0\) are identical for extrapolation and interpolation):
State Time/fs Temp/K Strain G/(J/m^2) CrackPos/A D(CrackPos)/A
---------------------------------------------------------------------------------
I 1.0 553.716406 0.08427 5.0012 -30.65 (-0.04)
I 2.0 547.759567 0.08428 5.0024 -30.65 (-0.05)
I 3.0 535.982832 0.08429 5.0036 -30.66 (-0.05)
I 4.0 518.791314 0.08430 5.0047 -30.66 (-0.06)
I 5.0 496.773542 0.08431 5.0059 -30.67 (-0.07)
I 6.0 470.679783 0.08432 5.0071 -30.68 (-0.08)
I 7.0 441.394231 0.08433 5.0083 -30.69 (-0.09)
I 8.0 409.901969 0.08434 5.0095 -30.70 (-0.10)
I 9.0 377.251837 0.08435 5.0107 -30.71 (-0.11)
I 10.0 344.516566 0.08436 5.0119 -30.73 (-0.12)
To continue from here, we simply go back to the extrapolation phase and then repeat the entire cycle.
QM active and buffer regions
Trajectory analysis
Open your new trajectory as before, using the
view() function from within a new ipython session, and
visualise the QM region by colouring the atoms using the
hybrid_mark property
aux_property_coloring("hybrid_mark")
This property is used internally to identify which atoms are used for the QM active and buffer regions:
The central green atoms have hybrid_mark == HYBRID_ACTIVE_MARK, and they are
the atoms for which QM forces are used to propagate the dynamics. Classical
forces are used for all other atoms, including the red buffer region, where
hybrid_mark == HYBRID_BUFFER_MARK. As explained above, the
purpose of the buffer region is to give accurate QM forces on the active atoms.
If you want to see the actual cluster used for carrying out the embedded DFTB
calculation, you could use the create_cluster_simple()
function together with the same args_str cluster options defined above:
cluster = create_cluster_simple(gcat(),
args_str=("single_cluster cluster_periodic_z carve_cluster "
"terminate cluster_hopping=F randomise_buffer=F"))
view(cluster)
Colouring the cluster by coordination (press k) can be useful to check that all cut bonds have been correctly passivated by hydrogen atoms:
Comparison between classical and LOTF dynamics
Step through your trajectory with the Insert and Delete keys to see what happens in the LOTF dynamics. As before, you can jump to the end with Ctrl+Delete. You should find that the dynamics is very different to the classical case.
Check if the QM region is following the moving crack properly by looking at the
hybrid_mark property. If you repeat the analysis of the stress field carried out in Step 2, you should find that
the time averaged stress field is strongly concentrated
on the sharp crack tip. It is this stress field which is used
by find_crack_tip_stress_field() to follow the crack tip,
and hence to update the set of atoms in the QM region.
Here is a movie of a typical LOTF simulation on the \((111)\) cleavage
plane. To colour the QM atoms dark blue, we passed
the highlight_qm_region() function as the hook argument
to render_movie():
During the LOTF dynamics, the time-averaged stress field smoothly tracks the crack tip, as can be seen in this movie, where atoms are coloured by their \(\sigma_{yy}\) component:
And here is a head-to-head comparison of SW and LOTF dynamics:
Fracture initiates much earlier in the LOTF case, i.e. at a much reduced energy release rate, and is much more brittle, with none of the artificial plasticity seen with the classical potential alone.
Note that if you continue the LOTF dynamics, however, we may see some defects in the frature surface after the crack has propagated for a few nm. These are associated with the relatively small system and high strain rate we are using here, which leads to fracture at high energies and possibly to high speed fracture instabilities [Fineberg1991]. If you have time you can investigate this in the extension task on size and strain rate effects.
Although it is beyond the scope of this tutorial, you might be interested to know that using an overall larger system, bigger QM region and lower strain rate, as well as changing the Hamiltonian from DFTB to DFT-GGA, removes all of these defects, recovering perfectly brittle fracture propagation. The DFT model also gives an improved description of the fracture surfaces, which reconstruct to form a Pandey \(\pi\)-bonded chain, with it’s characteristic alternating pentagons and heptagons:
Evolution of energy release rate and crack position
If you follow the previous approach to plot the energy release rate G and crack position crack_pos_x variables during your LOTF simulation, you should find that the crack now advances monotonically, with a constant crack velocity of around 2500 m/s, and at about half the energy release rate of the classical case (6 J/m2 vs 12 J/m2).
For comparison, here is the classical plot again:
You should find that the temperature still goes up, but more gently than in the classical case, since the flow of energy to the crack tip is closer to the energy consumed by creating the new surfaces. Some heat is generated at the QM/MM border; usually this would be controlled with a gentle Langevin thermostat, which we have omitted here in the interests of simplicity.
Low speed instability on the (111) cleavage plane
If you are lucky, you may see the formation of a crack tip reconstruction consisting of a 5 and a 7 membered ring on the lower fracture surface, related to the Pandey surface reconstruction.
This reconstruction can cause cracks to take a step down by one atomic layer, which over time can build up via positive feedback mechanism into an experimentally observable phenomena [Kermode2008].
3.4 Checking the predictor/corrector force errors (optional)
Add check_force_error=True to the LOTFDynamics
constructor. This causes the LOTF routines to do a reference QM force evaluation
at every timestep (note that these extra QM forces are not used in the fitting,
so the dynamical trajectory followed is the same as before).
When checking the predictor/corrector errors, you need to disable the updating of the QM region by commenting out the line:
dynamics.set_qm_update_func(update_qm_region)
Let’s create a logfile to save the force errors at each step during
the interpolation and extrapolation. Add the following code before the
dynamics.run() call:
def log_pred_corr_errors(dynamics, logfile):
logfile.write('%s err %10.1f%12.6f%12.6f\n' % (dynamics.state_label,
dynamics.get_time()/units.fs,
dynamics.rms_force_error,
dynamics.max_force_error))
logfile = open('pred-corr-error.txt', 'w')
dynamics.attach(log_pred_corr_errors, 1, dynamics, logfile)
Finally, change the total number of steps (via the nsteps parameter) to a much
smaller number (e.g. 200 steps), close the logfile after the dynamics.run()
line:
logfile.close()
Once the dynamics have run for a few LOTF cycles, you can plot the results with
a shell script called plot_pred_corr_errors.py:
plot_pred_corr_errors.py -e 10 pred-corr-error.txt
The -e 10 argument is used to specify the number of extrapolate steps. This
produces a set of four plots giving the RMS and maximum force errors during
extrapolation and interpolation:
Note that the scale is different on the extrapolation and interpolation plots! Try varying the extrapolate_steps parameter and seeing what the effect on force errors is. What is the largest acceptable value? You could also try changing the lotf_spring_hops and fit_hops parameters, which control the maximum length of the corrective springs added to the potential and the size of the fit region, respectively.
Milestone 3.4
Here is a final version of the run_crack_lotf.py script including
checking of the force errors: run_crack_lotf.py.
Further extension tasks
QM region size
Investigate the effect of increasing the QM region size, controlled by the qm_inner_radius and qm_outer_radius parameters. When does the behaviour converge qualitatively? What does this say about the size of the ‘process zone’ in silicon?
Buffer region size
We have used a hysteretic buffer region from 7 A to 9 A. How would you check if this is sufficient? What criteria need to be satisfied for our results to be considered to be converged with respect to buffer region size?
Crack energy-speed relationship
Try varying the flow of energy to the crack tip by changing the initial_G parameter used when making the crack system in Step 1: Setup of the Silicon model system. How does this affect the speed of the crack?
Other crack orientations
Return to the beginning of Step 1: Setup of the Silicon model system and try classical and/or LOTF dynamics (which will actually probably be faster!) on the \((110)\) surface. Do you see any major differences? Can you find any dynamic fracture instabilities?
System size and strain rate effects
What is the effect of changing the system size on the critical energy release rate for fracture? How would you converge with respect to this parameter? Do you think experimental length scales can be reached? If not, does it matter? Think about how the choice of loading geometry helps here.
As well as finite size effects, and perhaps more severely, we are limited in the time scales that can be accessed by our fracture simulations, especially when using a QM method to describe the crack tip processes. Are there any scaling relations that can help us out here? How would you estimate the effect of the artificially high strain rate we have been forced to impose here.