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.
Of course, the real aim of this example is familiarize you with the commands GiD uses. What follows is the universal method of accessing GiD's internal database, and then outputting the desired data to the solver.
It is assumed that files with the .bas extension will be created inside the working directory where the problem type file is located. The filename must be problem_type_name.bas for the first file and any other name for the additional .bas files. Each .bas file will be read by GiD and translated to a .dat file.
It is very important to remark that any word in the .bas file having no meaning as a GiD compilation command or not belonging to any command instructions (parameters), will be written verbatim to the output file.
First, we create the header that the solver needs in this particular case.
It consists of the name of the solver application and a brief description of its behaviour.
What follows is a commented line with the ECHO ON command. This, when uncommented, is useful if you want to monitor the progress of the calculation. While this particular command may not be compatible with your solver, a similar one may exist.
The next line specifies the type of calculation and the materials involved in the calculation; this is not a GiD related command either.
As you can see, a commented line with dashes is used to separate the different parts of the file, thus improving the readability of the text.
The next stage involves the initialization of some variables. The solver needs this to start the calculation process.
The following assignments take the first (parameter (1)) and second (parameter (2)) fields in the general problem, as the number of problems and the title of the problem.
The actual position of a field is determined by checking its order in the problem file, so this process requires you to be precise.
Assignment of the first (1) field of the Problem data file, with the command *GenData(1):
Assignment of the second (2) field assignment, *GenData(2):
The next instruction states the field where the starting time is saved. In this case, it is at the 10th position of the general problem data file, but we will use another feature of the *GenData command, the parameter of the command will be the name of the field.
This method is preferable because if the list is shifted due to a field deing added or subtracted, you will not lose the actual position. This command accepts an abbreviation, as long as there is no conflict with any other field name.
Here comes the initialization of some general variables relevant to the project in question - the number of points, the number of elements or the number of materials.
The first line is a description of the section.
The next line introduces the assignments.
This is followed by another line which features the three variables to be assigned. NPNOD gets, from the *npoin function, the number of nodes for the model; NELEM gets, from *nelem, either the total number of elements in the model or the number of elements for every kind of element; and NMATS is initialized with the number of materials:
In the next line, NNODE gets the maximum number of nodes per element and NDIME gets the variable *ndime. This variable must be a number that specifies whether all the nodes are on the plane whose Z values are equal to 0 (NDIME=2), or if they are not (NDIME=3):
The following lines take data from the general data fields in the problem file. NCARG gets the number of charge cases, NGDLN the number of degrees of freedom, NPROP the properties number, and NGAUSS the gauss number; NTIPO is assigned dynamically:
NLOAD= *GenData(Load_Cases), *\
You could use NGDLN= *GenData(Degrees_Freedom), *\, but because the length of the argument will exceed one line, we have abbreviated its parameter (there is no conflict with other question names in this problem file) to simplify the command.
Note that the last assignment is ended with the specific command *\ to avoid line feeding. This lets you include a conditional assignment of this variable, depending on the data in the General data problem.
Within the conditional a C format-like strcmp instruction is used. This instruction compares the two strings passed as a parameter, and returns an integer number which expresses the relationship between the two strings. If the result of this operation is equal to 0, the two strings are identical; if it is a positive integer, the first argument is greater than the second, and if it is a negative integer, the first argument is smaller than the second.
The script checks what problem type is declared in the general data file, and then it assigns the coded number for this type to the NTIPO variable:
You have to cover all the cases within the if sentences or end the commands with an elseif you do not want unpredictable results, like the next line raised to the place where the parameter will have to be:
In our case this last rule has not been followed, though this can sometimes be useful, for example when the problem file has been modified or created by another user and the new specification may differ from the one we expect.
The next assignment is formed by a string compare conditional, to inform the solver about a configuration setting.
First is the output of the variable to be assigned.
Then there is a conditional where the string contained in the value of the Result_File field is compred with the string "Yes". If the result is 0, then the two strings are the same, while the output result 1 is used to declare a boolean TRUE.
Then we compare the same value string with the string "No", to check the complementary option. If we find that the strings match, then we output a 0.
The second to last assignment is a simple output of the solver field contents to the INDSO variable:
The last assignment is a little more complicated. It requires the creation of some internal values, with the aid of the *set cond command.
The first step is to set the conditions so we can access its parameters. This setting may serve for several loops or instructions, as long as the parameters needed for the other blocks of instructions are the same.
This line sets the condition Point-Constraints as an active condition. The *nodes modifier means that the condition will be listed over nodes. The *or(... modifiers are necessary when an entity shares some conditions because it belongs to two or more elements.
As an example, take a node which is part of two lines, and each of these lines has a different condition assigned to it. This node, a common point of the two lines, will have these two conditions in its list of properties. So declaring the *or modifiers, GiD will decide which condition to use, from the list of conditions of the entity.
A first instruction will be as follows, where the parameters of the *or commands are an integer - (1, and (3, in this example - and the specification int, which forces GiD to read the condition whose number position is the integer.
In our case, we find that the first (1) field of the condition file is the X-constraint, and the third (3) is the Y-constraint:
GiD still has no support for substituting the condition's position in the file by its corresponding label, in contrast to case for the fields in the problem data file, for which it is possible.
Now we want to complete the setting of the loop, with the addition of new conditions.
Observe the order in which the conditions have been included: firstly, the surface constraints with the *Set Cond command, since it is the initial sentence; then the pair of *Add Cond sentences, the line constraints; and finally, the point constraints sentence. This logical hierarchy forces the points to be the most important items.
Last of all, we set a variable with the number of entities assigned to this particular condition.
Note that the execution of this instruction is only possible if a condition has been set previously.
To end this section, we put a separator in the output file:
After creating or reading our model, and once the mesh has been generated and the conditions applied, we can export the file (project_name.dat) and send it to the solver.
The command to create the .dat file can be found on the File -> Export -> Calculation File GiD menu. It is also possible to use the keyboard shortcut Ctrl-x Ctrl-c.
These would be the contents of the project_name.dat file:
This is where the calculation input begins.