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

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

3
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

4
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

5
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

6
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

7
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

8
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

9
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

10
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

11
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

12
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

13
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

14
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

15
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

Pages: [1] 2 3 4