C. MODEL DEVELOPMENT
1. GP model development program
There are three improvements that were made to the material generator program for efficiency, cleanliness, readability, and configurability.
Source code: Mater_Model7.f90 # Version 7 Directory: /shared/DATA/crystals/
All of the main algorithms in this code came directly from the previous code:
“Mater_Multi_2010_4.f90”. The improvements in the program are listed below.
1) Only the size of each scale is used when generating the lattice for that respective scale.
In other words, lattices do not fill the entire model domain during development, which saves computation time and resources. This also makes it possible to create very large scale GP domains up to the micron scale without suffering from computation lagging.
2) Many processing steps were consolidated and only one temporary file is used. This way, the data remains in memory saving computation time otherwise spent writing to disk. This also makes the code cleaner and more fluent.
3) Previously, all crystal structure data was manually included into the code of the program. This means that a user must modify the source code to add new crystal data.
Having the user modifying code is prone to cause errors.
This program uses external crystal data files to assist in crystal structure definition and allows for any number of crystals in any orientation. These crystal files can be located in the same “crystals” directory as the program code. For example FCC aluminum has a crystal file called AlFCC and inside of it is:
4.0559 a0 1.0 a 1.0 b 1.0 c
.false. hexagonal?
1.0 0.0 0.0 Base vectors 0.0 1.0 0.0
0.0 0.0 1.0
1 number of species/different elements Al 13 element, atomic number
4 ncell, number of atoms in unit cell
0.0 0.0 0.0 13 atom vector and atomic number for each specie cell 0.5 0.5 0.0 13
0.5 0.0 0.5 13 0.0 0.5 0.5 13
All of the crystal files follow this format. As a result the input file for the material generator is slightly different. Instead of specifying the material for a block as a single letter it is now the name of the material file. For example an input file for a two scale block of Copper:
2 2 !The number of scales used, GP Scale ratio 177.821 10.887 10.887 !Half model sizes
4 !number of blocks below
CuFCC 2 1 !material structure, scale, number of cuts -177.821 177.821 -10.887 10.887 -10.887 10.887
s
-127.015 127.015 -10.887 10.887 -10.887 10.887 CuFCC 1 1
-127.015 127.015 -10.887 10.887 -10.887 10.887 s
127.015 -127.015 10.887 -10.887 10.887 -10.887 CuFCC -1 1
-130.644 130.644 -10.887 10.887 -10.887 10.887 s
-127.015 127.015 -10.887 10.887 -10.887 10.887 CuFCC -2 1
-127.015 127.015 -10.887 10.887 -10.887 10.887 s
-119.757 119.757 -10.887 10.887 -10.887 10.887
The Model Size is measured from the center of the model, so these values are half-model size values. This means that the model must be centered about the origin to correctly use periodic boundary conditions, also be sure that the largest scale is thick enough in the periodic direction to accommodate two times the interatomic cutoff radius.
Also be sure that atomic layers are not being duplicated; in other words a structure that is stacked with the sequence ABABAB does not end with the same type of layer that it begins with, this would make the first layer and the last layer interact directly across the periodic boundary and violate the stacking sequence.
The number of material blocks refers to how many special material domains are listed. For example, it would be 2 if the model was half Al2O3 and Fe. It can also help when building irregularly shaped models and multiple scales.
The scale should be 1 to use atoms, and third is the number of cuts being made in this block. The next line is the full domain of the block in a, x-left, x-right, y-back, y- front, z-lower, z-upper, format. The single letter below this specifies the type of cut to be made (all blocks must have at least one cut). Cut types and their parameters can be seen in the table below. If the lower bound parameter for a given dimension is LARGER than the maximum bound parameter, it will invalidate the cut. In this way, it is possible to circumvent the mandatory one-cut-per block, to allow for a solid block defined by the material block domain. For example, to cut a cylindrical hole down the Y direction, use:
c
4.5 6.0 2.0
Where the first two parameters are the X and Z coordinates and the third is the radius of the cylinder. The cut-types shown in bold are not cuts per se, they just modify the lattice within or without the domain.
Cut type parameters
Cylinder c x-center, z-center, radius of cut
Ellipse e x-center, y-center, A-major-axis, B-minor-axis, angle
Pore/Sphere P,w x-center, y-center, z-center, radius of pore Tube T x-center, y-center, outer radius, inner radius Perimeter p x-left, x-right, y-back, y-front, z-lower, z-
upper, depth, material angle
Rod r x-center, y-center, A-major-axis, B-minor-axis, angle,material angle
perimeter v x-left, x-right, y-back, y-front, z-lower, z- upper, depth
Rectangular s x-left, x-right, y-back, y-front, z-lower, z- upper
Mirror m {x,y,z} x-left, x-right, y-back, y-front, z- lower, z-upper
There is a new cut type with identification letter ‘p’ this is a “perimeter” cut type meaning that the first six parameters are the same as a typical rectangular cut, except that the seventh parameter specifies a thickness in the x and y direction. This rectangular perimeter is the material left over. The central part is what is actually cut. The eighth parameter is the angle in radians from the x axis in the XoY plane to rotate the material, this is just the material's orientation, it doesn't rotate the domain. Care must be taken when rotating, since the rotation is made before the cutting, the overall material domain must be able to accommodate the rotation, otherwise the corners may appear to be cut.
The cut type 'v' for perimeter does the inverse of 'p', it actually cuts within the perimeter domain, rather than only leaving the perimeter as material.
The “Mirror” cut is used to make twin boundaries. It reverses, or mirrors, the lattice within the domain and is used, for example, as:
m y
-100.0 100.0 -25.0 25.0 -100.0 100.0
This will reverse the lattice across the Y axis following the formula:
y = cdom(4)-abs(cdom(3)-y)
where cdom(4) is shown above to be 25.0 and cdom(3)=-25.0, for every lattice point, y coordinate.
The cut type “Rod” is designed to be used with the cut type “Ellipse” as the ellipse will cut an elliptical hole and the rod can be used to fill the ellipse with a different material and orientation.
It is important to note that the block and model dimensions should be designed as multiples of the unit-cell lattice constants, a, b, and c. These values can be found in the material files (e.g. AlFCC).
It is important that the imaginary scales, denoted as the negative of their real counterpart, correctly overlap into a real domain. Scales must also be sufficiently large enough to reduce any scale boundary effect.
An example to run this program to generate a model is shown below.
$ /shared/DATA/crystals/Mater_Model7.exe model.in_example The first part is the program executable to run and the first and only parameter is the name of the “model.in” file to be generated from. This program generates a file called: “Model.MD” which can be used immediately for simulation. It is best to rename this file to be more descriptive, such as: “Model.MD_example”. It also makes a file called “Model.xyz” which can be viewed directly with VMD.
a. Auto-Scale Interface Creation
A new version of the model development code was created that will automatically create appropriate scale interfaces given only the inter-atomic cutoff radius. This new code is “Mater_Model8.f90”. The main advantage of this code is to make GP model development easy for the user; all that the user needs to do is to define the real atom and particle domains. For example the “model.in” input file described before could reduce to the following:
2 2 !The number of scales used, GP Scale ratio 177.821 10.887 10.887 !Half model sizes
5.3 !Cutoff radius
4 !number of blocks below
CuFCC 2 1 !material structure, scale, number of cuts -177.821 177.821 -10.887 10.887 -10.887 10.887
s
-127.015 127.015 -10.887 10.887 -10.887 10.887 CuFCC 1 1
-127.015 127.015 -10.887 10.887 -10.887 10.887 s
127.015 -127.015 10.887 -10.887 10.887 -10.887
Notice that the third line is new, this is to define the depth of the Wnimage domain from the interfaces which should be the same size as the cutoff radius used. Also notice that the previously defined imaginary domains are simply removed from the input file, see how much more simple this file appears!
This automatic capability is based on image particle proximity to real particles of the same scale. Specifically, for every real domain that the user specifies, a corresponding imaginary particle scale is made that has a scale n+1 and n-1 of the real scale, n (unless it doesn’t make sense, if n=1 then n-1 is not used, and if n is the number of scales then n+1 is not used). This follows the scale-duality principal described in Section II.A.4. In this example, when the scale-2 domain is generated a corresponding imaginary atomic domain is also made in the same location. Then when the real atomic domain is generated a corresponding imaginary scale-2 domain is made in the same location. At this point the scale interface is already made, however it is grossly over designed. The imaginary
particles in the center and far from the interface are superfluous. Thus after this type of model is made it is filtered into an image removal routine that will only keep the imaginary particles and atoms that are within a cutoff radius of a real atom or particle of the same scale. In this way all superfluous images are removed. This routine increases the computational cost and time of model development, but with the utilization of Verlet Neighbor Lists the speed is greatly increased.
The drawback of this automatic scale interface creation is that specific imaginary domains that would be needed for auto-decomposition (see Sections II.A.4.a and Appendix B.1) would be automatically removed since they are not a part of the scale interface. For this situation either the user could use the older version 7 of the code or they could add an imaginary domain to the model separately, outside of the program. The latter process would require two “model.in” files, one for the main GP model and the other for the imaginary domain. The imaginary domain would need to be made as a real domain first, to prevent it from being automatically removed, and then after it’s made it should be converted to images with the utility “chScale.exe”. This model should then be appended to the GP model. If the user is knowledgeable about proper scale interface design then the former approach is recommended as it is more concise, but for users uncomfortable with scale interface design the latter method is recommended.