Page Comparison

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.PROBLEMTYPE 'CLASSIC'>CONFIGURATION FILES>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, over lines, over surfaces, over volumes, over layers or over groups, and what kind of mesh entity they will be transferred over, i.e. over nodes, over face elements or over body elements.

• Over nodes This means that the condition will be transferred to the nodes contained in the geometrical entity where the condition is assigned.
• Over face elements ?multiple? If this condition is applied to a line that is the boundary of a surface or to a surface that is the boundary of a volume, this condition is transferred to the higher elements, marking the affected face. If it is declared as multiple, it can be transferred to more than one element face (if more than one exists). By default it is considered as single, and only one element face will be marked.
• Over body elements If this condition is applied to lines, it will be transferred to line elements. If assigned to surfaces, it will be transferred to surface elements. Likewise, if applied to volumes, it will be transferred to volume elements.

...

• #G#: global axes;
• #A#: automatic axes;
• #L#: automatic alternative axes.
• #M#: main curvature axes

...

• NumEntity: to track the numerical id of the geometric source entity
• x y z : to use the coordinates of the node or entity center where the condition is applied
• Cond(num_field,REAL): to use the value of other fields of this condition (REAL or INT declare that must be considered as a real or a integer number)
• Valid mathematical operations are the same as the used for the *Operation template command.

...

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.
2. 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.
3. 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:

• • An alphanumeric field name.
  • An alphanumeric field name followed by the #LA# statement, and then the single or double parameter.
  • An alphanumeric field name followed by the #CB# statement, and then the optional values between parentheses.

...

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.

...

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.

...

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.
2. 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: DENSITY_(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.

...

• Array fields

...

• Aesthetic 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:

...

• • 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
....
Image RemovedImage Removed

• • 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 ...
Image Removed

• • 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.

...

• 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

...

• 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. 1. <Vi> is the value that triggers the actions. A special value is #DEFAULT#, which refers to all the values not listed.
   2. [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.
   3. <Ai> is the action and can have one of these values: SET,DISABLE, HIDE, RESTORE. All these actions change the value of the property with the following differences:

SET assign the value, triggering its dependencies
DISABLE disables the property
HIDE hides the property
RESTORE brings the property to the enabled and visible state.
Note: SET will trigger its dependencies always, also if #CURRENT# value is used. DISABLE, HIDE and RESTORE usually maintain #CURRENT# value, but if other value is used really is like do also a SET and dependencies will be triggered also.

1. 1. <Pi> is the name of the property to be modified.
   2. <NVi> is the new value of <Pi>. A special value is #CURRENT#, which refers to the current value of <Pi>.

...

• 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

• TKWIDGET: TkWidget

The Tkwidged special field mechanism allow to customize with Tcl scripting language condition or material fields.
some Tcl procedures are predefined in dev_kit.tcl to be used for common cases, like show current layers, materials, pick a point or node, or select a filename.

• • Layer field:

Declare in the tkwidget field to use the Tcl procedureGidUtils::TkwidgetGetLayername, e.g:
...
QUESTION: your_question
VALUE: your_layername
TKWIDGET: GidUtils::TkwidgetGetLayername

• • Material field:

Declare in the tkwidget field to use the Tcl GidUtils::TkwidgetGetMaterialname e.g:
...
QUESTION: your_question
VALUE: your_materialname
TKWIDGET: GidUtils::TkwidgetGetMaterialname

• • Pick point or node field

Declare in the tkwidget field to use the Tcl procedure GidUtils::TkwidgetPickPointOrNode , e.g.
...
QUESTION: your_question
VALUE: your_node_id
TKWIDGET: GidUtils::TkwidgetPickPointOrNode

• • Select filename field

Declare in the tkwidget field to use the Tcl procedure GidUtils::TkwidgetGetFilenameButton , e.g.
...
QUESTION: your_question
VALUE: your_filename
TKWIDGET: GidUtils::TkwidgetGetFilenameButton

• • Vector field

To pack in a single line the three components of a vector, internally stored in the same question as a list of three real numbers, e.g.
...
QUESTION: your_question
VALUE: vx vy vz
TKWIDGET: GidUtils::TkwidgetGetVector3D

• • Text widget instead of entry widget

To replace the standard single-line entry widget with a multi-line text widget.
...
QUESTION: your_question
VALUE: your_value
TKWIDGET: GidUtils::TkwidgetText

• • Configure the entry field widget

procedure to change some configuration of the ttk::entry widget. GidUtils::TkwidgetEntry CONFIGURE {-<option> <value>}
...
QUESTION: your_question
VALUE: your_value
TKWIDGET: GidUtils::TkwidgetEntry CONFIGURE {-width 20}
PROBLEMTYPE 'CLASSIC'>CONFIGURATION FILES>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 and mesh model of preprecess 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.
Image Removed
Data unit window
Unit system: It is possible to define more than one 'unit sytem'. When the user select a unit sytem it mean than when writting to the calculation file the fields with units (material properties, conditions, general data, model length) they will be written converted to the reference unit of this magnitude for the selected unit system.
Hide some units depending on unit system:
The tcl procedure Units::SetUnitsDisallowed allow to specify a list of units to be disallowed (not used in graphical windows)
proc Units::SetUnitsDisallowed { basic_units_to_disallow }
example
proc GiD_Event_InitProblemtype { dir } {
My_On_AfterChangeModelUnitSystem [GiD_Units get system]
}
proc GiD_Event_AfterChangeModelUnitSystem { old_unit_system new_unit_system } {
My_On_AfterChangeModelUnitSystem $new_unit_system
}
proc My_On_AfterChangeModelUnitSystem { new_unit_system } {
if { $new_unit_system == "IMPERIAL" } {
Units::SetUnitsDisallowed {m cm mm Mm km kg ton kton N kp kN MN Nm kNm MNm Pa kPa MPa GPa}
} elseif { [string range $new_unit_system 0 8] == "INTERNATIONAL" } {
Units::SetUnitsDisallowed {in Mi miles ft lb lbf kip lbfft lbfin psi ksi Gal}
} else {
W "unexpected unit system $new_unit_system"
}
}
PROBLEMTYPE 'CLASSIC'>CONFIGURATION FILES>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.
PROBLEMTYPE 'CLASSIC'>CONFIGURATION FILES>Conditions symbols file (.sim)>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.