visitwriter

Synopsis

This functional macro writes data to a visit connection.

Input Ports

Name Type Description

SockID int Socket descriptor of the data-connection to the remote application.
Trigger int Triggers writing of data to the data socket when activated.
TimeStamp double Timestamp of the data sent to the visualization
n1 int Size of field in dimension 1
n2 int Size of field in dimension 2
n3 int Size of field in dimension 3
n4 int Size of field in dimension 4
DataInt int[] Data field, if datatype of message is INT32.
DataShort short[] Data field, if datatype of message is INT16.
DataByte byte[] Data field, if datatype of message is BYTE.
DataDouble double[] Data field, if datatype of message is FLOAT64.
DataString string Data field, if datatype of message is STRING.
DataIntScalar int Data value, if datatype of message is INT32 and the field length is 1.
DataShortScalar short Data value, if datatype of message is INT16 and the field length is 1.
DataByteScalar short Data value, if datatype of message is BYTE and the field length is 1.
DataDoubleScalar double Data value, if datatype of message is FLOAT64 and the field length is 1.

Description

This macro sends data to a remote application. The remote application it should connect to is specified by the SockID input. This input will normally be provided by the visitserver macro that has created the connection. The macro is triggered whenever data arrives at the Trigger port. The Trigger input can be connected directly to the Trigger output port of a visitserver macro if only one visitreader or visitwriter macro is being used. If more than one visitreader or visitwriter is connected to a visitserver it is necessary to use a multiplexer in order to select a visitreader or visitwriter macro for each request. There is no implicit distinction between read and write requests. Therefore the user is responsible for using different IDs for read and write requests. When writing data the Trigger output of the visitserver macro will be activated by a request from the remote application. This request can be generated by a visit_recv_4d or visit_recv_string function call.

Whenever the macro is triggered the data that is present on the input ports is sent to the remote application. When requesting data the remote application will request a specific datatype with specific array dimensionality and bounds. The datatype of the request is used to select which of the various input ports should be read from. If the remote application requests a scalar value this value is sent and no further checks are made. If an array of values is requested the array dimensionality and bounds are used to make sure that the macro does not send more data than the remote application expects. However the n1 ... n4 input ports can be used to override this dimensionality check. Normally these values will be all be set to -1. In this case the dimensions requested by the remote application are used. If the input array is smaller than the requested size it is collapsed to a 1D array and sent. However if the n1 .. n4 input ports are given values other than -1 then these values will be used as the dimensions of the array sent back to the remote application. In this case the product of these dimensions must equal the total size of the input array.

If this sounds obscure to you please do not worry. If you make sure that the AVS/Express application always provides the data that the remote application expects you will be able to leave the parameters n1 to n4 set to their default value of -1.

The visitwriter macro should be used in conjunction with the macros multiplexer, visitserver and visitreader.

Before this macro can be compiled and used the VISIT library must be installed. For information on how to install this library please see the VISIT library(http://www.fz-juelich.de/zam/visit) home page. A complete set of documentation for the VISIT-library can also be found at this URL.

The Visit IAC project assumes that the VISIT library has been installed into the default directory i.e.

/usr/local/visit/

If this is not the case then the references to that directory in the visit_mods.v file will have to be modified.

This functional macro is only provided for completeness. It is a very thin wrapper around the low-level VisitReader module. Therefore the VisitReader module should normally be used.

Inputs

SockID

Integer input port that contains a socket descriptor. This socket descriptor specifies the data-connection to the remote application. This input port should be connected to the SockID output port of the visitserver macro.

Trigger

When this input is triggered the visitwriter macro will attempt to send a message to the remote application. Normally this port should be connected to the Trigger output port of the visitserver macro. This should be done by either making a direct connection or making an indirect connection through a multiplexer macro.

Timestamp, n1, n2, n3, n4

Contain the header-information that will be send to the remote application. If the values of the n1 to n4 inputs are not set to -1 they will be used as the dimensions of the array that will be sent to the remote application. In this case the product of these dimensions must match the total size of the input data array.

DataString

If the requested datatype is STRING the value given by this input port will be sent to the remote application.

DataInt, DataShort, DataByte, DataDouble

If an array of data values has been requested one of these array inputs will be sent to the remote application. The input used depends upon the requested datatype. If only a single value is requested the value presented at the appropriate scalar input port will be used.

DataIntScalar, DataShortScalar, DataByteScalar, DataDoubleScalar

If a single data value has been requested on of these scalar inputs will be sent to the remote application. The input used depends upon the requested datatype. If an array of values is requested the values presented at the appropriate array input port will be used.

Utility Modules

The User Macro visitwriter is only a wrapper around the low-level module VisitWriter. All input and output ports of this module are directly connected to the macro ports.

Example

Two example applications are provided that work together with remote applications provided with the VISIT-library distribution. The VisitSimpleEg application is designed to test the installation of the Visit project and connects to the vclient remote application. If the project has been installed and compiled correctly several values should be sent to and received from the remote application. The test can be repeated several times by using the command line parameters of the vclient application. For instance the following command will repeat the test 20 times:

vclient -p -n 20

The VisitGoLEg example application is a more complete visualization example that connects to a remote game of life simulation. The application connects to the cgol remote application. This application computes the game of life simulation for a 3D field and sends the full state of simulation to the AVS/Express application after every life step. As well as displaying the results of the simulation the VisitGoLEg application also allows the simulation to be steered. It is possible to insert new blocks into the simulation, and to stop or pause the remote application.

A SEAP server must be running before either of these applications can be used. For full instructions on using the cgol and vclient applications please see the VISIT library home page.

Files

iac_proj/visit/visit_macs.v contains the V definition of the functional macro visitwriter.

Other Notes

The VisitMacs library inherits its process. As this library contains no procedural code, the process is not important. The modules in the low-level VisitMods library execute under the process specified in that library, not the process defined in the high-level library. By default the express process will be used.

Before the Visit project can be compiled the VISIT library must be installed, configured and compiled. For full instructions please see the VISIT library web-site.

The Visit IAC project assumes that the VISIT library has been installed into the default directory i.e.

/usr/local/visit/

If this is not the case then the references to that directory in the visit_mods.v file will have to be modified.

Author

Wolfgang Frings
Central Institute for Applied Mathematics
Research Center Juelich
D-52425 Juelich
Germany

Modifications

Ma YingLiang,
Manchester Visualization Centre

Andrew Dodd,
International AVS Centre

Contact

Wolfgang Frings
Central Institute for Applied Mathematics
Forschungszentrum Juelich GmbH
D-52425 Juelich
Germany
E-mail: W.Frings@fz-juelich.de
International AVS Centre
Manchester Visualization Centre
Manchester Computing
University of Manchester
Oxford Road
Manchester
United Kingdom
M13 9PL
E-mail: avs@iavsc.org

See Also