Vector length legend for vector arrows

This script requires some effort from the user and if used incorrectly it could lead to wrong or misleading information.

One of the EnSight created part types is a “Vector Arrow” part. The length of these arrows can be in proportional to the magnitude of the vector used to create them (the arrows can also be set to have uniform length). So the length of the arrows has definite meaning, but there is no ‘legend’ like the color palette legend which indicates what the length of a vector arrow means.

This script can create such a legend semi-automatically, but the legend is only accurate in certain situations. Since the arrows and the legend are in a 3D space, the direction the arrows are viewed from will affect how large the arrows appear. So I recommend using this legend only in certain situations such as:

  1. When all the arrows lay in a 2D plane, and they are viewed orthogonally with perspective view turned off (orthographic view mode)
  2. When the viewer can rotate the view, and therefore gauge the 3D scene and have an intuitive feeling about the distortion in size due to the viewer’s perspective

Example: The arrow length shows velocity while color indicates temperature.

The script performs a few simple steps:

  1. Create a single node using a point part
  2. Create a vector variable of unit magnitude on the node using MakeScalNode and MakeVect
  3. Create a vector arrow part on this node using this vector variable

The script will prompt you for the location and direction of the arrow. If desired, the location of the arrow can be changed by editing the point part. After the script runs the user should do two things:

  1. Adjust the arrow length by changing the scale factor of the Vector Arrow Legend part
  2. Create a text annotation indicating the meaning of the length of the reference arrow

One must be careful when scaling the legend arrow so that it represents the correct value. One could follow these steps:

  1. Adjust the scale factor of your vector arrow part(s) (not the legend part) to get the desired vector lengths. Call the scale factor “A”.
  2. Choose a vector value that you want the legend to represent, call this value “B”
  3. A * B = C, C is the scale factor you should use for the Vector Arrow Legend part (since the original vector magnitude is one). Now the legend arrow should be the same length in 3D space as an arrow that has vector value B.
  4. The text annotation should use the value B

Download the script.

If you like the idea of a vector arrow length legend and would like to see it added as a standard feature of EnSight you can vote for it and other features at Link to the arrow legend request

Assign Unique Node IDs

EnSight allows nodes and elements on different parts to have the same node ID numbers. For example it is perfectly fine to have a node #1 on every part even though those nodes are not the same node. In most cases EnSight provides a way to distinguish between these nodes, for example if you query a node ID, EnSight will query the node on the part(s) that you have selected.

However, there are a few somewhat uncommon situations when one does need unique node ID numbers. Two example are when using a Periodic Matchfile (for periodic boundaries), and when positioning the plane tool using 3 nodes.

This script will assign a unique node ID to every node in the geometry.

  • Run the script and select a .geo file
  • Requires the .geo file to be ascii (not binary)
  • Starts with node ID 1 and goes up from there
  • Ignores the current node IDs, accepts any type (none, assign, given)
  • Creates a new file with the old .geo name, and renames the original to “…_original.geo”

Possible enhancements (does not do this now):

  • Automatically convert all the .geo files in a transient simulation
  • Read and write binary .geo files
  • Change element IDs

Download the script.

CFx Particle Track Translator

Updated 23-Jan-2013

Users of CFx who utilize discrete particles in their domain were a bit stuck for options for visualizing and analyzing that data in EnSight. The current CFx Export to EnSight format does not include the particle track information, and the Native Reader of CFx files into EnSight did not handle the read of those particle very well (extremely slow for small amount of particle, and unusable for more.). Given some recent inquiries, and bit more investigation on our end, we here at CEI have come up with an alternative approach which seems to work fairly well. We have written a python routine which translates the Particle Traces exported from CFx (to a ascii text file) into EnSight Measured data, which can then be loaded up with your EnSight model. This allows you to now visualize and analyze your CFx particle data in EnSight.

Transient Model Users:
Please note that in order for this routine to work with transient models, the information written to the PT1.trk file for “Traveling Time” must actually be uniquely equal to the Absolute Time (Analysis_Time). According to the CFx usage and documentation, the time written to the PT1.trk file is just the Particle_Traveling time, and therefore is not specifically the unique Analysis_Time (ie the Particle Traveling Time is relative to when that particle started, not a single fixed absolute time (aka Analysis_Time). If your transient model does conform to Traveling_Time == Analysis_Time, then this routine should work. If not, this routine will certainly not work.

The current documentation is kept on our User Defined Tools Help page here:

The translation routine takes existing EnSight Case File exported from CFx, along with a CFx exported Particle Track file (ascii format) (.trk), and translate this into measured data. The routine creates a new .case file with the appropriate additions for the Measured data. The user therefore only has to run this translation routine once, and can directly load the new .case file on his 2nd and subsequent load of the data into EnSight. With the Particle Track information read into EnSight as Measured data, the user can visualize, scale, animate, calculate, and analyze the characteristics of the Particle information.

Please view the Help page link mentioned above before launching the User Defined Tool, as there are a few options to control how the Particle Track information gets translated. Once viewed, please download the python routine below and place it (along with the .png file) into your User Defined Tools area.

Please Click here to download the current Version of this Tool (version 3.0)

Any updates to the routine will be re-posted back here, with appropriate notes/changes. Please feel free to provide feedback and comments back to us so that we can ensure that we provide the most appropriate and useful tool for your visualization needs.

Updated 16-Oct-2012:

Version 2.0 of the routine, with the following changes:

Updated routine to handle different ASCII format (provided by CEI GmbH) (differing number of values per line in file)
Updated routine to handle explicit min and max times provided in the Track files
Updated routine to handle gaps in the ParticleIDs
Updated routine to stop routine if supplied .case file already has Measured Data in it (Information provided in Terminal window)
Updated routine to handle .case file which is already transient (time set += 1)

Updated 23-January-2013:
Version 3.0:
    Updated to handle particles not starting all at the same time (for Transients only)
    Updated to handle Stick & non-existent particles at initial time
    Modified linear interpolation during re-sampling.
    Modified sort algorithm to utilize ‘sorted’ with a lambda.
Please see note at top regarding Transient Model integration.