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 ... 8 9 [10] 11 12 ... 18
Support Forum / Re: using user-defined particle property
« on: February 07, 2018, 12:26:37 PM »
Yeah, you are right. That's something I overlooked in your code.

In the old OVITO version (2.9.0), standard particle properties could be accessed as if they were Python attributes, but user-defined properties required the particle_properties['...'] notation (key-based dictionary access). In the upcoming OVITO version (3.0.0), the key-based dictionary access must be used for all properties. So particle_properties['c_c2'] is the right way to go in any case.

Support Forum / Re: installing two versions of OVITO
« on: February 05, 2018, 02:20:36 PM »
Now we have a new dev build of Ovito 3.0 for macOS, which should be working again:

The version of the script you posted is meant to be run from the terminal with the external ovitos script interpreter program (or using the Scripting/Run Script File function from the main menu of the graphical version of OVITO). It is a batch script that performs all operations from beginning to end (including data file import).

It seems that you have been trying to use this batch script like a user-defined modifier function inside the graphical version of OVITO. For this approach, you need to instead use the first version of the example script posted on this page:

If you want to learn more about the difference between batch scripts and user-defined modifier function scripts, see this page of the user manual:

Support Forum / Re: ovito on Linux
« on: February 02, 2018, 10:26:41 PM »
Yes, changing the name of the executable is possible, but it has to remain inside the bin/ directory.

If you want to make the executable runnable from another directory, possibly under a different name, you can create a symbolic link to the executable using the "ln -s" Linux command.

Support Forum / Re: Writing a modifier that operates on several frames
« on: February 02, 2018, 03:42:52 PM »
I see. So far I already implemented the InterpolateTrajectoryModifier as a prototypical example for a modifier that samples the input trajectory at several different times.
It queries in the upstream data pipeline at one additional animation time to obtain two snapshots of the particle configuration between which it interpolates. In a similar fashion one could write a time-averaging modifier that queries an input particle property at several times within a window and then outputs the average value.

Support Forum / Re: Writing a modifier that operates on several frames
« on: February 02, 2018, 01:18:00 PM »
Hi Matteo,

so far that statement only applies to native modifiers written in C++, not Python script modifiers. The latter still have only access to the data from the upstream pipeline evaluated at the current time.
I haven't spent much thoughts yet on how (and if) the Python modifier interface can be extended to also support more advanced scenarios. But I will definitely do it when I find more time to work on the new architecture.

Perhaps you can briefly describe what kind of user-defined modifier function you have in mind that requires access to other simulation times. I can take this into account in the design. Would your function need information about the entire simulation trajectory, or particular frames only like the first or the preceding frame?


Support Forum / Re: installing two versions of OVITO
« on: February 01, 2018, 10:03:13 PM »
Yeah, I noticed too that it isn't working yet. Sorry for the premature message.

Something is wrong with the code signing of the new application bundle and the Gatekeeper service of macOS refuses to execute the application because of that. I'm still investigating why it is broken.

Support Forum / Re: installing two versions of OVITO
« on: February 01, 2018, 07:10:10 PM »
Please download OVITO 3.0.0 again and try once more:

It almost appears to have been a temporary problem only. I downloaded the .dmg package again with Safari and this time it ran without problems. Then I tried again using the Firefox browser and it also worked (unlike the first time I tried).

Note that I have now additionally uploaded a slightly updated development version (104), which contains a bug fix for an unrelated problem.

Support Forum / Re: installing two versions of OVITO
« on: February 01, 2018, 06:14:11 PM »
Yes, indeed. The app bundle seems to be broken. I will try to figure out why and fix it.

In the meantime you can still run the executable inside the Ovito 3.0.0-dev101 app bundle directly by opening a terminal window. Change to the directory where you extracted the bundle and enter the command:

Support Forum / Re: installing two versions of OVITO
« on: February 01, 2018, 05:26:11 PM »
Yes, it's possible to install both side by side. Simply rename the application bundle after installation from "Ovito" to "Ovito 2.9.0" or "Ovito 3.0.0" in the macOS finder.

Support Forum / Re: Two problem about W-S defect analysis
« on: February 01, 2018, 02:13:49 PM »
my apologies for the late reply. I was on vacation for a few days and now I am trying to catch up now.

When using the W-S function in OVITO it's important to realize that this function throws away the displaced atomic configuration and replaces it with the perfect crystal configuration. This is explained in the user manual:

It means that any subsequent selection operation will act on sites from the perfect crystal, not atoms from the displaced configuration (which are all thrown away). The only information on the original atoms that is retained is the count of each species that was occupying each site. So in your case this selection expression

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

will select A-sites occupied by 0 A-atoms and 2 B-atoms. Notably, it will not select the B-atoms that occupy these sites.

The general problem is that OVITO has to throw away one of configurations, either the reference or the defective one, after the W-S analysis has been performed. Any subsequent selection operation can act only on the retained configuration, not both configurations simultaneously. In the current W-S implementation, the decision has been made to retain the reference site configuration and throw away the defective atom configuration. This allows, for example, to select vacancies (sites with Occupancy==0), which would not be possible if we were retaining the defective configuration, because vacancies do not represent physical atoms.

For a future version of OVITO I am thinking about extending the W-S modifier. Maybe add a switch that allows the user to change this default behavior and instead keep the defective configuration and throw away the reference configuration. This would allow one to explicitly visualize the two or more interstitial atoms that are sitting on the same site. The meaning of the "occupancy" property would be changed then. It would now denote the total number of atoms occupying the same site as the atom to which the property relates.

Best regards,

Support Forum / Re: cannot construct mech in dislocation analysis
« on: February 01, 2018, 01:48:44 PM »
I was gone on vacation for a few days. Thanks for sending the .ovito file.

I think I cannot give you a definite explanation for the error unless I am able to reproduce the problem myself. So far you only gave me the "907" data file, probably the first frame from the sequence you are analyzing. Since the error occurs later at the 4th frame, it would be great if you could send me the corresponding data file too.


Support Forum / Re: histogram over all frames
« on: February 01, 2018, 10:35:56 AM »
The data pipeline consists of the sequence of modifiers that you add using the modifiers.append() method. The compute() method requests an evaluation of the data pipeline. In other words, it lets every modifier in the sequence act on the atomic data, one after the other. The result of these computations is returned by compute() itself or can be accessed later on through the node.output field. If you call compute() before the HistogramModifier has been added to the pipeline, it will compute the results only up to and including the SelectExpressionModifier. I guess so far everything has been clear to you already.

Behind the scenes, however, a caching mechanisms is in place. The details of this mechanism have changed from OVITO 2.9.0 to 3.0.0, but in the old version it worked as follows: After a pipeline evaluation is complete, OVITO stores the resulting data in the node.output field. In addition it memorizes the point up the which the pipeline was computed, in this case the SelectExpressionModifier. And it memorizes the animation time for which it was computed (dataset.anim.current_frame).

If you add the HistogramModifier to the pipeline after the first call to compute() and then call compute() a second time, OVITO will remember that the data currently in the cache already represents the state after the SelectExpressionModifier. Since the pipeline has only changed behind this caching point but not in front of it, OVITO can directly continue with the application of the HistogramModifier to the cached data. No re-evaluation of the other two modifiers takes place. I think this is why the error doesn't occur in this case. The error seems to be caused by the successive evaluation of the SelectExpressionModifier and the HistogramModifier.

This would also explain why the error occurs again once you change the current animation time (dataset.anim.current_frame): OVITO recognizes that the cached data is out of date and a complete pipepline evaluation is triggered, leading to the error.

Support Forum / Re: histogram over all frames
« on: January 31, 2018, 11:06:41 PM »
Your script looks okay. So I tried it on my computer and ran it with OVITO 2.9.0. I get the same error message.

The error must be caused by some unfavorable interplay between the SelectExpressionModifier and the HistogramModifier. If I take one of them out, the error disappears (but the script doesn't work as intended anymore, of course). I guess you discovered a bug in OVITO 2.9.0.

The good news is that the same script works normally when I run it using OVITO 3.0.0. Here, the pipeline system has been completely rewritten. So the bug is probably gone. My suggestion is that you switch to this newer version of OVITO, at least for this particular problem.


Support Forum / Re: using user-defined particle property
« on: January 31, 2018, 10:39:15 PM »
Dear Sepideh,

Hmm, I would expect this to work and I don't have an explanation for the error at the moment. But I have to admit that I never tested the CFG format reader with this particular type of CFG file written by LAMMPS.

Can you please attach one of your CFG files as well as the OVITO Python script? I will check what is going on. If the CFG file is too big, please post at least the header part of the file (including the "auxiliary" lines).



Support Forum / Re: histogram over all frames
« on: January 31, 2018, 01:23:35 PM »
Dear Kyu,

you made the classic mistake of appending modifiers to the data pipeline more than once from inside the for-loop. Note that every call to node.modifiers.append() extends the data pipeline by one step. Since you do this repeatedly, the pipeline will become longer and longer with every iteration. That is, it will contain the same modifiers several times. Thus, the CNA, selection and histogram computations will be performed multiple times for a single simulation frame when you call node.compute() to evaluate the pipeline.

The solution is to populate the pipeline with modifiers only once, i.e. move all calls to node.modifiers.append() in front of the for-loop (initialization phase). Then call node.compute() repeatedly inside the loop to evaluate the pipeline at different simulation times.

In a more recent version of the user manual I tried to make this pitfall more clear, because new users tend to make this kind of mistake. You can find the updated passage here (note that this is for Ovito 3.0.0, so some Python class names have changed):

Support Forum / Re: getting animation to save file
« on: January 30, 2018, 04:08:56 PM »
Dear rgust,

Please excuse my late reply. I've been on vacation for a few days.

It sounds like you've already figured out yourself how to solve the problem. I am still not sure what kind of issue you were struggling with when you wrote the first post. But your second post suggests that it was due to some confusion about the way OVITO saves (or rather doesn't save) the rendered images and videos. I took your feedback as an opportunity to extend and revise the corresponding section in the user manual:

Hope that clarifies the situation. If you have any further comments or feedback, please let me know.


Support Forum / Re: Parsing error in line 428114 of XYZ file
« on: January 27, 2018, 11:06:32 AM »
Didn’t you forget the comment line, which follows the number of atoms line?

Support Forum / Re: How to export custom variables by python scripts?
« on: January 23, 2018, 06:34:14 PM »
If you want to write the list of bonds of every (or almost every) atom to a single file, then you should do this using Python's built-in I/O functions. The only file format supported by OVITO's export_file() function which includes bond lists is the LAMMPS data format. But this format stores the bond list in arbitrary order, not sorted by atom, and is probably not what you want.

So I would suggest you open a Python file object for writing, iterate over the atoms, iterate over the bonds of the current atoms, and write each bond's information to the output file. This would look like the following pseudo-code:

Code: [Select]
file = open("/Users/eason851021/Documents/1635/output_file.txt", "w")]
for particle_index in range(node.output.number_of_particles):
    for bond_index in bond_enumerator.bonds_of_particle(particle_index):
        atomA = bonds_array[bond_index][0]
        atomB = bonds_array[bond_index][1]
        file.write("Atom %i has a bond to atom %i\n" % (atomA, atomB))

Support Forum / Re: How to export custom variables by python scripts?
« on: January 23, 2018, 05:27:17 PM »
...and to explain the error message you see:

Let's assume atomA is 0 and atomB is 1. Then this code
Code: [Select]
export_file(node, "/Users/eason851021/Documents/1635/output.imd",
   format = "imd",
   columns = ["Particle Identifier", "Particle Type", "%i"%(atomA), "%i" % (atomB)])
resolves to
Code: [Select]
export_file(node, "/Users/eason851021/Documents/1635/output.imd", format = "imd", columns = ["Particle Identifier", "Particle Type", "0", "1"])
However, "0" does not name a particle property. The columns list must only contain names of properties that are associated with every particle in the dataset to be exported.

Support Forum / Re: How to export custom variables by python scripts?
« on: January 23, 2018, 05:21:00 PM »
Note that the export_file() function always exports all atoms that leave the data pipeline. It cannot selectively output only a subset of atoms.

However, you can insert modifiers into the data pipeline that selectively delete atoms, so that export_file() sees only a reduced subset of atoms that need to be exported.

In your case, if I understand you correctly, you want to produce an output file that contains exactly two atoms, whose indices are given by atomA and atomB. Thus, we have to filter out all other atoms. I would do that by inserting a SelectExpressionModifier followed by a DeleteSelectedParticlesModifier:

Code: [Select]
sel_modifier = SelectExpressionModifier()

Make sure this insertion is done only once before the for-loop.

Later, once you have determined which two atoms you want to export, you can dynamically set the selection expression so that all atoms except the two atoms you want to keep are selected (and subsequently deleted by the DeleteSelectedParticlesModifier following in the pipeline):

Code: [Select]
sel_modifier.expression = "ParticleIndex != %i && ParticleIndex != %i" % (atomA, atomB)
export_file(node, "/Users/eason851021/Documents/1635/output.imd", format = "imd", columns = ["Particle Identifier", "Particle Type"])

Support Forum / Re: Atomic Strain tensor
« on: January 23, 2018, 01:17:35 PM »
I've received your data file now, but haven't found the time yet to take a look at it.

Regrading the calculation formula you asked about: delta_cur=delta_ref+neigh_displacement-center_displacement

Here, delta_ref denotes the vector connecting the central atom A, located at initial position x0(A), with its neighbour atom B, located at initial position x0(B):

delta_ref = x0(B) - x0(A)

Similarly, we have for the neighbour vector in the deformed (current) configuration:

delta_cur = x1(B) - x1(A)

Here, x1(A) and x1(B) denote the locations of the the two atoms in the deformed configuration. We also have the two atomic displacements:

u(A) = x1(A) - x0(A)  (= "center_displacement")
u(B) = x1(B) - x0(B)  (= "neigh_displacement")

Thus, we can express the neighbour vector in the deformed configuration in terms of the old neighbour vector and the displacements of the two atoms:

delta_cur = x1(B) - x1(A) = [x0(B) + u(B)] - [x0(A) + u(A)] = [x0(B) - x0(A)] + [u(B) - u(A)] = delta_ref + u(B) - u(A).

Support Forum / Re: Atomic Strain tensor
« on: January 23, 2018, 08:14:19 AM »
I didn't receive any files via email, sorry.

Why did uploading to the online forum fail? Was it the file size (there is a 20MB limit, I think) or the file extension (.txt)? Maybe zipping the files would help.

Support Forum / Re: Python script for cluster size
« on: January 22, 2018, 07:21:01 PM »
Is this the entire script code? It surprises me that the initial script version was failing with an error message in the numpy.savetxt() line, but now the corrected script, which doesn't generate the permission-denied error anymore, doesn't produce any file output. I cannot imagine that it gets stuck inside the savetxt() function.

How are you running this script? Are you using the "Run Script file" function form the menu (which would be correct), or are you running this in the context of a Python script modifier (which would be wrong)?

Support Forum / Re: Atomic Strain tensor
« on: January 22, 2018, 06:58:50 PM »
What concerns me is that you conducted this analysis in 3d-mode. For a true 2d-system like a graphene sheet, which is exactly planar in the undeformed configuration (I assume), the strain tensor calculation in 3d-mode will yield in unpredictable results --or an error message if you are lucky.

The reason is that you cannot calculate a 3x3 deformation gradient from a 2d-system where all atomic z-coordinates are zero. Tensor components such as F_zz, which involve the derivate of the displacement field with respect to the z-coordinate, remain undefined in this case. The implementation should catch this kind of degenerate situation, but it might not always be able to do so due to numerical errors. If that happens, tensor components like F_zz may take on arbitrary values. Consequently, the strain tensor E calculated from F will also be arbitrary (all of its components, not just the ones involving z-coordinates).

Have you tried doing this calculation in 2d-mode? You can switch to 2d-mode in the properties panel of the simulation cell. In 2d-mode, OVITO does not try to calculate the z-coordinate elements of the F tensor. Instead, they are set to fixed values assuming a plane strain situation.

If you can, please also post the simulation files for the initial and deformed configurations. Then I can take a look at the displacements of the atoms myself and check the strain calculation. I particularly would like to know if there are any out-of-plane displacements.

Support Forum / Re: Python script for cluster size
« on: January 22, 2018, 06:34:50 PM »
Since you are working under Windows, the current working directory while you are running this script in Ovito is probably "C:\Program Files\Ovito\".
That means the call to numpy.savetxt("Cluster3.txt") will try to write to the output path "C:\Program Files\Ovito\Cluster3.txt", which probably refers to a write-protected location. The file I/O operation fails.

The solution is to specify an absolute output path by prepending the destination directory to the file name:

output_filepath = path + "\\Cluster3.txt"

Support Forum / Re: Computing Per-atom Change
« on: January 22, 2018, 08:15:55 AM »
Dear Farheen,

In this case, the Freeze Property modifier is your friend. Please see the "Example 2" on this page. It should answer your question.


Support Forum / Re: Atomic Strain tensor
« on: January 22, 2018, 08:11:24 AM »

Yes, this a strange result indeed. Is this calculation done in 2d-mode in OVITO? If so, how did you implement the plane strain calculation? In OVITO, particular elements of the V and W matrices are set to special values at some point of the calculation and then OVITO continues as if the problem where 3d (see source code).

And did you also compare the atomic deformation gradient with your solution? The def gradient is an intermediate calculation results and could help locate the source for this deviation.


Support Forum / Re: rotation single frame
« on: January 19, 2018, 08:35:53 AM »
Hi Enrique,

Yes, all you need to know about this is described on this page:

Here is an overview of the steps:

  • Open the Animation Settings dialog and set the desired animation length
  • Activate Auto-Key mode
  • Go to the last animation frame
  • Activate the Rotation tool in the upper toolbar and enter a rotation angle of 360° into the z-axis axis input field that appears below the viewports.
  • That's it, the selected object should now perform a 360° rotation. You can deactivate Auto-Key mode again

Support Forum / Re: DXA for molecular crystals
« on: January 18, 2018, 06:33:02 PM »
Yes, as long as the representative points form one of the currently supported lattice types. That is fcc, bcc, hcp, cubic diamond and hexagonal diamond.

Pages: 1 ... 8 9 [10] 11 12 ... 18