Configuration Files

These files generate the conditions and material properties, as well as the general problem and intervals data to be transferred to the mesh, at the same time giving you the chance to define geometrical drawings or symbols to represent some conditions on the screen.

XML file

The file problem_type.xml contains information related to the configuration of the problem type, such as file browser, icon, password validation or message catalog location. Besides this, the file can be used to store assorted structured infomation such as version number, news added from the last version, and whatever the developer decides to include. This file can be read using the Tcl extension tcom which is provided with GiD .

The data included inside the xml file should observe the following structure:

<Infoproblemtype version="1.0">

<Program>

</Program>

</Infoproblemtype>

We suggest that the following nodes are included (the values of these nodes are just examples):

ValidatePassword node

The default action taken by GiD when validating a problem type password is verifying that it is not empty. When a password is considered as valid, this information is written in the file 'password.txt' which is located in the problem type directory. In order to override this behaviour, two nodes are provided in the .xml file

Example:

<PasswordPath>..</PasswordPath>

key with the contents of the password typed,

dir with the path of the problem type, and

computer_name with the name of host machine.

Note: It's like this Tcl procedure prototype: proc PasswordPath { key dir computer_name } { ... body... }

The script should return one of three possible codes:

0 in case of failure.

1 in case of success.

2 in case of success; the difference here is that the problem type has just saved the password information so GiD should not do it.

Furthermore, we can provide a description of the status returned for GiD to show to the user. If another status is returned, it is assumed to be 1 by default.

Below is an example of a <ValidatePassword> node.

<ValidatePassword>

#validation.exe simulates an external program to validade the key for this computername

#instead an external program can be used a tcl procedure

if { [catch {set res [exec [file join $dir validation.exe] $key $computername]} msgerr] } {

return [list 0 "Error $msgerr"]

}

switch -regexp -- $res {

failRB {

return [list 0 "you ask me to fail!"]

}

okandsaveRB {

proc save_pass {dir id pass} {

set date [clock format [clock second] -format "%Y %m %d"]

set fd [open [file join $dir .. "password.txt"] "a"]

puts $fd "$id $pass # $date Password for Problem type '$dir'"

close $fd

}

save_pass $dir $computername $key

rename save_pass ""

return [list 2 "password $key saved by me"]

}

okRB {

return [list 1 "password $key will be saved by gid"]

}

default {

return [list 0 "Error: unexpected return value $res"]

}

}

</ValidatePassword>

Conditions file (.cnd)

Files with extension .cnd contain all the information about the conditions that can be applied to different entities. The condition can adopt different field values for every entity. This type of information includes, for instance, all the displacement constraints and applied loads in a structural problem or all the prescribed and initial temperatures in a thermial analysis.

An important characteristic of the conditions is that they must define what kind of entity they are going to be applied over, i.e. over points, lines, surfaces, volumes or layers, and what kind of entity they will be transferred over, i.e. over nodes, over face elements or over body elements.

Note: For backwards compatibility, the command over elements is also accepted; this will transfer the condition either to elements or to faces of higher level elements.

Another important feature is that all the conditions can be applied to different entities with different values for all the defined intervals of the problem.

Therefore, a condition can be considered as a group of fields containing the name of the particular condition, the geometric entity over which it is applied, the mesh entity over which it will be transferred, its corresponding properties and their values.

The format of the file is as follows:

CONDITION: condition_name

CONDTYPE: 'over' ('points', 'lines', 'surfaces', 'volumes', 'layer')

CONDMESHTYPE: 'over' ('nodes', 'face elements','face elements multiple', 'body elements')

QUESTION: field_name['#CB#'(...,optional_value_i,...)]

VALUE: default_field_value

...

QUESTION: field_name['#CB#'(...,optional_value_i,...)]

VALUE: default_field_value

END CONDITION

CONDITION: condition_name

...

END CONDITION

Note: #CB# means Combo Box.

Note that this file format does not allow you to put blank lines between the last line of a condition definition, END CONDITION, and the first one of the next condition definition.

Local Axes

QUESTION: field_name['#LA#'('global', 'automatic', 'automatic alternative')]

VALUE: default_field_value

This type of field refers to the local axes system to be used. The position of the values indicates the kind of local axes .

If it only has a single default value, this will be the name of the global axes. If two values are given, the second one will reference a system that will be computed automatically for every node and will depend on geometric constraints, like whether or not it is tangent, orthogonal, etc. If a third value is given, it will be the name of the automatic alternative axes, which are the automatic axes rotated 90 degrees.

All the different user-defined systems will automatically be added to these default possibilities.

To enter only a specific kind of local axes it is possible to use the modifiers #G#,#A#,#L#.

When using these modifiers the position of the values does not indicate the kind of local axes.

Example

QUESTION: Local_Axes#LA#(Option automatic#A#,Option automatic_alt#L#)

VALUE: -Automatic-

Note: All the fields must be filled with words, where a word is considered as a string of characters without any blank spaces. The strings signaled between quotes are literal and the ones inside brackets are optional. The interface is case-sensitive, so any uppercase letters must be maintained. The default_field_value entry and various optional_value_i entries can be alphanumeric, integers or reals. GiD treats them as alphanumeric until the moment they are written to the solver input files.

Global axes:

X=1 0 0

Y=0 1 0

Z=0 0 1

Automatic axes :

For surfaces, this axes are calculated from the unitary normal N:

z'=N

if N is coincident with the global Y direction (Nx or Nz > some tolerance) then

x'=Y x N / |Y x N|

else

x'=Z x N / |Z x N|

y'=N x x'

z'=N

For lines, this axes are calculated from the unitary tangent T:

x'=T

if T is coincident with the global Z direction (Nx or Ny > some tolerance) then

y'=Y x x' / |Y x x'|

else

y'=Z x x' / |Z x x'|

z'=x' x y'

Automatic alternative axes:

They are calculated like the automatic case and then swap x and y axes:

x''= y'

y''= - x'

z''= z'

For curves

x'=unitary tangent to the curve on the place where the condition is applied

If this tangent is different of the Z global axe=(0,0,1) then

y'=Y x x'

else

y'=Z x x'

z'=x' x y'

Note: the tangent x' is considered different of (0,0,1) is the first or second component is greater than 1/64

One flag that can optionally be added to a condition is:

CANREPEAT: yes

It is written after CONDMESHTYPE and means that one condition can be assigned to the same entity several times.

Self Calculated #FUNC# fields:

Another type of field that can be included inside a condition is a #FUNC# to do some calculation,

where the key #FUNC#, means that the value of this field will be calculated just when the mesh is generated. It can be considered as a function that evaluates when meshing.

Valid variables for a #FUNC# field are:

e.g.

QUESTION: Surface_number#FUNC#(NumEntity)

VALUE: 0

In the above example, NumEntity is one of the possible variables of the function. It will be substituted by the label of the geometrical entity from where the node or element is generated.

QUESTION: X_press#FUNC#(Cond(3,REAL)*(x-Cond(1,REAL))/(Cond(2,REAL)-Cond(1,REAL)))

VALUE: 0

In this second example, the x variable is used, which means the x-coordinate of the node or of the center of the element. Others fields of the condition can also be used in the function. Variables y and z give the y- and z-coordinates of this point.

Note: There are other options available to expand the capabilities of the Conditions window (see Special fields ).

Example: Creating the conditions file

Here is an example of how to create a conditions file, explained step by step:

  1. First, you have to create the folder or directory where all the problem type files are located, problem_type_name.gid in this case.
  1. Then create and edit the file (problem_type_name.cnd in this example) inside the recently created directory (where all your problem type files are located). As you can see, except for the extension, the names of the file and the directory are the same.
  1. Create the first condition, which starts with the line:

CONDITION: Point-Constraints

The parameter is the name of the condition. A unique condition name is required for this conditions file.

  1. This first line is followed by the next pair:

CONDTYPE: over points

CONDMESHTYPE: over nodes

which declare what entity the condition is going to be applied over. The first line, CONDTYPE:... refers to the geometry, and may take as parameters the sentences "over points", "over lines", "over surfaces" or "over volumes".

The second line refers to the type of condition applied to the mesh, once generated. GiD does not force you to provide this second parameter, but if it is present, the treatment and evaluation of the problem will be more acurate. The available parameters for this statement are "over nodes" and "over elements".

  1. Next, you have to declare a set of questions and values applied to this condition.

QUESTION: Local-Axes#LA#(-GLOBAL-)

VALUE: -GLOBAL-

QUESTION: X-Force

VALUE: 0.0

QUESTION: X-Constraint:#CB#(1,0)

VALUE: 1

QUESTION: X_axis:#CB#(DEFORMATION_XX,DEFORMATION_XY,DEFORMATION_XZ)

VALUE: DEFORMATION_XX

END CONDITION

After the QUESTION: prompt, you have the choice of putting the following kinds of word:

The VALUE: prompt must be followed by one of the optional values, if you have declared them in the previous QUESTION: line. If you do not observe this format, the program may not work correctly.

In the previous example, the X-Force QUESTION takes the value 0.0. Also in the example, the X-Constraint QUESTION includes a Combo Box statement (#CB#), followed by the declaration of the choices 1 and 0. In the next line, the value takes the parameter 1. The X_axis QUESTION declares three items for the combo box: DEFORMATION_XX,DEFORMATION_XY,DEFORMATION_XZ, with the value DEFORMATION_XX chosen.

Beware of leaving blank spaces between parameters. If in the first question you put the optional values (-GLOBAL, -AUTO-) (note the blank space after the comma) there will be an error when reading the file. Take special care in the Combo Box question parameters, so as to avoid unpredictable parameters.

  1. The conditions defined in the .cnd file can be managed in the Conditions window (found in the Data menu) in the Preprocessing component of GiD.

Conditions window in Preprocessing, showing an unfolded Combo Box

Materials file (.mat)

Files with the extension .mat include the definition of different materials through their properties. These are base materials as they can be used as templates during the Preprocessing step for the creation of newer ones.

You can define as many materials as you wish, with a variable number of fields. None of the unused materials will be taken into consideration when writing the data input files for the solver. Alternatively, they can be useful for generating a materials library.

Conversely to the case of conditions, the same material can be assigned to different levels of geometrical entity (lines, surfaces or volumes) and can even be assigned directly to the mesh elements.

In a similar way to how a condition is defined, a material can be considered as a group of fields containing its name, its corresponding properties and their values.

The format of the file is as follows:

MATERIAL: material_name

QUESTION: field_name['#CB#'(...,optional_value_i,...)]

VALUE: default_field_value

...

QUESTION: field_name['#CB#'(...,optional_value_i,...)]

VALUE: default_field_value

END MATERIAL

MATERIAL: material_name

...

END MATERIAL

If a material has a variable property (an example would be where a property was dependent on temperature and was defined with several values for several temperatures) a table of changing values may be declared for this property. When the solver evaluates the problem, it reads the values and applies a suitable property value.

The declaration of the table requires two lines of text:

The first is a QUESTION line with a list of alphanumeric values between parentheses.

QUESTION: field_name:(...,optional_value_i,...)

These values are the names of each of the columns in the table so that the number of values declared is the number of columns.

This first line is followed by another with the actual data values. It starts with the words VALUE: #N#, and is followed by a number that indicates the quantity of elements in the matrix and, finally, the list of values.

VALUE: #N# number_of_values ... value_number_i ...

The number of values declared for the matrix obviously has to be the number of columns multiplied by the number of rows to be declared.

This kind of material specification is most likely to be used in thermo-mechanical simulations, where the problem is exposed to a temperature variation, and the properties of the materials change for each temperature value.

All the fields must be filled with words, where a word is considered as a string of characters without any blank spaces. The strings signaled between quotes are literal and the ones within brackets are optional. The interface is case-sensitive, so any uppercase letters must be maintained. The default_field_value entry and various optional_value_i entries can be alphanumeric, integers or real numbers, depending on their type.

The numbers of the materials have to be consecutive, beginning with number 1. There is no need to indicate the overall number of materials or the respective number of fields for each one. This last one can vary for each material.

Note that in this file, you cannot include blank lines between different material definitions, nor between questions and values.

Note: There are other options available to expand the capabilities of the Materials window (see Special fields ).

Example: Creating the materials file

Here is an example of how to create a materials file, explained step by step:

  1. Create and edit the file (problem_type_name.mat in this example) inside the problem_type_name directory (where all your problem type files are located). As you can see, except for the extension, the names of the file and the directory are the same.
  1. Create the first material, which starts with the line:

MATERIAL: Air

The parameter is the name of the material. A unique material name is required for this into this materials file (do not use blank spaces in the name of the material).

  1. The next two lines define a property of the material and its default value:

QUESTION: Density

VALUE: 1.0

You can add as many properties as you wish. To end the material definition, add the following line:

END MATERIAL

  1. In this example we have introduced some materials; the .mat file would be as follows:

MATERIAL: Air

QUESTION: Density

VALUE: 1.01

END MATERIAL

MATERIAL: AISI_4340_Steel

QUESTION: YOUNG_(Ex)

VALUE: 21E+9

QUESTION: SHEAR_MODUL

VALUE: 8.07E+9

QUESTION: POISSON_(NUXY)

VALUE: 0.3

QUESTION: ALPX

VALUE: 0.0000066

QUESTION: DENSIDAD_(DENS)

VALUE: 0.785

END MATERIAL

MATERIAL: Concrete

QUESTION: Density

VALUE: 2350

END MATERIAL

  1. The materials defined in the .mat file can be managed in the Materials window (found in the Data menu) in the Preprocessing component of GiD.

Materials window in GiD Preprocessing

Problem and intervals data file (.prb)

Files with the extension .prb contain all the information about general problem and intervals data. The general problem data is all the information required for performing the analysis and it does not concern any particular geometrical entity. This differs from the previous definitions of conditions and materials properties, which are assigned to different entities. An example of general problem data is the type of solution algorithm used by the solver, the value of the various time steps, convergence conditions and so on.

Within this data, one may consider the definition of specific problem data (for the whole process) and intervals data (variable values along the different solution intervals). An interval would be the subdivision of a general problem that contains its own particular data. Typically, one can define a different load case for every interval or, in dynamic problems, not only variable loads, but also variation in time steps, convergence conditions and so on.

The format of the file is as follows:

PROBLEM DATA

QUESTION: field_name['#CB#'(...,optional_value_i,...)]

VALUE: default_field_value

...

QUESTION: field_name['#CB#'(...,optional_value_i,...)]

VALUE: default_field_value

END PROBLEM DATA

INTERVAL DATA

QUESTION: field_name['#CB#'(...,optional_value_i,...)]

VALUE: default_field_value

...

QUESTION: field_name['#CB#'(...,optional_value_i,...)]

VALUE: default_field_value

END INTERVAL DATA

All the fields must be filled with words, where a word is considered as a string of characters without any blank spaces. The strings signaled between quotes are literal and the ones inside brackets are optional. The interface is case-sensitive, so any uppercase letters must be maintained. The default_field_value entry and various optional_value_i entries can be alphanumeric, integers or real numbers, depending on the type.

Note: There are other options available to expand the capabilities of the Problem Data window (see Special fields ).

Example: Creating the PRB data file

Here is an example of how to create a problem data file, explained step by step:

  1. Create and edit the file (problem_type_name.prb in this example) inside the problem_type_name directory (where all your problem type files are located). Except for the extension, the names of the file and the directory must be the same.

  1. Start the file with the line:

PROBLEM DATA

  1. Then add the following lines:

QUESTION: Unit_System#CB#(SI,CGS,User)

VALUE: SI

QUESTION: Title

VALUE: Default_title

The first question defines a combo style menu called Unit_System, which has the SI option selected by default. The second question defines a text field called Title, and its default value is Default_title.

  1. To end the file, add the following line:

END PROBLEM DATA

  1. The whole file is as follows:

PROBLEM DATA

QUESTION: Unit_System#CB#(SI,CGS,User)

VALUE: SI

QUESTION: Title

VALUE: Default_title

END PROBLEM DATA

  1. The options defined in the .prb file can be managed in the Problem Data window (found in the Data menu) in the Preprocessing component of GiD.

Problem Data window in GiD Preprocessing

Conditions symbols file (.sim)

Files with the extension .sim comprise different symbols to represent some conditions during the preprocessing stage. You can define these symbols by creating ad hoc geometrical drawings and the appropriate symbol will appear over the entity with the applied condition every time you ask for it.

One or more symbols can be defined for every condition and the selection will depend on the specified values in the file, which may be obtained through mathematical conditions.

The spatial orientation can also be defined in this file, depending on the values taken by the required data. For global definitions, you have to input the three components of a vector to express its spatial direction. GiD takes these values from the corresponding conditions window. The orientation of the vector can be understood as the rotation from the vector (1,0,0) towards the new vector defined in the file.

For line and surface conditions, the symbols may be considered as local. In this case, GiD does not consider the defined spatial orientation vector and it takes its values from the line or surface orientation. The orientation assumes the vector (1,0,0) to be the corresponding entity's normal.

These components, making reference to the values obtained from the adequate conditions, may include C-language expressions. They express the different field values of the mentioned condition as cond(type,i), where type (real or int) refers to the type of variable (not case-sensitive) and i is the number of the field for that particular condition.

Example: Creating the Symbols file

Here is an example of how to create a symbols file. Create and edit the file (problem_type_name.sim in this example) inside the problem_type_name directory (where all your problem type files are located). Except for the extension, the names of the file and the directory must be the same.

The contents of the problem_type_name.sim example should be the following:

cond Point-Constraints

3

global

cond(int,5)

1

0

0

Support3D.geo

global

cond(int,1) && cond(int,3)

1

0

0

Support.geo

global

cond(int,1) || cond(int,3)

cond(int,3)

cond(int,1)*(-1)

0

Support-2D.geo

cond Face-Load

1

local

fabs(cond(real,2))+fabs(cond(real,4))+fabs(cond(real,6))>0.

cond(real,2)

cond(real,4)

cond(real,6)

Normal.geo

This is a particular example of the .sim file where four different symbols have been defined. Each one is read from a ***.geo file. There is no indication of how many symbols are implemented overall. GiD simply reads the whole file from beginning to end.

The ***.geo files are obtained through GiD. You can design a particular drawing to symbolize a condition and this drawing will be stored as problem_name.geo when saving this project as problem_name.gid. You do not need to be concerned about the size of the symbol, but should bear in mind that the origin corresponds to the point (0,0,0) and the reference vector is (1,0,0). Subsequently, when these ***.geo files are invoked from problem_type_name.sim, the symbol drawing appears scaled on the display at the entity's location.

Nevertheless, the number of symbols and, consequently, the number of ***.geo files can vary from one condition to another. In the previous example, for instance, the condition called Point-Constraints, which is defined by using cond, comprises three different symbols. GiD knows this from the number 3 written below the condition's name. Next, GiD looks to see if the orientation is relative to the spatial axes (global) or moves together with its entity (local). In the example, the three symbols concerning point constraints are globally oriented.

Imagine that this condition has six fields. The first, third and fifth field values express if any constraint exist along the X-axis, the Y-axis and the Z-axis, respectively. These values are integers and in the case that they are null, the degree of freedom in question is assumed to be unconstrained.

For the first symbol, obtained from the file Support3D.geo, GiD reads cond(int,5), or the Z-constraint. If it is false, which means that the value of the field is zero, the C-condition will not be satisfied and GiD will not draw it. Otherwise, the C-condition will be satisfied and the symbol will be invoked. When this occurs, GiD skips the rest of the symbols related to this condition. Its orientation will be the same as the original drawing because the spatial vector is (1,0,0).

All these considerations are valid for the second symbol, obtained from the file Support.geo, but now GiD has to check that both constraints (&&) - the X-constraint and the Y-constraint - are fixed (their values are not zero).

For the third symbol, obtained from the file Support-2D.geo, only one of them has to be fixed (||) and the orientation of the symbol will depend on which one is free and which one is fixed, showing on the screen the corresponding direction for both degrees of freedom.

Finally, for the fourth symbol, onbtained from the file Normal.geo, it can be observed that the drawing of the symbol, related to the local orientation will appear scaled according to the real-type values of the second, fourth and sixth field values. Different types of C-language expressions are available in GiD. Thus, the last expression would be equivalent to entering '(fabs(cond(real,2))>0. || fabs(cond(real,4))!=0. || fabs(cond(real,6))>1e-10)'.

Note: As previously mentioned, GiD internally creates a project_name.geo file when saving a project, where it keeps all the information about the geometry in binary format. In fact, this is the reason why the extension of these files is .geo. However, the file project_name.geo is stored in the project_name.gid directory, whereas these user-created ***.geo files are stored in the problem_type_name.gid directory.

Unit System file (.uni)

When GiD is installed, the file units.gid is copied within the GiD directory. In this file a table of magnitudes is defined. For each magnitude there is a set of units and a conversion factor between the unit and the reference unit. The units systems are also defined. A unit system is a set of mangnitudes and the corresponding unit.

BEGIN TABLE

LENGTH : m, 100 cm, 1e+3 mm

...

STRENGTH : kg*m/s^2, N, 1.0e-1 kp

END

BEGIN SYSTEM(INTERNATIONAL)

LENGTH : m

MASS : kg

STRENGTH : N

...

TEMPERATURE : Cel

END

The syntax of the unit file (problem_type_name.uni) within the problem type is similar. It can include the line:

USER DEFINED: ENABLED

(or DISABLED)

meaning that the user is able (or not able) to define his own system unit within the project. If the line does not appear in the file the value is assumed to be ENABLED.

It is possible to ignore all units systems defined by default inside the file units.gid:

USE BASE SYSTEMS: DISABLED

(or ENABLED)

With the command HIDDEN: 'magnitude', 'magnitude' certain magnitudes will not be displyed in the Problem units window.

HIDDEN: strength, pressure

If the problem type uses a property which has a unit, then GiD creates the file project_name.uni in the project directory. This file includes the information related to the unit used in the geometric model and the unit system used. The structure of this file is:

MODEL: km

PROBLEM: USER DEFINED

BEGIN SYSTEM

LENGTH: m

PRESSURE: Pa

MASS: kg

STRENGTH: N

END

In this file, MODEL refers to the unit of the geometric model and PROBLEM is the name of the units system used by GiD to convert all the data properties in the output to the solver. If this name is USER DEFINED , then the system is the one defined within the file. The block

BEGIN SYSTEM

...

END

corresponds to the user-defined system.

Data unit window

Special fields

These fields are useful for organizing the information within data files. They make the information shown in the data windows more readable. In this way you can better concentrate on the data properties relevant to the current context.

  • Book: With the Book field it is possible to split the data windows into other windows. For example, we can have two windows for the materials, one for the steels and another for the concretes:

BOOK: Steels

...

All steels come here

...

BOOK: Concretes

...

All concretes come here

...

Options corresponding to books

The same applies to conditions. For general and interval data the book field groups a set of properties.

  • Title: The Title field groups a set of properties on different tabs of one book. All properties appearing after this field will be included on this tab.

TITLE: Basic

...

Basics properties

....

TITLE: Advanced

...

Advanced properties

....

Grouping by titles

  • Help: With the Help field it is possible to assign a description to the data property preceding it. In this way you can inspect the meaning of the property through the help context function by holding the cursor over the property or by right-clicking on it.

QUESTION: X-Constraint#CB#(1,0)

VALUE: 1

HELP: If this flag is set, movement is ...

Help property

  • Image: The Image field is useful for inserting descriptive pictures in the data window. The value of this field is the file name of the picture relating to the problem type location.

IMAGE: young.gif

Data window with an image

  • Unit field: With this feature it is possible to define and work with properties that have units. GiD is responsible for the conversion between units of the same magnitude

....

QUESTION: Normal_Pressure#UNITS#

VALUE: 0.0Pa

...

Data property with units

  • Dependencies: Depending on the value, we can define some behavior associated with the property. For each value we can have a list of actions. The syntax is as follows:

DEPENDENCIES:(<V1>,[TITLESTATE,<Title>,<State>],<A1>,<P1>,<NV1>,...,<An>,<Pn>,<NVn>)...(<Vm>,<Am>,<Pm>,<NVm>,...)

where:

  1. <Vi> is the value that triggers the actions. A special value is #DEFAULT# , which refers to all the values not listed.
  1. [TITLESTATE,<Title>,<State>] this argument is optional. Titlestate should be used to show or hide book labels. Many Titlestate entries can be given. <Title> is the title defined for a book (TITLE: Title). State is the visualization mode: normal or hidden.
  1. <Ai> is the action and can have one of these values: SET, HIDE, RESTORE . All these actions change the value of the property with the following differences: SET disables the property, HIDE hides the property and RESTORE brings the property to the enabled state.
  1. <Pi> is the name of the property to be modified.
  1. <NVi> is the new value of <Pi> . A special value is #CURRENT# , which refers to the current value of <Pi> .

Here is an example:

...

TITLE: General

QUESTION: Type_of_Analysis:#CB#(FILLING,SOLIDIFICATION)

VALUE: SOLIDIFICATION

DEPENDENCIES: (FILLING,TITLESTATE,Filling-Strategy,normal,RESTORE,

Filling_Analysis,GRAVITY,HIDE,Solidification_Analysis,#CURRENT#)

DEPENDENCIES: (SOLIDIFICATION,TITLESTATE,Filling-Strategy,hidden,HIDE,

Filling_Analysis,#CURRENT#,RESTORE,Solidification_Analysis,#CURRENT#)

TITLE: Filling-Strategy

QUESTION: Filling_Analysis:#CB#(GRAVITY,LOW-PRESSURE,FLOW-RATE)

VALUE: GRAVITY

QUESTION: Solidification_Analysis:#CB#(THERMAL,THERMO-MECHANICAL)

VALUE: THERMAL

...

  • State: Defines the state of a field; this state can be: disabled, enabled or hidden. Here is an example:

...

QUESTION: Elastic modulus XX axis

VALUE: 2.1E+11

STATE: HIDDEN

...

  • #MAT#('BookName'): Defines the field as a material, to be selected from the list of materials in the book 'BookName'. Here is an example:

QUESTION:Composition_Material#MAT#(BaseMat)

VALUE:AISI_4340_STEEL