adhishm / dd2d_matryoshka Goto Github PK

In the program, there are two kinds of time increment defined:

• Adaptive time increment through the SlipPlane::calculateTimeIncrement function
• Fixed time increment, with dislocation movement being handled by the SlipPlane::moveDislocationsToLocalEquilibrium function

There should probably be a flag indicating which kind of increment to use for the simulations.

In the function SlipPlane::calculateDislocationStresses, currently only dislocations are browsed and their stress fields calculated. However, other defects may have stress fields too. Therefore, for each dislocation, the total stress field at its position should be calculated using contributions from all defects. Moreover, the class Defect has a virtual function Defect::stressField precisely for this reason.

Objective:
For each slip plane, a near-field table should be generated. This table would contain all the obstacles which are close to the dislocations of that slip plane.

Benefit:
When searching for the obstacle or defect nearest to a given dislocation, the program will not have to pass through the entire list of defects, but only through this reduced list. This list may be updated once in a predefined number of iterations, or when one or more defects disappear.

Consider the following input files:
Parameter file:

## Material properties
# Shear modulus
mu 7.0e10
# Poissons ratio
nu 0.33
# Burgers vector magnitude
BMag 2.5e-10
# Drag coefficient
drag 1.0e09
# Dipole emission
tauCritical_mean 5.0e08
tauCritical_stdev 0.2e06
tauCritical_time 1.0e-07

## Load
# Applied stress
appliedStress 0.0 0.0 0.0 0.0 2.0e09 0.0

## Simulation parameters
Stopping Time 5.0e-06
TimeStep fixed
LimitingDistance 5.0
ReactionRadius 15.0
LimitingTimeStep 1.0e-09

## Directories
Input input
Output output

## Statistics
### Name Flag(0/1) Frequency(iterations) Filename Parameters(if any)
statsSlipSystemObjects 1 100 SlipSystemObjects

## Filenames
Structure slipSystem_test01.txt

and the structure file slipSystem_test01.txt:

# Initial time
0.0
# Slip system origin position
0.0 0.0 0.0
# Slip system normal vector
1.0 1.0 1.0
# Slip system direction
1.0 -1.0 0.0
# Number of slip planes
3
## The following data specify the slip planes
## Slip plane 1
# Position
0.0 0.0 1.0e-05
# Extremities
-5.0e-06 0.0 0.0
+5.0e-06 0.0 0.0
# Nunber of dislocations
3
# Dislocations
# Position(3) BurgersVector(3) LineVector(3) BurgersMagnitude(1) Mobile(bool)
0.5e-06 0 0 1 0 0 0 1 0 2.5e-10 1
0.0e-06 0 0 1 0 0 0 1 0 2.5e-10 1
4.0e-06 0 0 1 0 0 0 1 0 2.5e-10 1
# Number of dislocation sources
2
# Dislocation sources
# Position(3) BurgersVector(3) LineVector(3) BurgersMagnitude(1)
-3.0e-06 0 0 -1 0 0 0  1 0 2.5e-10
3.0e-06 0 0 -1 0 0 0  1 0 2.5e-10
## Slip plane 2
# Position
0.0 0.0 2.0e-05
# Extremities
-5.0e-06 0.0 0.0
+5.0e-06 0.0 0.0
# Nunber of dislocations
3
# Dislocations
# Position(3) BurgersVector(3) LineVector(3) BurgersMagnitude(1) Mobile(bool)
0.5e-06 0 0 1 0 0 0 1 0 2.5e-10 1
0.0e-06 0 0 1 0 0 0 1 0 2.5e-10 1
4.0e-06 0 0 1 0 0 0 1 0 2.5e-10 1
# Number of dislocation sources
2
# Dislocation sources
# Position(3) BurgersVector(3) LineVector(3) BurgersMagnitude(1)
-3.0e-06 0 0 -1 0 0 0  1 0 2.5e-10
3.0e-06 0 0 -1 0 0 0  1 0 2.5e-10
## Slip plane 3
# Position
0.0 0.0 3.0e-05
# Extremities
-5.0e-06 0.0 0.0
+5.0e-06 0.0 0.0
# Nunber of dislocations
3
# Dislocations
# Position(3) BurgersVector(3) LineVector(3) BurgersMagnitude(1) Mobile(bool)
0.5e-06 0 0 1 0 0 0 1 0 2.5e-10 1
0.0e-06 0 0 1 0 0 0 1 0 2.5e-10 1
4.0e-06 0 0 1 0 0 0 1 0 2.5e-10 1
# Number of dislocation sources
2
# Dislocation sources
# Position(3) BurgersVector(3) LineVector(3) BurgersMagnitude(1)
-3.0e-06 0 0 -1 0 0 0  1 0 2.5e-10
3.0e-06 0 0 -1 0 0 0  1 0 2.5e-10

The simulation proceeds smoothly for several hundred iterations until when, the slip planes have 43 defects each, one dislocation lies beyond the slip plane extremity (grain boundary). Why?

This causes a segmentation fault in the part where the dislocations are to be moved to their local equilibrium positions, where there is no defect beyond it.

It might be useful to define two new classes GrainBoundary and FreeSurface which would both inherit public Defect.

This would allow them to have their own typical stress field expressions as well as treatments in case of imminent collisions.

According to the calculations shown in the wiki page on the Peach-Koehler force, there should be no z-axis component in the Peach-Koehler force. However, in the simulations the value of this component is non-zero.

It is suspected that this may be due to the fact that the dislocation bvec, lvec etc are expressed in the crystal system (ie, standard Burgers vectors like [110] etc). Perhaps these calculations should be changed to not only simplify the calculations but also to eliminate any evidently incorrect force vectors.

In the constructors of the class SlipPlane, there are several redundant operations which write to the std::vector<Defect*> defects repeatedly. There should be a logical order of calling the various functions like SlipPlane::setExtremities, SlipPlane::createDefects, etc., amd also a clean up of the operations each of those functions carries out, in order to remove redundancy and conflicts.

This bug may also be responsible for the other bug about wrong/changing defectType for the slip plane extremities.

I need some images for the validation section in the wiiki for the Grain class.

In these 2D simulations, it has been assumed that the dislocation line vector is always perpendicular to the line of intersection between the slip plane and the plane of observation. While this assumption simplifies certain aspects of the simulation pertaining to the input data for dislocations, it leads to the situation that the dislocations thus produced are, in general, mixed.

The evaluation of the Peach-Koehler force inherently separates the edge and screw components of each dislocation. However, the stress fields of the dislocations must be calculated taking into account the mixed nature of the dislocations.

The functions Grain::writeGrainBoundaryStressField and Grain::writeStressField write the values of the stress field at points along a specified path. The number of points along the path at which the stress field is to be calculated is given by the argument int resolution.

For the moment, the resolution is hard-coded into the program, and has the value 100. This should be a parameter read from the input file. It may be added to the variable Statistics grainStressField into its vector<double> parameters vector.

Error in Peach-Koehler force implementation in function Dislocation::forcePeachKoehler (Stress sigma, double tau_crss) in file dislocation.cpp
The order of multiplications between stress and the other vectors is not correct.
See wiki page on Peach-Koehler force.

Interactions between dislocations and other defects need to be defined. For example:

• Two dislocations of the same sign and on the same plane
• Two dislocations of opposite sign and on the same plane
• Two dislocations on different planes
• Dislocation - grain boundary
• Dislocation - free surface

Branch version_0.0_simulateSingleSlipPlane_listDefects:
The defects, when reading a slip plane get initialized with wrong defectType, or defectType gets changed by some operation.

For a dislocation, the force experienced due to an applied stress is given by the Peach-Koehler equation.

However, for the dislocation to move, the total shear stress on it must be greater than the critical resolved shear stress (CRSS). As can be seen from the final expression of the Peach-Koehler force, the shear stresses (expressed in the dislocation's co-ordinate system) are s12 and s23, for the edge and screw components, respectively.

The question then arises: What criterion for CRSS (which is a single number) should be applied?

Objective:
To have a single global time increment but all dislocations simply move to a position at which the force from the neighbouring defect balances out the stresses from all other sources.

Benefit:
This will eliminate the need to calculate individual time increment for each dislocation.
A global value t_global will still be imposed and this will limit the movement of dislocations that would take greater than t_global amount of time to reach the equilibrium position.

Each entity must have its own co-ordinate system, so that all operations are carried out in its own fixed reference frame.

The current plotting script takes in data in the form of a matrix with each row corresponding to an instant in time and each column giving the position of a certain defect. The trouble is that when one or more dislocations disappear (by annihilation, or by absorption into a free surface), the number of of columns changes.
Is there a simple way for the script to know that it is time to stop plotting a certain defect as it has disappeared from the simulation?

Dislocation dipole sources have to be introduced into the simulation. It is the mechanism by which increase of dislocation density occurs. The dislocation source operates by emitting a dislocation dipole when it experiences a shear stress greater than a threshold value tau_c for a certain number of iterations.

Care must be taken to create a Gaussian distribution of tau_c values. This is important because if all dislocation sources were to have the same value of tau_c, large numbers of them would get activated simultaneously causing sudden increases in plastic deformation, which is clearly artificial.

There should be no CRSS condition in the Peach-Koehler force. Once a dislocation is created, it simply moves under the influence of the force applied.

After the annihilation event, when the function SlipPlane::calculateDislocationStresses calls Defect::stressField, the program throws a segmentation fault at the call for the dislocation.

The interaction between a dislocation and a free surface is presently dealt with by simply removing the dislocation. The FreeSurface should be displaced by a step equivalent to the Burgers vector of the dislocation absorbed.

Each entity in the simulation, be it a slip plane, a slip system, a dislocation, etc, should have a unique identification number. These IDs can be stored in a list written out to file at the end of the simulation.

The advantage of such a system is that it can be used by the post-processing software for analysis.

Problem

The plotting of a slip system is not trivial because, unlike the case of plotting a slip plane, we now have objects that exist in 2 dimensions. They will then have to beplotted as such, with a third dimension representing time.

Solutions

I am considering two possible kinds of graphs:

• 3D graphs with the dislocation structure evolving in time, which may quickly become a huge mess because of the large number of objects
• 2D graphs showing the object positions, one for each instant, with the possibility of navigating in time using a slider (if such a thing is easily achievable using Matlab)

Take care to use Defect* as the type for the std::vector. When Defect is used, and a virtual function is called, the implementation of the base class, Defect in this case, is carried out instead of the one from the derived classes such as Dislocation, etc.

It might be desirable to pass to a different, less explicit format of input file.

Currently, all dislocation positions are specified explicitly. Instead of doing this, simply a dislocation density may be specified along with the crystal structure. Using this the right number of dislocations (from the density) of the right kind (from the crystal structure) may be placed on to the slip planes.

Validate the simulations with the behaviour of a single dislocation. See details on the wiki page Validation : Single dislocation.