Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Xtof

Pages: [1] 2 3 ... 5
1
Support Forum / Re: PKA (primary knock atom)
« on: September 11, 2018, 08:42:31 AM »
Hi,

I am not sure I understand what you mean by "observe the PKA atom"
If what you want to is to see the defects caused by the PKA in OVITO, first dump in LAMMPS snapshots of the cell every N time steps.
Then, in OVITO you can calculate for each snapshot the SIA and V using the Wigner-Seitz modifier.

Hope it helps.
Cheers,
Christophe

2
I tried with 1/2<111> DL and it works. Ovito correctly detects a 1/2<111> dislocation. However, after equilibration, the loop adopts a strange shape, like a deformed platelet. I do not know if that is correct. I guess it has to do with the potential (Ackland 2004).

For <100> vacancy loops, Ovito was not able to detect any loop. Again, it might be due to the potential. As you suggest, a colleague of mine, also mentionned a possible problem with the potential and as consequence, that there is no spontaneous collapse.

Xtof

3
Hi Alex,

I determined the position of the atoms as to form a <100> interstitial DL. Then, I simply removed these atoms and minimized the energy. The resulting group of atoms has the shape of a platelet, like the <100> would have. See in attachment the position of the vacancies according to the WS analysis.

The result of the CNA is also attached. I removed from the view the atoms with perfect BCC structure type. It shows the cluster has a platelet-like shape.

Xtof



4
Hi Alex and Ovito users,

Recently I started working with the DXA modifier of Ovito to determine the Burguers vector of Dislocation Loops (DL) in Fe. I succeeded to define interstitial 1/2<111> and <100> DL with LAMMPS. Ovito identified well their Burguers vector in both cases.
Then, I tried to do the same with vacancy DLs. In the case of a vacancy <100> DL (89 sites), I just removed the atoms and equilibrated the system in LAMMPS. In this case, Ovito was not able to identify a dislocation segment.

Any idea why this occurs? Is it due to a limitation of Ovito in this particular case or could it be due to a wrong description of these objects by MD (wrong potential)?

Many thanks in advance and best regards,
Christophe

5
The solution I proposed works. It was quite easy to implement.
I keep in mind your alternative solution in case of...

Thanks again and best regards,
Christophe

6
Maybe a solution is to calculate the min and max coordinates of the vertexes for each dislocation line and then check for each cluster if its average coordinates (xmean, ymean, zmean) are such that:

xmin <= xmean <= xmax
ymin <= ymean <= ymax
zmin <= zmean <= zmax

When the average coordinates of a cluster fulfil these 3 conditions, then it means that the cluster is inside this dislocation line and we can say that the Burgers vector of the dislocation is the Burgers vector of this cluster.

Xtof

7
Hi Alex,

Here is a cascade of 150 keV in W. Red balls are SIAs and the white ones, vacancies. As you can see, relatively large clusters of SIAs form, with a dislocation line around. In this case, Ovito identifies 4 dislocs of type 1/2<111> (two of them are very close).

What I would like to do is to know the Burgers vector of the clusters obtained with the WS modifier.

What comes to my mind is to use the vertex coordinates given by the DXA modifier and compare them to the coordinates of clusters obtained with the WS modifier. I guess that by comparison, I could deduce that a certain dislocation with id i corresponds to a certain cluster with id j.

What do you think?
Many thanks in advance and best regards,
Christophe

8
Dear Alex and OVITO users,

I managed to write, on the one hand, a Python script to analyse clusters with the Wigner-Seitz modifier, and, on the other hand, a Python script to analyse dislocations with the DXA modifier.
Both scripts work well separately.
With the first one, I get the size, nature (SIA or V) and coordinates of clusters. With the second one, I am able to determine, when clusters are sufficiently large, their Burgers vector. For n>=7 (in bcc Fe) the DXA modifier identifies very well 1/2<111> dislocation loops.
Now, what I would like to do is, when a cluster is sufficiently large and a dislocation loop is identified, correlate the Burgers vector given by the DXA modifier with the corresponding information obtained with the WS modifier in order to store in a file, the size of the cluster, its nature (SIA or V), its coordinates and its Burgers vector.

How to correlate the information obtained with the WS modifier with that obtained with the DXA modifier? Any idea how to do that?

Many thanks in advance and best regards,
Christophe

9
Support Forum / Identification of Burgers vector of defects
« on: March 05, 2018, 09:39:50 AM »
Dear Alex and OVITO users,

Under collision cascade, sometimes, relatively large clusters of defects can form. In particular, Dislocation Loops.

I would like to determine their Burgers vector. Is it possible with the Dislocation Analysis modifier? If so, I would like to know if it is possible to distinguish between defects with a Burgers vector <111> from those with a Burgers vector <-1 1 1>.

With best regards,
Christophe

10
Update.

With the support of the HPC Marconi we found why it fails.
It is due to the module python/3.5.2. It has been working with this module during months but suddenly, it stopped working. They likely changed something, recompiled some modules, who knows...

However, it works with module python/3.6.4. That is a good news.

So it is solved.

The support told me they would investigate that to understand why it fails with module python/3.5.2. I will update you with the latest news.

Christophe

11
Sorry, I have used gdb few times.

The result of the run inside gdb is:

Starting program: /marconi/home/userexternal/cortiz00/bin/ovitos_dev115 -c pass
warning: File "/marconi/prod/opt/compilers/gnu/6.1.0/none/lib64/libstdc++.so.6.0.22-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load:/usr/bin/mono-gdb.py".
To enable execution of this file add
   add-auto-load-safe-path /marconi/prod/opt/compilers/gnu/6.1.0/none/lib64/libstdc++.so.6.0.22-gdb.py
line to your configuration file "/marconi/home/userexternal/cortiz00/.gdbinit".
To completely disable this security protection add
   set auto-load safe-path /
line to your configuration file "/marconi/home/userexternal/cortiz00/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
   info "(gdb)Auto-loading safe path"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffe83b8700 (LWP 54119)]
Missing separate debuginfo for /marconi/home/userexternal/cortiz00/ovito-3.0.0-dev115-x86_64/lib/ovito/plugins/../libfftw3.so.3
Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/71/1de7374ad3a5db27f41b97b3ffa32025c08a84.debug
Missing separate debuginfo for /marconi/home/userexternal/cortiz00/ovito-3.0.0-dev115-x86_64/lib/ovito/plugins/../libssl.so.0.9.8
Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/6c/0495a5040d7276bdad1f07fbc30285a140446d.debug
Missing separate debuginfo for /marconi/home/userexternal/cortiz00/ovito-3.0.0-dev115-x86_64/lib/ovito/plugins/../libcrypto.so.0.9.8
Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/69/4b2605b6fd822a880709e0b17561be88810f41.debug

Program received signal SIGSEGV, Segmentation fault.
PyType_IsSubtype (a=0x7365636e615f7061, b=0x7fffd013d680 <sipVoidPtr_Type>) at Objects/typeobject.c:1343
1343   Objects/typeobject.c: No such file or directory.
Missing separate debuginfos, use: debuginfo-install expat-2.1.0-8.el7.x86_64 fontconfig-2.10.95-7.el7.x86_64 freetype-2.4.11-11.el7.x86_64 glibc-2.17-106.el7_2.8.x86_64 libICE-1.0.9-2.el7.x86_64 libSM-1.2.2-2.el7.x86_64 libX11-1.6.3-2.el7.x86_64 libXau-1.0.8-2.1.el7.x86_64 libXcursor-1.1.14-2.1.el7.x86_64 libXdamage-1.1.4-4.1.el7.x86_64 libXext-1.3.3-3.el7.x86_64 libXfixes-5.0.1-2.1.el7.x86_64 libXrender-0.9.8-2.1.el7.x86_64 libXxf86vm-1.1.3-2.1.el7.x86_64 libdrm-2.4.60-3.el7.x86_64 libselinux-2.2.2-6.el7.x86_64 libuuid-2.23.2-26.el7_2.3.x86_64 libxcb-1.11-4.el7.x86_64 libxshmfence-1.2-1.el7.x86_64 mesa-libGL-10.6.5-3.20150824.el7.x86_64 mesa-libglapi-10.6.5-3.20150824.el7.x86_64 pcre-8.32-15.el7_2.1.x86_64 xz-libs-5.1.2-12alpha.el7.x86_64 zlib-1.2.7-15.el7.x86_64
(gdb)

Clearly, a segmentation fault occurs. I understand that it is due to typeobject.c that is not found. I tried with dev52 and dev115. Same problem.
Do you think it could be due to a problem with modules that are loaded in the environment of the HPC Marconi? They often change things, which ends up messing up everything for the users...

I also typed bt but the result is a long sequence of lines of code + hexadecimal info. If you think it could give you a hint, I'll send it to you.

12
I could run it with the gdb. It shows nothing.

> gdb --args ovitos_dev115 -c "pass"

GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-80.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /ovito-3.0.0-dev115-x86_64/bin/ovitos...(no debugging symbols found)...done.
(gdb)

It says no debugging symbols found. Doesn't that mean that the code should be compiled with the -g option? Since I use the ovitos binary, maybe that is the reason why it does not show anything.

Christophe

13
Update:
It is not due to this script in particular. Even old scripts that were working on the HPC Marconi no longer work. They must have changed something...

Christophe

14
Dear Alex and OVITO users,

I wrote a script to identify defects in SiC after cascade. I use the WS modifier with the per_type_occupancies option.
I developed the script on my PC (i7 proc, Ubuntu 14.04) with the version dev105 and it works well. Then, I wanted to run it on the HPC Marconi where I have all the data and surprisingly, it does not work. It throws a Segmentation fault. I tried with different versions (dev52, dev105, dev115) and same thing. It is the first time that such problem occurs.
The nodes on the HPC Marconi are 2 x 24-cores Intel Xeon 8160 CPU (Skylake) at 2.10 GHz.

Best regards,
Christophe

15
Hi Alex,

Thanks for the explanation. Clearly, something was missing in my reasoning. Indeed, I did not take into account that a Si vacancy could be occupied by a C atom.
I tried what you said and now it works (version dev105). For a given cascade in SiC, if I compare what I obtain with the global occupancy with what I obtain when using the per-type occupancies, I get the following:

Global occupancy
-------------------

V(Si): ParticleType==1 && Occupancy==0    31 V
V(C): ParticleType==2 && Occupancy==0    61 V


Per-type occupancies
-----------------------

V(Si): ParticleType==1 && Occupancy.1==0 && Occupancy.2==0   31 V
C(Si): ParticleType==2 && Occupancy.1==0 && Occupancy.2==0   61 V


Results are now consistent. All results above were obtained with the Python script (dev105).

However, I noticed a discrepancy between what gives the GUI and what I obtain with the Python script. It occurs when I do it the way I was doing it before, ie without taking into account that C atom could be in a Si vacancy, and vice-versa.

GUI
----

V(Si): ParticleType==1 && Occupancy.1==0   32 V. Here we can see that it is not 31. Means that there is 1 C atom in 1 V(Si)
V(C): ParticleType==2 && Occupancy.2==0   61 V


Python Script
---------------

V(Si): ParticleType==1 && Occupancy.1==0   49 V.
V(C): ParticleType==2 && Occupancy.2==0   74 V

This is very different from what the GUI gives.

Best regards,
Christophe

Pages: [1] 2 3 ... 5