LLNL
On the question that dislocation lines will simulate disappearing
@nrbertin Hello developer, my model size is 800b, b=0.248nm, when I set the dislocation line to 400b, at the beginning of the simulation, the dislocation line disappears, open the data file in the restret folder and find that there is no node information, the nodes are gone. But as long as the dislocation line is a little longer than 400b, such as 400.0001b, it can be simulated normally, and less than 200b can not be simulated, the picture is the node information of my data file, why is this? Hope to get your answer!
@Passion28-y This happens because introducing an infinite dislocation line discretized with 3 nodes breaks the minimum image treatment under periodic boundary conditions. When introducing a dislocation, you need to ensure that the length of each segment is less than half the box size.
@nrbertin Is it less than half of the simulated size? Should it be greater than half of the simulated size? Because it cannot be simulated when the length is 300b.
@Passion28-y It may appear to be working for longer lengths because both segments start to overlap with each other; but this is not what you want. Just use more discretization nodes to ensure that each segment is smaller than half the box length and everything should be working fine.
@nrbertin Sorry, I don't understand. My simulation area length is 800b. If it is the length of the segment, as shown in the figure, it is 200b, and half of the simulation length is 400b. This is less than half of the simulation length, but it cannot be simulated.
@Passion28-y In your example, node 0 at z=200 is connected to node 2 at z=-200, which makes segment 0-2 of length 400b through periodic boundary condition. All segments must be of length < 400b for a simulation box of size 800b.
@nrbertin According to the solution you provided, I have reduced the node coordinates, ensuring that each segment is less than 400b. However, the results remain the same, with no dislocation lines present. Attached is the content of my latest attempt with the nodes. I hope to receive your response. Thank you.
@Passion28-y In this new example, segment 0-2 (connecting node 0 at z=100 to node 2 at z=-100) has length 600b > 400b.
@nrbertin My current understanding is that the way to get 600b is due to periodic boundary conditions. The dislocation line goes from 100b up to 400b, then goes around to -400b to -100b, so the length is 600b. Is this the calculation I understand? Or is there another way to calculate?
@nrbertin I have tried for a long time but still cannot simulate it correctly. Attached is the node information from my best attempt. Under periodic conditions, I believe each segment is 200b (for example, 0-2 is 600b > 400b, which is half the length of the periodic boundary). When corrected for periodic conditions, it becomes 200b, making the lengths uniformly 200b; however, I still cannot simulate it. If I have misunderstood, I would appreciate your guidance. It would be great if you could modify the attached example for accurate simulation. I look forward to your response!
@Passion28-y I do not know what you used to generate this configuration, but the connectivity is incorrect.
For simplicity, you can use the tools provided in OpenDiS. For instance, the following python script:
import pyexadis
from pyexadis_base import ExaDisNet
from pyexadis_utils import insert_infinite_line
pyexadis.initialize()
# Define box
Lbox = 800.0
cell = pyexadis.Cell(h=Lbox*np.eye(3), origin=-0.5*Lbox*np.ones(3)) # center box around zero for ParaDiS
nodes, segs = [], []
# Insert infinite line
burg = np.array([1.,0.,0.])
plane = np.array([0.,1.,0.])
theta = 90.0 # edge dislocation
origin = np.array(cell.center())
nodes, segs = insert_infinite_line(cell, nodes, segs, burg, plane, origin, theta=theta)
# Export in .data file
G = ExaDisNet(cell, nodes, segs)
G.write_data('line.data')
pyexadis.finalize()
will produce the following configuration:
domainDecomposition =
# Dom_ID Minimum XYZ bounds Maximum XYZ bounds
0 -400.000000 -400.000000 -400.000000 400.000000 400.000000 400.000000
nodalData =
# Primary lines: node_tag, x, y, z, num_arms, constraint
# Secondary lines: arm_tag, burgx, burgy, burgz, nx, ny, nz
0, 0 0.000000000000 0.000000000000 0.000000000000 2 0
0, 1 1.000000000000 0.000000000000 0.000000000000
0.000000000000 1.000000000000 0.000000000000
0, 5 -1.000000000000 -0.000000000000 -0.000000000000
0.000000000000 1.000000000000 0.000000000000
0, 1 0.000000000000 0.000000000000 -133.333333333333 2 0
0, 0 -1.000000000000 -0.000000000000 -0.000000000000
0.000000000000 1.000000000000 0.000000000000
0, 2 1.000000000000 0.000000000000 0.000000000000
0.000000000000 1.000000000000 0.000000000000
0, 2 0.000000000000 0.000000000000 -266.666666666667 2 0
0, 1 -1.000000000000 -0.000000000000 -0.000000000000
0.000000000000 1.000000000000 0.000000000000
0, 3 1.000000000000 0.000000000000 0.000000000000
0.000000000000 1.000000000000 0.000000000000
0, 3 0.000000000000 0.000000000000 -400.000000000000 2 0
0, 2 -1.000000000000 -0.000000000000 -0.000000000000
0.000000000000 1.000000000000 0.000000000000
0, 4 1.000000000000 0.000000000000 0.000000000000
0.000000000000 1.000000000000 0.000000000000
0, 4 0.000000000000 0.000000000000 266.666666666667 2 0
0, 3 -1.000000000000 -0.000000000000 -0.000000000000
0.000000000000 1.000000000000 0.000000000000
0, 5 1.000000000000 0.000000000000 0.000000000000
0.000000000000 1.000000000000 0.000000000000
0, 5 0.000000000000 0.000000000000 133.333333333333 2 0
0, 4 -1.000000000000 -0.000000000000 -0.000000000000
0.000000000000 1.000000000000 0.000000000000
0, 0 1.000000000000 0.000000000000 0.000000000000
0.000000000000 1.000000000000 0.000000000000
@nrbertin Thank you for telling me that I can use OpenDiS to generate it, but this is not the dislocation line I want. I want to generate two dislocation lines with a length of 400b, but I can't set a reasonable node connection method (all are free nodes). Is there a requirement for the length of the dislocation line?
@Passion28-y If you want to generate 2 Frank-Read sources separated by 100b along y, then you can use the following script:
import pyexadis
from pyexadis_base import ExaDisNet
from pyexadis_utils import insert_frank_read_src
pyexadis.initialize()
# Define box
Lbox = 800.0
cell = pyexadis.Cell(h=Lbox*np.eye(3), origin=-0.5*Lbox*np.ones(3)) # center box around zero
nodes, segs = [], []
Lsrc = 0.5*Lbox
burg = np.array([1.,0.,0.])
plane = np.array([0.,1.,0.])
theta = 90.0 # edge dislocation
# Insert source 1
center1 = cell.center()
nodes, segs = insert_frank_read_src(cell, nodes, segs, burg, plane, Lsrc, center1, theta=theta)
# Insert source 2
center2 = center1 + np.array([0.0, 100.0, 0.0])
nodes, segs = insert_frank_read_src(cell, nodes, segs, burg, plane, Lsrc, center2, theta=theta)
# Export in .data file
G = ExaDisNet(cell, nodes, segs)
G.write_data('frs.data')
pyexadis.finalize()
which would generate the attached file frs.txt (rename to .data).
PS: if you want to generate a dipole, make sure to specify -plane instead of plane for the second source to reverse its line direction.
@nrbertin That is to say, under periodic boundary conditions, it is not possible to generate a dislocation line with a length of 400b? Or do I want to generate a closed-loop dislocation line (out of boundary) on the xy plane, such as the example in the attachment, the quadrilateral of the closed loop, is this not possible? Is it possible that dislocation lines that do not go out of bounds can only use the frank-read source?
@nrbertin However, when simulating this model, all nodes will disappear, just like what was mentioned above.
@Passion28-y Please note that there are different things at play here. In your previous examples, dislocation lines disappeared either because periodic segment lengths were too large or because the nodal connectivity was incorrect.
In your new example of a closed glissile loop, the dislocation likely disappears because the loop shrinks and collapses under its own line-tension force. This is the expected physical result for a glissile loop (when using a linear mobility law). If you don't want the loop to collapse, you need to introduce a prismatic loop instead. In your toy example this would correspond to setting the Burgers vector to b=[001], i.e. perpendicular to the loop habit plane.
@nrbertin I am using the migration law of FCC_0. I tried your method to modify the Burgers vector, but the nodes still disappeared.
@Passion28-y Then I don't have enough information about your setup and what you are trying to achieve to know what's the issue. If you share your ctrl and data files I'll take a look.
@nrbertin Below are my ctrl and data files. I intend to construct a closed dislocation line within the simulation domain (without crossing the boundaries), with an overall length of 400b, which may appear as a line segment of length 200b.
dirname = "test"
Domain geometry
numXdoms = 2 numYdoms = 2 numZdoms = 2
Cell geometry
numXcells = 4 numYcells = 4 numZcells = 4
Dynamic load balancing
decompType = 2 DLBfreq = 3
Discretization and topological change controls
maxSeg = 50 remeshRule = 2 enforceGlidePlanes = 1 enableCrossSlip = 0 splitMultiNodeFreq = 1
Simulation time and timestepping controls
maxstep = 2000000
timestepIntegrator = trapezoid
deltaTT = 1.656930e-12
maxDT = 1.000000e-07
nextDT = 1.988316e-12
rTol = 1
rann = 0.5
Fast Multipole Method controls
eshelbyfmEnabled = 0
fmEnabled = 0
fmMPOrder = 2
fmTaylorOrder = 5
fmCorrectionTbl = "./inputs/fm-ctab.Cu.m2.t5.dat"
Rijmfile = "./inputs/Rijm.cube.out"
RijmPBCfile = "./inputs/RijmPBC.cube.out"
Loading conditions
loadType = 1
eRate = 1.0e3
collisionMethod = 2
edotdir = [ 0 1 1 ]
appliedStress = [ 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 0.000000e+00 ]
Material and mobility parameters
mobilityLaw = "FCC_0"
shearModulus = 79e9
pois = 0.31
burgMag = 2.4800e-10
mobility values may be a little low for FCC
MobScrew = 4000 MobEdge = 4000 rc = 2
I/O controls and parameters
fluxfile = 1
fluxfreq = 500
gnuplot = 1
gnuplotfreq = 500
psfile = 0
psfilefreq = 500
savecn = 1
savecnfreq = 500
saveprop = 1
savepropfreq = 500
savetimers = 0
velfile = 1
velfilefreq = 500
armfile = 1
armfilefreq = 500
writeForce = 1
writeForceFreq = 500
dataFileVersion = 4
numFileSegments = 1
minCoordinates = [ -400 -400 -400 ] maxCoordinates = [ 400 400 400 ] nodeCount = 4
dataDecompType = 1
dataDecompGeometry = [ 1 1 1 ]
END OF DATA FILE PARAMETERS
domainDecomposition = -400 -400 -400 400 400 400
nodalData =
Primary lines: node_tag, x, y, z, num_arms, constraint
Secondary lines: arm_tag, burgx, burgy, burgz, nx, ny, nz
0,0 0 100 0 2 0
0,1 0 0 1
0 0 1
0,3 0 0 -1
0 0 1
0,1 0 0 0 2 0
0,2 0 0 1
0 0 1
0,0 0 0 -1
0 0 1
0,2 0 -100 0 2 0
0,3 0 0 1
0 0 1
0,1 0 0 -1
0 0 1
0,3 0 0 0 2 0
0,0 0 0 1
0 0 1
0,2 0 0 -1
0 0 1
I intend to construct a closed dislocation line within the simulation domain (without crossing the boundaries), with an overall length of 400b, which may appear as a line segment of length 200b.
If you construct your dislocation loop like this with both segments of length 200b overlapping, then indeed the segments will immediately annihilate. If you want to construct a single dislocation line of finite length then the only possible option is to use a Frank-Read source. If you want to insert a closed dislocation loop, then segments should not overlap, otherwise the loop will disappear by annihilation (which is a physical process).
@nrbertin That is to say, under periodic boundary conditions, it is not possible to generate a dislocation line with a length of 400b? Or do I want to generate a closed-loop dislocation line (out of boundary) on the xy plane, such as the example in the attachment, the quadrilateral of the closed loop, is this not possible? Is it possible that dislocation lines that do not go out of bounds can only use the frank-read source?
Why does this also annihilate? This does not overlap (I have changed the Bergers vector you mentioned and tried again), it is the same ctrl.
@Passion28-y You also need to ensure that the segments belong to their slip plane when changing the Burgers vector (otherwise the loop will still shrink and disappear). For instance the following modified configuration respects this condition and the loop shouldn't disappear:
nodalData =
# Primary lines: node_tag, x, y, z, num_arms, constraint
# Secondary lines: arm_tag, burgx, burgy, burgz, nx, ny, nz
0,0 -100 100 0 2 0
0,1 0 0 1
1 0 0
0,3 0 0 -1
0 1 0
0,1 -100 -100 0 2 0
0,2 0 0 1
0 1 0
0,0 0 0 -1
1 0 0
0,2 100 -100 0 2 0
0,3 0 0 1
1 0 0
0,1 0 0 -1
0 1 0
0,3 100 100 0 2 0
0,0 0 0 1
0 1 0
0,2 0 0 -1
1 0 0
However, if your intent is to simulate FCC, then this configuration is not valid because <100> Burgers vectors and {100} planes are not valid crystallographic directions in FCC.
@nrbertin Yes, it can be simulated now. Thank you for your help. Thank you very much
@nrbertin I would like to know what requirements must be met when setting the Burgers vector in the data file? For example, the Burgers vector in your answer above must satisfy the vertical dislocation loop. Because I want to simulate the FCC type, I plan to use <110> Burgers vectors and {111} planes. In this case, does my dislocation line only need to satisfy the slip plane, without worrying about the relationship between the dislocation line and the Burgers vector? Looking forward to your answer.
If you want the dislocations to behave properly, you need to ensure that: (i) Burgers vectors and slip plane normals are valid directions (1/2<110> Burgers vectors and {111} planes for FCC), and (ii) both Burgers vector and line direction are contained within the slip plane for each segment. In FCC, the same crystallography imposes that 1/2<110> prismatic loops are rhomboidal in shape, with each opposite pair of arms belonging to different slip planes.
As always, the simplest is to use generation functions from OpenDiS, e.g. to generate a collection of prismatic loops in FCC:
import pyexadis
from pyexadis_base import ExaDisNet
pyexadis.initialize()
G = ExaDisNet()
G.generate_prismatic_config('fcc', Lbox, num_loops, radius, maxseg, seed=1234)
G.write_data('prismatic_loops.data')
@nrbertin I have created an initial dislocation configuration for prismatic_loops using OpenDiS, but it does not inform me of the initial dislocation density. How should I obtain the initial dislocation density?