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 ... 19
1
Support Forum / Re: How can we get a bond angle distribution in ovito?
« on: February 16, 2018, 04:17:41 PM »
Hi there,

Here is a script I wrote some time ago for Ovito 2.9.0 to calculate the bond-angle distribution for a system (for demonstration purposes). It may serve you as a starting point to develop a solution for your specific problem. Disclaimer: I never used the script for real-word analyses and I never verified that it is working correctly. So use with caution.

-Alex

2
I can only guess, but the discrepancy between the results obtained within the GUI and with ovitos are likely due to different modifier settings. In general, when you use a modifier in a script executed with ovitos, its parameters are initialized to hard-coded default values, which are all documented in the Python scripting reference. In contrast to that, when you insert a modifier into the pipeline using the GUI, some its parameters are typically initialized the most-recently used values (Ovito memorizes them in a config file in the user's home directory). Remaining parameter are always initialized to the same hard-coded values as in ovitos.

So please make sure that the WignerSeitzAnalysisModifier.eliminate_cell_deformation setting has been set consistently in the GUI and in the script. Note that, in Ovito 3.0, this parameter has been deprecated and replaced by the ReferenceConfigurationModifier.affine_mapping parameter.

3
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).

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

5
Christoph,

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.

6
The NearestNeighborFinder.find() yields a bunch of information about the neighbors of a particle. Aside from the distance and the neighbor vector, it all returns the global index of the 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
        ...

7
Hi,

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.

8
Christophe,

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 (||).

-Alex 

9
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                                                                                           
node.modifiers.append(CommonNeighborAnalysisModifier())
# Modifier 2: Select non-HCP atoms                                                                 
node.modifiers.append(SelectExpressionModifier(expression = 'StructureType!=2'))
# Modifier 3: Delete them                                                                                   
node.modifiers.append(DeleteSelectedParticlesModifier())

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

10
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
dataset.anim.current_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:

http://ovito.org/manual_testing/python/modules/ovito_pipeline.html#ovito.pipeline.FileSource

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

http://ovito.org/manual_testing/python/modules/ovito_modifiers.html#ovito.modifiers.CorrelationFunctionModifier 

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

-Alex

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

14
Christoph,

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.

-Alex

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

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

https://gitlab.com/stuko/ovito/blob/master/src/plugins/stdmod/gui/HistogramModifierEditor.cpp#L260

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

-Alexander

Pages: [1] 2 3 ... 19