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
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

16
Dear Alex and OVITO users,

I am trying to determine defects (including antisites) in a binary system such as SiC.
Using the SelectExpressionModifier, it works well.
For instance, to determine the number of Si vacancies (type=1) I proceed as follows:


Code: [Select]

    node = import_file(file_coord_final)
   
    # Construct the modifier for Wigner Seitz analysis of SIA and V
    ws_mod = WignerSeitzAnalysisModifier(eliminate_cell_deformation = True)

    # Load the reference crystal   
    ws_mod.reference.load(file_coord_init)
   
    # Add the modifier to the modification pipeline
    node.modifiers.append(ws_mod)

# Select vacancies of type Si (type=1)
    select_vacancies_mod = SelectExpressionModifier(expression = 'Occupancy == 0 && ParticleType == 1')
    node.modifiers.append(select_vacancies_mod)
   
   
    node.compute()



This works fine and for a given cascade I obtain 31 Si vacancies.

Now, I wish to determine antisites, i.e., Si atoms that are in C vacancies and vice-versa. To do so, I took the example given in OVITO website on a binary system (https://ovito.org/manual/python/modules/ovito_modifiers.html#ovito.modifiers.WignerSeitzAnalysisModifier).
Following this example, I simply extended my script to take into account the occupancy number per particle type.

The resulting script is similar to the previous one, except that the WS modifier takes into account the occupancy number per particle type. Also, in the SelectExpressionModifier, one has to take into account that Occupancy has now 2 components. If for instance, I want to select Si vacancies (type 1), I do the following:

Code: [Select]

...
    ws_mod = WignerSeitzAnalysisModifier(per_type_occupancies = True, eliminate_cell_deformation = True)
...

# Select vacancies of type Si (type=1)
    select_vacancies_mod = SelectExpressionModifier(expression = 'Occupancy.1 == 0 && ParticleType == 1')
    node.modifiers.append(select_vacancies_mod)
   

    node.compute()



This works. However, this time, I get 49 Si vacancies.
Clearly, there is something that I am doing wrong.


I also find a problem with determining the SIA of Si type when I use Occupancy.x. I use the following SelectExpressionModifier to find Si SIAs:


Code: [Select]

    select_SIA_mod = SelectExpressionModifier(expression = 'Occupancy.1 == 2 && ParticleType == 1')


The number of Si SIA I obtain this way is too small and clearly not correct.

Do I use correctly Occupancy.1 in the SelectExpressionModifier?

Any help is appreciated.
Many thanks in advance and best regards,
Christophe

17
It was with version dev39.
With the current dvpt version (dev105), it properly throws an error message when there is a space in 'Particle Type ==1' expression.

Xtof

18
Hi Alex,

Thanks for the very prompt reply.

I confirm this is the origin of the issue. With 'ParticleType == 1' now it correctly gives SIA(Si) = 51. I am using the version 3.0.0 (dev) that you suggested me to try some time ago, the one that included parallelization for the WS analysis.

And I confirm it does not show any error message with Python.

I tried with previous version 2.8.0. In this case, Python does throw an error message if I use 'Particle Type == 1' with space, as you expected.

Xtof

19
Dear Alex and OVITO users,

After a cascade in SiC, I am trying to determine the number of SIAs of type Si (type 1) and those of type C (type 2).
To do so, I started from an ovitos script that was working fine for the Fe case and slightly modified it, changing the selection expression.
To select interstitials of type Si (1) this is what I did:

Code: [Select]

# import the cascade file
node = import_file(file_coord_final)
   
# Construct the modifier for Wigner Seitz analysis of SIA and V
ws_mod = WignerSeitzAnalysisModifier(eliminate_cell_deformation = True)

# Load the reference crystal   
ws_mod.reference.load(file_coord_init)
   
# Add the modifier to the modification pipeline
node.modifiers.append(ws_mod)

node.compute()


# Selection of interstitials of type Si (occupancy >=2, particle type = 1)
select_SIA_mod = SelectExpressionModifier(expression = 'Occupancy == 2 && Particle Type == 1')
node.modifiers.append(select_SIA_mod)
   
node.compute()



All this works but does not return the expected result. The total number of SIAs is 112. I checked it with the OVITO GUI. The number of SIAs of type Si is equal to 51. However, the script returns 112, that is, the total number of SIAs. It seems the condition 'Particle Type == 1' is not taken into account. But likely, I did something wrong.

Could you please give me a hand?

Many thanks in advance and best regards,
Christophe

20
Support Forum / Re: Question about rendering viewport
« on: February 08, 2018, 11:10:37 AM »
Of course! Thank you. It was in front of me and I was not able to see it xD.

Best regards,
Christophe

21
Support Forum / Question about rendering viewport
« on: February 08, 2018, 09:40:25 AM »
Dear Alex and OVITO users,

I am trying to produce a picture of a collision cascade for an article (see attachment). The frame appears in blue but I would like to have it in black. Is it possible? I do not find the option in the rendering panel where to tune this.

Many thanks in advance and best regards,
Christophe

22
Support Forum / Re: how to display dumbbells through W-S defect analysis
« on: December 28, 2017, 05:19:25 PM »
Interesting question. I would also be interested in knowing how to do that.

Best regards,
Christophe

23
No problem. I launched the analysis (Python script) of 30 boxes of 200x200x200 (bcc Fe, 16 million atoms) on a proc 24-cores Intel Xeon 8160 CPU (Skylake) at 2.10 GHz (HPC Marconi).

dev39: 6m28s
dev52: 6m28s

This time we can say that there is no extra cost in using double precision.

Christophe

24
Here is the result. The benchmark was performed with a proc 24-cores Intel Xeon 8160 CPU (Skylake) at 2.10 GHz (HPC Marconi)

Analysis of 30 boxes of 200x200x200 (bcc Fe, 16 million atoms)
dev39: 6m28s
dev46: 6m23s

Analysis of 30 boxes of 300x300x400 (bcc Fe, 72 million atoms)
dev39: 33m28s
dev46: 33m23s

We can say that the CPU time is more or less the same. The performance is not affected by the double-precision.

If you need a reference, I can also do it with the old version of Ovito (WS not parallelized). Just let me know.

Best regards,
Christophe

25
Ok, no problem.

I will do the benchmark with the old version, the version 39 (WS parallelized) and the new version.

Best regards,
Christophe

26
I tried the new version dev39 on the HPC Marconi with 18 boxes with, on average, 635 M atoms.

Old version (serial) on a proc Intel SkyLake: 21h30min
New version dev39 with a proc Intel SkyLake (24 cores): 1h47 min
New version dev39 with an Intel Xeon Phi (Kight Landing 68 cores): 8h31min


Thank you, Alex and congratulations for the great work. This will clearly ease the analysis of defects in large boxes.

With best regards,
Christophe

27
I tried it on my PC (i7 quad) for boxes of moderate size.
Older version: 10min30s
dev39: 5min24s
Already a factor x2.

Now I am trying it on very large boxes (~635 M atoms) on a Xeon Phi (KNL) and on a 24 cores SkyLake. I will let you know.

Best regards,
Christophe

28
Oh waouh. That was fast!
Thanks a lot, Alex. I am going to try it right away. I'll let you know.

Best regards,
Christophe

29
I have monitored the times for the different steps.

- Loading the displaced configuration from disk (635 million atoms, 15 GB): 199.38 s
- node.compute() with the WS analyser: 10507 s

I guess I could try the NetCDF format to speedup the loading of files, but clearly, most of the time is spent on the calculation of defects.

Best regards,
Christophe

30
The number of atoms per dataset varies. It ranges from 89 million to 635 million atoms. In average, each dataset comprises 340 million atoms. The size of some files can reach 24 GB. I understand it can take some time to read and load so many data.

I will check how long it takes to load the displaced configuration file.

I know that LAMMPS allows dumping files as .bin. Would it make it? Would ovitos be able to read these files?

Christophe

Pages: [1] 2 3