The tailed_advector module generates AVS5 style advectors with dynamic tails.
Name | Type | Description | |
in_field | Field | Input data. | |
in_probe | Mesh | Start positions of advectors. | |
in_glyph | Field | Geometry to use for glyph output. | |
Please see the AVS/Express advector documentation for information on inherited parameters.
Name | Type | Description | UI Control |
tracer_len | int | Length of generated tracer line. | Slider |
tracer_style | int | Style of tracer to generate. | Radiobox. |
time_step_interval | float | Interval between time step increments. | UIslider |
Name | Type | Description | |
out_fld | Field | Generated glyph visualization data. | |
out_stream | Field | Generated stream visualization data. | |
out_tracer | Field | Generated advector tail visualization data. | |
out_obj | GDobject | Renderable glyph visualization. | |
stream_obj | GDobject | Renderable stream visualization. | |
tracer_obj | GDobject | Renderable advector tail visualization. | |
time_step_number | int | Current time step number. | |
Generating advectors is a well known method of visualisation and both AVS5 and AVS/Express are supplied with modules that perform this sort of visualization. However the AVS/Express version has significant limitations with compared to the AVS5 version. This project aims to correct these limitations by presenting an improved version of the AVS/Express advector module.
The advector technique is intended to help visualize flow through a set of data. It does this by releasing a sample of zero mass particles and showing how they move with time. The actual simulation of this process is done by generating a series of streamlines and moving the particles along these lines. As well as seeing where the particles are at an instance in time it can also be useful to show where they have been. The AVS5 module allowed this to be done by showing a trace behind each particle. Unfortunately the AVS/Express version of the module is not able to do this. The tailed_advector module in this project adapts the standard module so that it is able to generate advector traces.
As the advector technique models the movement of particles over time it would also be useful if the module could support time dependent data. The standard AVS/Express module does not support this. The tailed_advector module adds the functionality necessary to support time dependent data. More information on how this functionality can be used is given in the descriptions of the TimeDependentAdvector and AltTimeDependentAdvector user macros.
The tailed_advector module has a number of limitations that are not present in the standard AVS/Express advector module. Most of these limitations are practical problems caused by the added complexity introduced into the module.
Movement of particles is not interpolated
As a particle moves along the calculated streamline it is unlikely that it will coincide exactly with a streamline node. Hence the normal advector module interpolates between streamline nodes to calculate the position of a particle. To ensure that the particle matches up with the advector tail the interpolated nodes would have to be added into the streamline mesh. Currently the tailed_advector module does not do this. Instead it does not interpolate the position of particles. Hence particle movement will be noticeably less smooth if there are few nodes.
Only one set of particles can be released per run.
The standard advector module allows particles to be released repeatedly during the course of a single run. This significantly complicates support for time dependent data. Therefore multiple release of particles and the release_time parameter are not currently supported.
Tracer length refers to number of streamline nodes.
The length of each advector trace is specified as a number of streamline nodes. It is not specified as a spatial length. Hence the actual length of the advector trace will depend upon the number of nodes present on the streamline.
Time must be reset before a new probe is specified.
The tailed_advector module internally stores an altered version of the input probe mesh. This is necessary so that the module can cope with time dependent data. If the time is not reset before specifying a new probe then this adapted probe will still be in use.
in_field
Input field structure containing the data that is to be analysed. The field should contain a mesh with associated node data. The first node data component should contain the velocity vector data. The velocity vector should have either 2 or 3 components. All other node data components are ignored.
in_probe
Mesh structure containing the initial positions of each particle that is to be released during the advection process. Normally a FPlane geometry can be used as the input to this port.
in_glyph
Geometry that should be used to represent the particles. Any mesh can be used, however for convenience the Geometries library provides many suitable objects.
Only the parameters added to the standard advector module are described here. For a full description of the parameters of the advector module please see the AVS/Express documentation.
tracer_len
Integer parameter that specifies the maximum number of streamline nodes that should be included in the generated advector tracer. This parameter is ignored if a tracer_style of ADD is specified. To simplify the implementation of this module no attempt is made to ensure that the tracer is of a constant spatial length.
tracer_style
Integer parameter that specifies the how the advector tracer should be generated. Currently there are three possible options.
CAP
Generates a tracer that begins at the initial particle position and continues until either tracer_len steps have been completed or the current particle position has been reached.
CYCLE
Generates a tracer that begins at the current particle position and continues until either tracer_len steps have been completed or the initial particle position has been reached.
ADD
Generates a tracer that begins at the initial particle position and continues until the current particle position is reached.
time_step_interval
This float parameter specifies the time that should elapse between each increment of the time_step_number output. For the time_step_number output to be incremented regularly the time_step_interval should be several times longer than the standard advector step period. If this parameter has a value of 0 the time_step_number output will not be incremented.
out_fld
Output field containing the current particle positions. Each particle position is represented by a glyph geometry. The glyphs are orientated along the current velocity vector. They are scaled and coloured by the magnitude of the velocity vector.
out_stream
Output field containing the streamlines that were used to perform the advection. The field contains a Polyline mesh with the velocity vector stored as a node data component.
out_tracer
Output field containing the generated advector tracers. The field contains a Polyline mesh with the velocity vector stored as a node data component.
out_obj
The GDobject version of the out_fld output, suitable for direct connection to a viewer.
stream_obj
The GDobject version of the out_stream output, suitable for direct connection to a viewer.
tracer_obj
The GDobject version of the out_tracer output, suitable for direct connection to a viewer.
time_step_number
Integer output that is incremented whenever the time specified by the time_step_interval parameter has passed. This output is used by the TimeDependentAdvector module to choose which data set should be used as the input to the tailed_advector module.
The functional macro TailedAdvectorFunc uses the low-level module TailedAdvectorCore. The user macro tailed_advector uses this functional macro and the user interface macro TailedAdvectorUI. The TailedAdvectorParams parameter block is used to connect these components together.
The Synchronize utility module is provided so that two tailed_advector module can be started and reset simultaneously.
Two example applications are provided. The SingleTailedAdvectorEg application reads the 'bluntfin.inp' dataset and allows the user to investigate the air flow by using a single tailed_advector module. The DualTailedAdvectorEg application similarly reads the 'bluntfin.inp' dataset. However it allows the user to investigate the air flow by using two tailed_advector modules simultaneously. The Synchronize module can be used to start both modules.
iac_proj/t_advect/tadvmods.v contains the V definitions of the TailedAdvectorCore module, the Synchronize utility module and the TailedAdvectorParams parameter block.
iac_proj/t_advect/tadvmacs.v contains the V definitions of the TailedAdvectorUI UI macro, the TailedAdvectorFunc functional macro and the tailed_advector, TimeDependentAdvector and AltTimeDependentAdvector user macros.
iac_proj/t_advect/tadvapps.v contains the V definitions of the SingleTailedAdvectorEg, DualTailedAdvectorEg and TimeDependentAdvectorEg example applications.
This project relies on the successful installation of the following components. Without them it will not function correctly.
The low-level TailedAdvectorMods library containing the TailedAdvectorCore module does not specify a process. By default the express process will be used.
Fernand Alcatrao, Advanced Visual Systems, Inc.
Andrew Dodd, International AVS Centre
International AVS Centre Manchester Visualization Centre Manchester Computing University of Manchester Oxford Road Manchester United Kingdom M13 9PL