Fields

A field is some physical phenomenon known or expected to have value at every point in the set over which the field is defined. In other words, a field represents some continuous (as opposed to discrete) function which is defined over the infinite point set specified as the base space for the field.

In SAF, we divide the notion of a field into two pieces; a wholly abstract piece free of the details of how a field is is implemented, and an implementation specific piece. The abstract piece is called a field template. See saf_declare_field_tmpl for more information. Essentially, a field template defines a class of fields. The implementation specific piece of a field is called, simply, a field.

Presently, SAF requires the client to create a new scientific modeling primitive (e.g. a field object) for each instance of a field’s data. For example, if you have a pressure field that is evolving with time, each time the field’s data is written to the database, the client needs to declare a new field object. The client is not simply writing more data for the same field object. As more experience is gained with the data model and implementation, this behavior will be modified to be more natural. It is ok for a client to simply create a field with the same name, etc. This will not cause any problems in SAF. For example, if a client creates several pressure fields, all of which are instances of the same field at different points in time, that is ok. However, the client will probably want to organize those fields into a more aggregate field of fields (e.g. a field whose “values” are other fields on other base spaces). We call such a field an indirect field. In fact, the states and suites interface is provided as a conventient way to construct an indirect field representing various states of the problem output by the client. See *States* or saf_declare_state_group. However, there are a variety of situations in which a client may want to define an indirect field. The remaining portions of this chapter introduction discuss these situations in some detail. We’ll begin with some definitions.

Degrees Of Freedom**(**dofs): The degrees of freedom or dofs of a field is the name we give to the data associated with the field. Typically, the dofs are the problem sized arrays of floats or doubles representing some independent (or dependent) variables of a simulation. We call these datums degrees of freedom because, within the context of SAF, they are the degrees of freedom in the representation of the field. It is important to recognize this context of the representation of the field. That is what SAF is solely concerned with: representing fields so that other clients can read and interpret them. In this context, every datum represents a degree of freedom. This sense of degree of freedom should not be confused with, for example, similar terminology in the linear system of equations a client might be solving. That is an entirely different context in which similar terminology is used to describe those datums that effect the solution of the system of equations being solved. SAF is concerned with data that effects the representation of the field. Why don’t we call these values? Because the word “values” implies that the field is, in fact, equal to these numbers for some (maybe many) points in the base-space. And, this is only true when the field’s evaluation function is interpolating. That is, the interpolation functions pass through the dofs controlling the interpolation. This is most certainly not true for a field represented by, for example, a Fourier series.

Indirect Field: An indirect field is any field whose algebraic type is SAF__ALGTYPE_FIELD. Equivalently, this means that if you were to call saf_read_field for such a field, you would obtain a bunch of SAF__Field field handles. Likewise, when the algebraic type of a field is not SAF__ALGTYPE_FIELD, the field is not an indirect field and we, instead, call it a direct field. Note that indirection is, in general, recursive. An indirect field can refer to fields that are themselves indirect fields. An example of an indirect field is the pressure over a mesh as a function of time for 9 time instances. There would be 9 instances of pressure fields on the mesh, one for each time instant. Each of these fields is just one of the instances of the pressure on the mesh. To characterize the pressure field’s variation over time, we would define another field on the time base space having 9 dofs. Each dof would be a different one of the pressure fields over the mesh as illustrated in figure “indirect field-1.gif”.

Homogeneous Field: A homogeneous field is any field whose defining characteristics do not vary over the base space upon which the field is declared. We include in “defining characteristics” all those parameters used to declare a field and its field template such as algebraic type, number of components, quantity, units, component interleave, component order, evaluation function and even its storage.

Any field that is not homogeneous is inhomogeneous. An example of an inhomogeneous field is a stress tensor defined over a 3D rocket body and its 2D fins. Over the 3D body, the field is a 3D symmetric tensor and over the 2D fins it is a 2D symmetric tensor. This is illustrated in “indirect field-2.gif”.

Another example is a coordinate field of a mesh whose storage is decomposed into separate chunks, one for each processor in a parallel decomposition. This is illustrated in “indirect field-3.gif”.

SAF deals with inhomogeneous fields by breaking them up, recursively in general, into homogeneous pieces. Thus, the data for an inhomogeneous field is the handles to these field pieces. An inhomogeneous field is, therefore, also an indirect field. Furthermore, if a field is inhomogeneous, all bets are off about any of the field’s defining characteristics. All that can be said, for sure, about an inhomogeneous field is that there is some decomposing collection of the field’s base-space upon which it is presumably piecewise homogeneous. We say presumably here because any piece of an inhomogeneous field can itself be inhomogeneous so that, in general, its decomposition into homogeneous pieces is recursive.

With all of this information, we can construct a pseudo class-hierarchy for these various kinds of fields.

                                 Field
                                   |
                  ---------------------------------
                  |                               |
              INdirect                          Direct
                  |                               |
        -------------------                       |
        |                 |                       |
 INhomogeneous       Homogeneous              Homogeneous
                          |
                          |
                          |
                      State Field

Because an inhomogeneous field is also an indirect field, it is often convenient when talking about both inhomogeneous indirect fields and homogeneous indirect fields to simply refer to the two as inhomogeneous and indirect fields, respectively. There are some important conceptual differences between inhomogeneous and indirect fields worth mentioning here.

First, one requirement of the various fields comprising an inhomogeneous field is that the union of the base-spaces of all the homogeneous pieces must form a decomposition of the base-space of the inhomogeneous aggregate. SAF enforces this condition and will not permit a client to construct an inhomogeneous field for which this is not true.

Second, it does not make sense to conceive of interpolating between the pieces of an inhomogeneous field in the same way we might want to interpolate between the pieces of an indirect field. For example, it doesn’t make sense to try to interpolate between the stress tensor on the fins and the stress tensor on the rocket body of the inhomogeneous field in “indirect field-2.gif” while it does make sense to try to interpolate between the 4th and 5th instances of the pressure field in “indirect field-1.gif”.

Third, for all homogeneous fields, the number of dofs read from and written to a field is the product of the number of components in the field, the size of the collection the field’s dofs are associated with and the association ratio (see saf_declare_field). This is true for homogeneous, direct fields where the dofs might be floats or doubles as well as homogeneous, indirect fields where the dofs are handles to other fields. However, for inhomogenous fields, the number of field handles to be read and written is determined by the size of the decomposing collection upon which the field is presumably piecewise homogeneous. That collection is what determines the number of pieces the field is decomposed into.

FIELD TARGETING: SAF now offers some limited ability to transform a field during read. Currently, this capability is available only during read. Transformations during write will be made available later. Currently, on read, a client can invoke the following transformations:

1. changes in precision (single<–>double)
2. changes in interleave (vector<–>component)
3. changes in storage decomposition (self<–>other immediate). By immediate we mean a decomposition which is immediately below the self set in the subset relation graph.

The targeting function, saf_target_field, is used to tell SAF to invoke such transforms during read. The intent is that a reader will call saf_target_field before making a call to read the field. The target call will indicate the intended form of the field in the destination. Once targeting has been setup with a call to saf_target_field, a call to saf_read_field will do the right thing resulting in the altered field in the destination’s buffers. This is an experimental capability and interface. Field targeting will only work on serial SAF clients or single processor parallel SAF clients (i.e. SAF clients that have opened the database on just one processor).

Soon, SAF will offer some limited ability to transform a field during read or write. The intent is that a reader or writer will call saf_target_field before making a call to read or write the field. The target call will indicate the intended form of the field in the destination (the database during write or the client’s memory during read). Once targeting has been setup with a call to saf_target_field, a call to saf_read_field or saf_write_field will do the right thing resulting in the altered field in the destination’s buffers.

Members

• SAF_CONSTANT [Public macro]
• SAF_DECOMP [Public macro]
• SAF_NODAL [Public macro]
• SAF_NULL_FIELD [Public macro]
• SAF_WHOLE_FIELD [Public symbol]
• SAF_ZONAL [Public macro]
• _saf_find_parent_field [Public function]
• saf_data_has_been_written_to_comp_field [Public function]
• saf_data_has_been_written_to_field [Public function]
• saf_declare_coords [Public function]
• saf_declare_default_coords [Public function]
• saf_declare_field [Public function]
• saf_describe_field [Public function]
• saf_find_coords [Public function]
• saf_find_default_coords [Public function]
• saf_find_fields [Public function]
• saf_get_count_and_type_for_field [Public function]
• saf_get_field_att [Public function]
• saf_is_self_stored_field [Public function]
• saf_put_field_att [Public function]
• saf_read_field [Public function]
• saf_target_field [Public function]
• saf_write_field [Public function]