#include <FieldFormat.h>
Inheritance diagram for FieldFormat::
NAME: FieldFormat - flexible formats for a variable coefficient in PDEs
DESCRIPTION:
The class enables flexible handling of various formats of a variable coefficient in a PDE. The variable coefficient is represented as a scalar field, or more precisely, as a Diffpack "Field" class. Different formats are supported, corresponding to different Diffpack scalar field subclasses: A field given as an explicit function, usually a functor, a finite element field given from a datafile, a field as a piecewise constant function over subdomains (where ""subdomain"" refers to the material concept in class "GridFE" and the material values are read interactively), and a constant field. Using this class it is easy to write a short answer on a menu and the program can easily treat the field in question as a constant, a function or read it from file. The class contains information on the field format, and to some extent the field values (constants and piecewise constant fields have their values stored in data members of this class, other fields have their filenames or function names stored in the class). By checking the contents of the class, it is easy for an application program to perform the necessary actions to compute the field values.
|
|
|
|
|
There are no constructors. The initialization is performed in "scan" which usually reads string answers from a menu. In order to make use of the "define", "scan" and "allocateAndInit" functions, the programmer must assign a proper value to "name". This variable is used to generate and read menu items as well as when allocating a new field object (i.e. the new field objects gets the name "name"). |
|
|
|
|
|
See documentation of one of the overloaded functions. |
|
|
See documentation of one of the overloaded functions. |
|
|
See documentation of one of the overloaded functions. |
|
|
given a handle to a field, the functions check the field format, allocates the proper field object and initializes the field values. Two of the functions take a "GridFE*" pointer as a second, optional argument. This grid pointer is used (that is, the grid must exist and be properly initialized) for the "MATERIAL_CONSTANTS" format only. If the field format is "FUNCTOR", the programmer must explicitly allocate the field in the calling program. This is also the case for some of the other formats (error messages are issued if one calls an unimplemented feature). When the "allocateAndInit" functions load the field from a simres file, information about the time point is available as the data member "time" of the "FieldFormat" object. At present, only "FieldFE" or "FieldsFE" objects can be read from file. If another field type is actually stored on file, "SimResFile readFile" will issue an error message. Two other "allocateAndInit" functions have only "Handle(FieldFE)" and "Handle(FieldsFE)" arguments. These can only be used for the formats "FIELD_ON_FILE" and "CONSTANT". The final "allocateAndInit" functions take "Handle(FieldFE)" and "Handle(FieldsFE)" arguments. These functions also support only constant values and fields on file and require the fields to be in an "ok" state if the format is "CONSTANT" or "CONSTANT_VECTOR". The return value of "allocateAndInit" is true if the allocation and initialization were successful, otherwise (e.g. in case of a format that is not supported by the function), a false value is returned.
// given FieldFormat u_format, Handle(GridFE) grid and Handle(FieldFE) u if (!u_format.allocateAndInit (u)) { // make grid, e.g., by calling readOrMakeGrid u.rebind (new FieldFE(grid(),"u")); } else // u_format allocated the field and the associated grid grid.rebind (u->grid()); // proceed with initialization of ALL other fields that depend on grid Here is another useful variant:
void MySimulator :: init ()
{
// u0_format is a FieldFormat with the user-format for an initial // condition, u_prev is the corresponding handle (Handle(FieldFE))
if (!u0_format.initAndAllocate (u_prev))
{
if (u0_format.format == FieldFormat ::FUNCTOR)
{
u_prev.rebind (new FieldFE (grid(), "u_prev"));
if (u0_format.function_name == "plane")
func.rebind( new PlaneFromLeftU(*this));
else if (u0_format.function_name == "spherical")
func.rebind( new SphericalU (*this));
// etc
}
// else: error, the format cannot be used
}
else
// initAndAllocate either read a field from file or initialized
// the u_prev field by a constant, according to the user's menu
// choice (read by u0_format.scan)
u_prev.setFieldname ("u_prev");
In simulator classes one will usually use "allocateAndInit(Handle(Field))&,GridFE*" for reading and initializing coefficients in the equations, whereas "allocateAndInit(Handle(FieldFE))&" is better suited for reading a primary unknown from file and continue a previously aborted simulation. In order to see how the "FieldFormat" class can be used in a code, we encourage the reader to study the functions "define", "scan" and "allocateAndInit". Especially the latter may be of importance. If you find the "allocateAndInit" function(s) inappropriate, it is easy to copy the body of these member functions, make the necessary modifications and insert the statements in the calling program. We should remark that the "MATERIAL_CONSTANTS" format is not suitble for "FieldPiWisConst" fields where the elements are the subdomains (then there are too many parameters to assign, at least when the syntax of "FieldFormat:.scan" is used). |
|
|
Reimplemented in RandFieldFormat. |
|
|
adds an item about a field format on a menu. This function requires the fieldname. The "define" function applies the internal fieldname ("name"). Note that the internal fieldname "name" must be initialized in order to use "define", "scan(MenuSystem)" and "allocateAndInit". The advantage of using this function is that the menu command details are hidden in the application program. Reimplemented in RandFieldFormat. |
|
|
See documentation of one of the overloaded functions. Reimplemented in RandFieldFormat. |
|
|
The version that takes a "MenuSystem" object as argument initializes the "FieldFormat" object on basis of a string supplied by the menu. This "scan" function simply extracts a string from the menu and calls "scan(String)". The advantage of using this function is that the menu command details are hidden in the application program. The overloaded version taking a "String" reads a string in a special format (see below) and fills the internal data structures. To print the contents of a "FieldFormat" object one can either simply print the "specification" string (which has the same syntax as the input string to "scan") or one can use the internal data structures and format the output string as desired. Reimplemented in RandFieldFormat. |
|
|
|
|
|
writes a more detailed text containing the characteristics of the field. If the field is constant, the constant value is reported, if the field is stored in simres format on a file, the filename and the fieldname is written. The user can supply an optional argument "field" that points to the field in question. This argument is used for extracting min and max values for characterizing the field. Of course, this will only affect the "FIELD_ON_FILE" format. For the "MATERIAL_CONSTANTS" format, the output consists of one line of text for every material. More details about the output format can be gained by reading the body of the function. Reimplemented in RandFieldFormat. |
|
|
writes headings for a summary report (see class "MultipleReporter"). Reimplemented in RandFieldFormat. |
|
|
writes results for a summary report (see class "MultipleReporter"). The amount of output is similar to "writeExtendedResults", except for the "FIELD_ON_FILE" field format which is reported more compactly by "writeResults". For the "MATERIAL_CONSTANTS" format, both "writeHeadings" and "writeResults" generates an item for each material. For example, if the fieldname is "a" and there are two materials, there will be two summary items: "a_1" and "a_2". Reimplemented in RandFieldFormat. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|