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

Pages: 1 2 [3] 4 5 ... 21
Okay, good to here that you solved the problem already.

I still don't understand why the loaded environment module affects the operation of Ovito on your HPC cluster, but I guess that is not important. What counts is that you got it working. In general, however, I can say that the binary Ovito installation packages come with their own copy of the Python interpreter. So there should be no need to load any Python interpreter on the system in order to use Ovito. But I can also say that the Python interpreter shipped with Ovito may not be perfectly isolated from the system environment. So things like environment variables set on the local system may interfere and still affect its operation (possibly letting it crash).

I forgot to tell: Within GDB, type "run" and press enter to start the execution. In case the segfault occurs and execution stops, type "bt" + enter to get the backtrace.
Even without debugging symbols included in the executable, you should get some first, approximate information abut the location where the crash happened.


What happens if you run

  ovitos -c "pass"

This command will execute just the Python "pass" statement and nothing else. If possible, run this in a debugger such as GDB:

  gdb --args ovitos -c "pass"

Perhaps this allows you to capture a stack trace, which could tell us more about the reason for the segfault.

The NearestNeighborFinder.find() yields a bunch of information about the neighbors of a particle. Aside from the distance and the neighbor vector, it also returns the global index of the current neighbor particle. This index can be used to access other properties of the neighbor particle. Example:

Code: [Select]
foo_values = data.particle_properties['foo'].array
for index in range(data.number_of_particles):
    for neigh in finder.find(index):
        neigh_foo = foo_values[neigh.index]  # Access the 'foo' value of the current neighbor


Yes, unwrapping the atomic coordinates can be achieved, but it's complicated:

  • First, go to frame 0 of the sequence and make a copy of the current atomic positions using the Freeze Property modifier. Name the copied property "pos0", for example.
  • Use the Displacement Vectors modifier to let Ovito compute the atomic displacements with respect to the initial positions. This is where the minimum image convention comes into play.
  • Finally, use the Compute Property modifier to overwrite the values of the Position property. For the X component, enter the expression "pos0.X+Displacement.X". For the other two components, do correspondingly.


After your activate the WignerSeitzAnalysisModifier.per_type_occupancies option, the occupancy numbers will be calculated element-wise. Instead of a total "Occupancy" number for a site, partial numbers "Occupancy.1", "Occupancy.2", etc. are calculated. The sum of all partial occupancy numbers for a site is always equal to the total number computed without the per_type_occupancies option.

Given that you have two atom types in your simulation, you need to make sure that both partial occupancy numbers are zero for a Si-site to detect vacancies:

  Occupancy.1 == 0 && Occupancy.2 == 0 && ParticleType == 1

This expression will make sure that Si-sites now occupied by a C-atom in the displaced configuration are excluded from the selection.
Regarding your second question: The expression

  Occupancy.1 == 2 && ParticleType == 1

will select Si-sites that are occupied by exactly two Si-atoms, regardless of how many C-atoms are on the same site. The question is: what exactly do you consider a "Si SIA"? Maybe a site that was originally occupied by a C-atom and is now occupied by two Si-atoms should also count as a "Si SIA". To catch those kinds of sites as well, you might have to extend the expression with additional criteria that are combined with a logical OR operator (||).


Support Forum / Re: How to calculate max and min of cluster's position
« on: February 13, 2018, 09:20:46 AM »
Hi Kevin,

Thank you for sharing the solution to your own problem. I hope you don't mind if I comment on your script. I agree with the way you determine the size of the stacking fault. But I am wondering if the sequence of 5 modifiers is really necessary to extract the SF atoms. In my eyes, the ClusterAnalysisModifier is not necessary. You could have directly deleted all non-HCP atoms as follows:

Code: [Select]
# Modifier 1: CNA                                                                                           
# Modifier 2: Select non-HCP atoms                                                                 
node.modifiers.append(SelectExpressionModifier(expression = 'StructureType!=2'))
# Modifier 3: Delete them                                                                                   

A ClusterAnalysisModifier would only be necessary if there are several independent HCP atom clusters in your system and you want to focus on a particular one of them, perhaps the largest one. Then, however, you should make use of the ClusterAnalysisModifier.sort_by_size option and delete all atoms with property Cluster!=1.

Best regards

Support Forum / Re: source, output attributes
« on: February 12, 2018, 09:51:34 PM »
I guess this behaviour is due to the two parallel caches the FileSource maintains. There is one cache (let's call it 'A') that contains the data for the most recently requested frame, and a second cache (let's call it 'B') for the data at the current animation time. When a new request for a frame is processed, the FileSource first checks if the data for the requested frame is already available in either of these two caches. Only if that is not the case, the data is retrieved from the external file(s).

So in your case, the following happens:

Code: [Select]
import_file(...) # This fills cache B with data of frame 0
node.compute(3)  # This fills cache A with data of frame 3
node.compute() # Cache A already contains the data for the requested frame. Returns immediately.

Cache B is not updated again in this case. But cache B is exactly the one that the FileSource object exposes to the Python script. This explains the output you see, I think.

Based on your input, I extended the Python interface of the FileSource class a bit. In the newest development build of OVITO, the class provides a new method compute(), allowing you to request arbitrary frames from the FileSource. Now it no longer matters which data is currently in the visible cache of the FileSource. Please see the updated documentation for details:

Support Forum / Re: Correlation Function for Python
« on: February 12, 2018, 09:33:32 PM »
I have published a new development build (dev155) of OVITO 3.0, which provides Python-based access to the Correlation Function modifier an its results: 

Support Forum / Re: Correlation Function for Python
« on: February 12, 2018, 04:49:19 PM »
Hi Morgane,

Python bindings for the "Correlation Function" modifier have been a missing program feature in the existing program versions. You are the first one asking for it.
Let me add the Python interface to the current development version. Maybe I can provide a new program version already by tomorrow.


I tested the Python script with the current development version of OVITO 3.0 and also an older version (dev52). In both cases I get the error message notifying me about the invalid selection expression, as expected.
Not sure why you don't get the error. Perhaps because you are using an even older development version, where the new data pipeline system wasn't completed yet. Please check if you get correct behavior with the current dev version, and let me know if not.


I noticed a typo in your selection expression: "Occupancy == 2 && Particle Type == 1".
Within selection expressions, spaces in property names must always be omitted due to limitations of the expression parser. Like that: "ParticleType == 1"

However, I am surprised that you didn't see a corresponding error message. Normally, your final call to node.compute() should raise a Python exception in this situation. In the GUI, I am indeed seeing an error message being displayed: "Unexpected variable "Type" found at position 27" when using the same selection expression. I will need to check why the error is not getting raised in the Python script --after you confirmed that this is indeed the origin of your issue.


Support Forum / Re: Accessing ovito source for histogram
« on: February 10, 2018, 09:22:26 AM »

the routine for the GUI function, which writes the histogram data to an output text file, is found on the c++ side:

Let me know if that doesn't fully answer your question.


Support Forum / Re: source, output attributes
« on: February 10, 2018, 08:51:21 AM »
Dear Kevin,

Let's first speak about OVITO 2.9.0:

To me, the output seems reasonable. Both fields, node.source and node.output, represent data caches for the input and output data of the pipeline, respectively. If you evaluate the pipeline at timestep 7500, then it's expected that after evaluation is complete both caches contain data from timestep 7500. Why would you expect to find data from a completely different timestep (0) in the pipeline input cache?

The input cache (node.source) works as follows: Whenever a pipeline evaluation is requested for a certain animation time (timestep 7500 in your case), OVITO checks if the data present in node.source is for that timestep. If yes, it is directly used as input for the modifier pipeline. If not, the data for the requested timestep is loaded from the external input file and stored in the cache before passing it on to the modifier pipeline.

Now about OVITO 3.0.0:

The caching mechanisms have become more complex in this version, because the pipeline tends to be evaluated at different timesteps simultaneously in this version. From the Python perspective you only see one of these caches. node.source is the cache for the current animation time, which is controlled by the global ovito.dataset.anim.current_frame setting (basically the time slider in the GUI). This setting is not affected when you call node.compute(3). Thus, you'll still find data for the current animation time (frame 0) in that input cache.

(The second input cache, which contains the data from the most recent evaluation (frame 3), is not accessible from Python. I'm not sure if that poses a limitation from the user's perspective or not.)

Furthermore, as you said, in OVITO 3 the node.output cache for the output data is gone (should no longer be used). Instead, the Python script should take care of the "caching" itself by storing the output DataCollection returned by compute() in a local Python variable (e.g. "theOutput" in your case).

In OVITO 3.0, accessing the node.output field is equivalent to invoking node.compute() (without frame parameter). Thus, it will always yield the pipeline output for the current animation time. It's basically a poor emulation of the old node.output field from OVITO 2.9.0, just to provide some limited backward compatibility.

Support Forum / Re: Box size in Ovito scripting
« on: February 09, 2018, 05:50:55 PM »
Yes, the box size values ("Width", "Height", "Length") shown in the GUI are implicitly computed from the cell vectors (or, equivalently, the cell matrix). They are not independent parameters.

The cell origin (stored in the 4th column of the extended cell matrix) is not related to the box size nor the three cell vectors. That means you can ignore it if you are just interested in the size of the box. Note that this is different from the convention used by LAMMPS, which uses a "low boundary + high boundary" representation of the box. OVITO uses an "origin+size" representation instead.

Pages: 1 2 [3] 4 5 ... 21