GiD 10 Customization Manual Pre and post processing system for Numerical Simulations.
International Center For
Numerical Methods In Engineering (CIMNE)
FEATURES
FEATURES
GiD offers the following customization features:
Complete menu´s can be customised and created to suit the specific needs of the user´s simulation software.
Simple interfaces can be developed between the data definition and the simulation software.
Simple interfaces based on scalar, vector and matrix quantities can be developed for the results visualisation.
Menus for the results visualisation can be customised and created according to the needs of the application or analysis.
The customization in GiD is done by creating a ...
When GiD is to be used for a particular type of analysis, it is necessary to predefine all the information required from the user and to define the way the final information is given to the solver module. To do so, some files are used to describe conditions, materials, general data, units systems, symbols and the format of the input file for the solver. We give the name Problem Type to this collection of files used to configure GiD for a particular type of analysis.
Note: You can also learn how to configure GiD for a particular type of analysis by following the ...
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.
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:
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
PasswordPath: The value of this node specifies a relative or absolute path describing where to locate/create the file password.txt. If the value is a relative path it is taken with respect to the problem type path.
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....
Here is an example of how to create a conditions file, explained step by step:
First, you have to create the folder or directory where all the problem type files are located, problem_type_name.gid in this case.
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....
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....
Here is an example of how to create a materials file, explained step by step:
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.
Create the first material, which starts with the line:
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....
Here is an example of how to create a problem data file, explained step by step:
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.
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....
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:
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.
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:
Once you have generated the mesh, and assigned the conditions and the materials properties, as well as the general problem and intervals data for the solver, it is necessary to produce the data input files to be processed by that program.
To manage this reading, GiD is able to interpret a file called problem_type_name.bas (where problem_type_name is the name of the working directory of the problem type without the .bas extension).
This file (template file) describes the format and structure of the required data input file for the solver that is used for a particular case. This file must remain in the problem_type_name.gid directory, as well as the other files already described - problem_type_name.cnd, problem_type_name.mat, problem_type_name.prb and also problem_type_name.sim and ***.geo, if desired....
All the rules that apply to filename.bas files are also valid for other files with the .bas extension. Thus, everything in this section will refer explicitly to the file filename.bas. Any information written to this file, apart from the commands given, is reproduced exactly in the output file (the data input file for the numerical solver). The commands are words that begin with the character *. (If you want to write an asterisk in the file you should write **.) The commands are inserted among the text to be literally translated. Every one of these commands returns one (see Single value return commands...
When writing a command, it is generally not case-sensitive (unless explicitly mentioned), and even a mixture of uppercase and lowercase will not affect the results.
These commands return more than one value in a prescribed order, writing them one after the other. All of them except LocalAxesDef are able to return one single value when a numerical argument giving the order of the value is added to the command. In this way, these commands can appear within an expression. Neither LocalAxesDef nor the rest of the commands without the numerical argument can be used inside expressions. Below, a list of the commands with the appropriate description is displayed.
* To avoid line-feeding you need to write *, so that the line currently being used continues on the following line of the file filename.bas.
*# If this is placed at the beginning of the line, it is considered as a comment and therefore is not written.
** In order for an asterisk symbol to appear in the text, two asterisks ** must be written.
Include
*Include. The include command allows you to include the contents of a slave file inside a master .bas file, setting a relative path from the Problem Type directory to this secondary file. ...
Below is an example of how to create a Template file, step by step.
Note that this is a real file and as such has been written to be compatible with a particular solver program. This means that some or all of the commands used will be non-standard or incompatible with the solver that another user may be using.
The solver for which this example is written treats a line inside the calculation input file as a comment if it is prefixed by a $ sign. In the case of other solvers, another convention may apply.
Now we want to output the desired results to the output file. The first line should be a title or a label as this lets the solver know where a loop section begins and ends. The end of this block of instructions will be signalled by the line END_GEOMETRY.
GEOMETRY
The next two of lines give the user information about what types of commands follow.
Firstly, a title for the first subsection, ELEMENTAL CONNECTIVITIES:
After the data initialization and declarations, the solver requires a list of nodes with boundary conditions and the fields that have been assigned....
First, we set the loop to the interval of the data.
*loop intervals
The next couple of lines indicate the starting of one section and the title of the example, taken from the first field in the interval data with an abbreviation on the label. They are followed by a comment explaining the type of data we are using.
LOADS
TITLE: *IntvData(Charge_case)
$ LOAD TYPE
We begin by setting the condition as before. If one condition is assigned twice or more to the same element without including the *CanRepeat parameter in the *Set Cond, the condition will appear once; if the *CanRepeat parameter is present then the number of conditions that will appear is the number of times it was assigned to the condition....
Once all the problem type files are finished (.cnd, .mat, .prb, .sim, .bas files), you can run the solver. You may wish to run it directly from inside GiD.
To do so, it is necessary to create the file problem_type_name.bat in the Problem Type directory. This must be a shell script that can contain any type of information and that will be different for every operating system. When you select the Calculate option in GiD Preprocess this shell script is executed (see CALCULATE from Reference Manual).
Because the .bat file will be different depending on the operating system, it is possible to create two files: one for Windows and another for Unix/Linux. The Windows file has to be called: ...
The information about what is displayed when Output view: is pressed is also given here. To determine what will be shown, the script must include a comment line in the following form:
For Windows :
rem OutputFile: %1.log
For Linux/Unix:
# OutputFile: "$1.log"
where "$1.log" means to display in that window a file whose name is: project_name.log. The name can also be an absolute name like output.dat. If this line is omitted, when you press Output view:, nothing will be displayed....
included in the .bat file means that the given filename is the error file. At the end of the execution of the .bat file, if the errorfile does not exist or is zero, execution is considered to be successful. If not, an error window appears and the contents of the error file are considered to be the error message. If this line exists, GiD will delete this file just before calculating to avoid errors with previous calculations....
In GiD Postprocess you can study the results obtained from a solver program. The solver and GiD Postprocess communicate through the transfer of files. The solver program has to write the results to a file that must have the extension .post.res, or the old .flavia.res, and its name must be the project name.
The solver program can also send the postprocess mesh to GiD (though this is not mandatory), where it should have the extension .post.msh, or the old version .flavia.msh. If this mesh is not provided by the solver program, GiD uses the preprocess mesh in Postprocess.
If the same meshes are used for all the analyses, the following section can be skipped.
A new concept has been introduced in Postprocess: Group, which allows the postprocessing of problems which require re-meshing or adaptive meshes, where the mesh change depending on the time step.
Normal operations, such as animation, displaying results and cuts, can be done over these meshes, and they will be actualized when the selected analysis/step is changed, for example by means of View results -> Default analysis/step
Note: The new postprocess results format requires GiD version 6.1.4b or higher.
Note: Code developers can download the GiDpost tool from the GiD web page (http://www.gidhome.com/gid-plus/tools/gidpost/); this is a C/C++/Fortran library for creating postprocess files for GiD in both ASCII and compressed binary format.
This is the ASCII format description:
The first line of the files with results written in this new postprocess format should be:...
If Gauss points are to be included, they must be defined before the Result which uses them. Each Gauss points block is defined between the lines GaussPoints and End GaussPoints.
If a Result Range Table is to be included, it must be defined before the Result which uses it.
Each Result Range Table is defined between the lines ResultRangesTable and End ResultRangesTable.
The structure is as follows and should:
Begin with a header that follows this model:
ResultRangesTable "ResultsRangeTableName"
where ResultRangesTable: is not case-sensitive; "ResultsRangeTableName": is a name for the Result Ranges Table, which will be used as a reference by the results that use this Result Ranges Table....
Each Result block is identified by a Result header, followed by several optional properties: component names, ranges table, and the result values, defined by the lines Values and End Values.
The structure is as follows and should:
Begin with a header that follows this model:
Result "result name" "analysis name" step_value my_result_type my_location "location name"
Results can be grouped into one block. These results belong to the same time step of the same analysis and are located in the same place. So all the results in the group are nodal results or are defined over the same gauss points set.
Each Result group is identified by a ResultGroup header, followed by the results descriptions and its optional properties - such as components names and ranges tables, and the results values - all between the lines Values and End values.
New file *.post.lst can be read into GiD, postprocess. This file is automatically read when the user works in a GiD project and changes from pre to postprocess.
This file can also be read with File-->Open
The file contains a list of the files to be read by the postprocess:
The first line should contain one of these words: Single / Merge / Multiple to read a single file, merge the list of files or handle them as several meshes (for diferent time steps);
rest of lines: the files to be read, with one filename per line;...
This file is a complete list of the dumped results, where each result will be organized as follows:
Set 1: Header. Results description
The total number of lines in this set is 1, composed of 1 character string, 1 integer, 1 real, 1 optional character string, which depends on the first integer, plus 3 integers:
Note: Here is a description of the old Gauss Points file format for the old results file format. However, the new Gauss Points file format (see Gauss Points) is also compatible with the old results format.
Gauss Points: For the Gauss points to be included in the results, they must be treated as if they were a type of result, but:
- they must be inserted at the beginning of the file; and
- the header structure is the same as that of the results files, but the meaning changes....
The old postprocess mesh format is still compatible with this version of GiD. The files containing the postprocess mesh (in the old file format) can be separated into two categories:
3D Data Files: ProjectName.post.msh, or the old ProjectName.flavia.msh, for volume mesh information and ProjectName.post.bon, or the old ProjectName.flavia.bon, for surface mesh information; and
2D Data Files: ProjectName.post.dat, or the old ProjectName.flavia.dat, for 2D mesh information.
Postprocessing data files are ASCII files and must be in a specific format, which is explained below. Each mesh information file can only handle one type of element....
This set contains six lines which are included so that information about the project can be included. They can be left blank, but it is suggested to use them for the project name and current version, as well as any extra comments, e.g. the type of project, the kinds of equations used, the conditions and materials involved, etc.
Note: As the seventh line of the file (i.e. Set 2) contains a series of numbers, it is advisable to use the sixth line to explain what these figures represent.
This set contains six lines which are included so that information about the project can be included. They can be left blank, but it is suggested to use them for the project name and current version, as well as any extra comments, e.g. the type of project, the kinds of equations used, the conditions and materials involved, etc.
Note: As the seventh line of the file (i.e. Set 2) contains a series of numbers, it is advisable to use the sixth line to explain what these figures represent.
This set contains six lines which are included so that information about the project can be included. They can be left blank, but it is suggested to use them for the project name and current version, as well as any extra comments, e.g. the type of project, the kinds of equations used, the conditions and materials involved, etc.
Note: As the seventh line of the file (i.e. Set 2) contains a series of numbers, it is advisable to use the sixth line to explain what these figures represent.
This chapter looks at the advanced features of GiD in terms of expandability and total control. Using the Tcl/Tk extension you can create script files to automatize any process created with GiD. With this language new windows and functionalities can be added to the program.
For more information about the Tcl/Tk programming language itself, look at www.scriptics.com http://www.scriptics.com.
If you are going to use a Tcl file, it must be located in the Problem Type directory and be called problem_type_name.tcl....
The structure of problem_type_name.tcl can optionally implement some of these Tcl prototype procedures (and other user-defined procedures). The procedures listed below are automatically called by GiD. Their syntax corresponds to standard Tcl/Tk language:
This is a simple function, but a very powerful one. It is used to enter commands directly inside the central event manager. The commands have the same form as those typed in the command line within GiD.
You have to enter exactly the same sequence as you would do interactively, including the escape sequences (using the word escape) and selecting the menus and operations used.
You can obtain the exact commands that GiD needs by checking the Right buttons...
This function provides any information about GiD, the current data or the state of any task inside the application. Depending on the arguments introduced after the GiD_Info sentence, GiD will output different information:
GiD_Info materials
This command returns a list of the materials in the project.
These options are also available:
["material_name"]: If a material name is given, its properties are returned. It is also possible to add the option ...
GiD_Mesh create|delete|edit|get node|element <num>|append <elemtype> <nnode> <N1 ... Nnnode> <radius> <nx ny nz> ?<matname>? | <x y z>
To create, delete, modify or know information about mesh nodes or elements of the preprocess:
<num>|append: <num> is the identifier (integer > 0) for the node or element. You can use the word 'append' to set a new number automatically. The number of the created, deleted or modified entity is returned as the result. When deleting, it is possible to use a list of entities;...
GiD_Result create ?-array? {Result header} ?{Unit <unit_name>}? ?{componentNames name1 ...}? {entity_id scalar|vector|matrix_values} {...} {...} : these creation parameters are the same as for the postprocess results format (see Result of Postprocess results format: ProjectName.post.res...
list : gets a list of the existent graphs, an empty list if there is no graph;
show : switches the graphic view and shows the graphs;
hide : hides the graphs and switches back to mesh view;
clear : delete all graphs in GiD;
get <graph_name> : gets a list with the values of the graph with name "graph_name", the values are the same used to create a graph: <label_x> <label_y> <x_values> <y_values>...
GiD offers you the opportunity to customize the pull-down menus. You can add new menus or to change the existing ones. If you are creating a problem type, these functions should be called from the InitGIDProject or InitGIDPostProcess functions (see TCL AND TK EXTENSION).
Note: Menus and option menus are identified by their names.
Create a directory named html inside your Problem Type directory
Call HelpWindow "CUSTOM_HELP" "problem_type_name", where problem_type_name is the name of your problem type with the .gid extension (e.g. Examples/cmas2d.gid).
The function HelpWindow opens the file "index.html" which must be inside the html folder.
With GiD version 7.4 and later, problem type developers can take advantage of the new help format. It is essentially the same html content, but now with an enhanced look and structure. The GiDCustomHelp procedure below is how you can show help using the new format:
GiDCustomHelp ?args?
where args is a list of pairs option value. The valid options are:
-title : specifies the title of the help window. By default it is "Help on <problem_type_name>"....
Assuming that html has been chosen as the base directory for the multilingual help content, the following structure is possible:
html
\__ en - English content
\__ es - Spanish content
Each content will probably have a directory structure to organize the information. By default the help system builds a tree resembling the directory structure of the help content. In this way there will be an internal node for each subdirectory, and the html documents will be the terminal nodes of the tree....
With HelpDirs we can specify which of the subdirectories will be internal nodes of the help tree. Moreover, we can specify labels for the nodes and a link to load when a particular node is clicked. The link is relative the node. For instance:
TocPage defines an html page as a table of contents for the current node (current directory). We have considered two ways of specifying a table of contents:
If we specify a topic index by IndexPage, we can take advantage of the search index. In IndexPage we can provide a set of html index pages along with the structure type of the index. The type of the index could be:
In this section the Tcl/Tk (scripted) customization of the look and feel of the data windows is shown. The layout of the properties drawn in the interior of any of the data windows - either Conditions, Materials, Interval Data or Problem Data - can be customized by a feature called TkWidget; moreover, the common behaviour of two specific data windows, Conditions and Materials, can be modified by a Tcl procedure provided for that purpose. This common behaviour includes, in the case of Materials for example, assigning/unassigning, drawing, geometry types, where to assign materials, creating/deleting materials, etc....
The problem type developer can change the way a QUESTION is displayed and if he wishes he can also change the whole contents of a window, while maintaining the basic behavior of the data set, i.e. in the Condition window: assign, unassign, draw; in the Material window: create material, delete material; and so on.
With the default layout for the data windows, the questions are placed one after another in one column inside a container frame, the QUESTION's label in column zero and the VALUE in column one. For an example see picture below....
In this subsection we explain a Tcl procedure used to configure the common behaviour of Materials. We are working on providing a similar functionality for Conditions using the same interface.
GiD_DataBehaviour controls properties of data windows for Materials and Conditions (not currently implemented). For Materials we can modify the behaviour of assign, draw, unassign, impexp (import/export), new, modify and delete. We can also specify the entity type list with the assign option throught the subcommands geomlist and meshlist.
Normally, a problem type requires a minimum version of GiD to run. Because the problem type can be distributed or sold separately from GiD, it is important to check the GiD version before continuing with the execution of the problem type. GiD offers a function, GidUtils::VersionCmp, which compares the version of the GiD currently being run with a given version.
GidUtils::VersionCmp { Version }
This returns a negative integer if Version is greater than the currently executed GiD version; zero if the two versions are identical; and a positive integer if Version is less than the GiD version....
The Tcl language has the exec command used to invoke a subprocess. This command treats its arguments as the specification of one or more subprocesses to execute. It is possible to invoke a subprocess from GiD using this option.
Example: invoking a process in the background
exec netscape http://www.gidhome.com &
Note: In Windows, instead of & it is necessary to put >& NUL: & to run the process in the background. ...
Here is a step by step example of how to create a Tcl/Tk extension. In this example we will create the file cmas2d.tcl, so we will be extending the capabilities of the cmas2d problem type. The file cmas2d.tcl has to be placed inside the cdmas2d Problem Type directory.
Note: The cmas2d problem type calculates the center of mass of a 2D surface. This problem type is located inside the Problem Types directory, in the GiD directory.
In this example, the cmas2d.tcl creates a window which appears when the problem type is selected....
This section explains a new way to expand GiD capabilities: the plug-in mechanism.
Plug-ins which should be used by GiD shoud be present inside the $GID/plugins directory.
There are two possible plugin mechanisms:
- the .tcl plug-in and
- the dynamic library plug-in ( look into $GID/plugins/Import/Docs for the PostImportPluginManual which describes this mechanism and the provided examples)
By GiD version 10.1.2d following plug-ins are provided:
To learn how to configure GiD for a particular type of analysis, you can find some practical examples:
By following the Problem Type Tutorial; this tutorial is included with the GiD package you've bought. You can also download the tutorial from support area of the GiD web page [http://www.gidhome.com]
By studing and modifing some Problem Type
Problem types included in GiD by default as example:...
