This functional macro writes data to a visit connection.
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. | |
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.
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.
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.
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.
iac_proj/visit/visit_macs.v contains the V definition of the functional macro visitwriter.
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.
Wolfgang Frings Central Institute for Applied Mathematics Research Center Juelich D-52425 Juelich Germany
Ma YingLiang, Manchester Visualization Centre Andrew Dodd, International AVS Centre
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