The field format

The field files are the main channel between an application and AVS/Express³. As every feature of this software, this data structure can become complex but, once again, we will restrict us to demonstrate how it can be used to store data from our application, i.e. from a uniform 3D domain.

A field file is split in two entities:

• the header,

• the data.

2NB: the byte representation of real and integer are inversed in Linux compared to Unix.

Therefore, if the simulation is ran on a Linux platform and AVS/Express on a Unix one, the data file must be treated.

3For further information about the field format, read the chapterFielddata type in the user guideData visualization kit

Figure C.1: A snapshot of a simple application in theAVS/Expressenvironment.

The network editor in the righ hand side, containing libraries of modules and the graph of modules linked together; the left hand side contains informations about the enlighted module; the black graphic window corresponds to the UViewer module of the network (the point of view can be modified using the tools - zoom, translation, rotation - displayed on the extreme left of the figure).

C.2.1 A practical example

To illustrate this format, we can take a practical case. Let’s consider a 3D domain nx×ny×nz (wherenx = 100,ny = 30 andnz = 50). Throughout this domain, a variable containing the 3 components of the fluid velocity is defined. In Fortran 90, it could be defined as:

real,dimension(3,50,30,100)::vel

where the dimension are inversed in prevision of the parallel distribution of the workload, where the domain is split among thex−dimension (which is often the largest) as explained in section 4.3.2.

The field data file (*.fld.dat)

The data file contains the values of the stored field, its storing order is not unique and has to be explicited in the header file. However, when reading an array, the first index varies most quickly (fortran style).

In the current example, the variablevelis saved in an unformatted file (writ-ing on disk directly the byte representation of the data, to save space) in the following manner:

open(10, file=’ex-1.fld.dat’,form=’unformatted’) do l=1,3

write(10)(((vel(l,k,j,i),i=1,100),j=1,30),k=1,50) enddo

It could have been saved in some other ways, but this one will store the values of vel in the following order:

@@@@ vel(1,1,1,1) vel(1,1,1,2) vel(1,1,1,3)

... vel(1,1,1,100) vel(1,1,2,1) ... vel(1,50,30,100)@@@@

@@@@ vel(2,1,1,1) vel(2,1,1,2) vel(2,1,1,3)

... vel(2,1,1,100) vel(2,1,2,1) ... vel(2,50,30,100)@@@@

@@@@ vel(3,1,1,1) vel(3,1,1,2) vel(3,1,1,3)

... vel(3,1,1,100) vel(3,1,2,1) ... vel(3,50,30,100)@@@@

where there is neither space or return characters in this file, as the values are stored unformatted by their byte representation (4 bytes as vel is declared as real).

The loop inside the abovewritestatement is performed to inverse the indice order (we could have savedveldirectly throughwrite(10) vel(l,:,:,:) ifvel had been defined in the classic way as real,dimension(3,100,30,50)::vel).

Moreover, the chains @@@@ are four bytes blocks which appear before and after any written data in the Fortran unformatted mode (there is no such features in C). We will have to take into account this strings when reading the data from AVS/Express.

The field header file (*.fld)

The header contains information about the field, i.e. the number of dimensions, the kind of data and its location . . . It is a short ASCII file, such as, for the current example, shown in table C.1

Multi-steps fields

As getting only a snapshot of a simulation is often not enough to catch the behavior of a system, the experimentalist often needs to see its evolution. A solution is therefore to save regularly the system state in a field. Instead of tediously opening by hand a list of field files, AVS/Exprees offers the possibility of building multi-steps fields.

Let’s modify the previous example, saving the system every 1000 steps in 500 files labeledex-1.001.fld.dat,ex-1.002.fld.dat. . . ex-1.500.fld.dat. We therefore need to write a more complete header file in the following manner:

# AVS field

# wind velocity every 1000 steps ndim = 3

.THEFIELDFORMAT131

# AVS field

# wind velocity Comments lines must start with#

# max: 0.1943228 min: -0.1513349

ndim= 3 Number of computational dimensions

dim1= 100 n_x

dim2= 30 n_y

dim3= 50 n_z

nspace= 3 Number of physical dimensions

veclen= 3 Number of data stored at each nodes (3 velocities components)

data=float Type of the data

field=uniform uniform, as the domain uniformly maps the domain

variable 1 file=ex-1.fld.dat filetype=binary skip=4 stride=1 The first variable (the array containing the first component over 3, asveclenis stated), is stored in fileex-1.fld.dat; the4first bytes of the file should be skiped (@@@@ fortran tag); the data are adjacent,i.e. all the data should be read continuously (if the first component was stored on every 3 reals - write(10)vel -, we would havestride=3)

variable 2 file=ex-1.fld.dat filetype=binary skip= 600012 stride=1

600012 bytes must be skipped before reading the second com-ponents (100×30×50×4(=size(real))+3×4(=three preceding

@@@@tags)) variable 3 file=ex-1.fld.dat filetype=binary skip=1200020

stride=1

Table C.1: field header file for the mono-step example described in paragraph C.2.1

dim1 = 100

variable 1 file=ex-1.001.fld.dat filetype=binary skip=4 stride=1

variable 2 file=ex-1.001.fld.dat filetype=binary skip= 72012 stride=1 variable 3 file=ex-1.001.fld.dat filetype=binary skip= 144020 stride=1 EOT

time value = step_2000

variable 1 file=ex-1.002.fld.dat filetype=binary skip=4 stride=1

variable 2 file=ex-1.002.fld.dat filetype=binary skip= 72012 stride=1 variable 3 file=ex-1.002.fld.dat filetype=binary skip= 144020 stride=1 EOT

variable 1 file=ex-1.500.fld.dat filetype=binary skip=4 stride=1

variable 2 file=ex-1.500.fld.dat filetype=binary skip= 72012 stride=1 variable 3 file=ex-1.500.fld.dat filetype=binary skip= 144020 stride=1 EOT

TheAVS/Express read fieldmenu is therefore slightly modified when opening such a file, as options concerning the time steps are proposed (running once the whole simulation, displaying directly the step x . . . ). Note that, for conveniency, all the data files can be appended in one big file (the skip options should consequently be adapted).