This is gid.info, produced by Makeinfo version 3.12h from gid.texinfo.

   This is the GiD manual

   Copyright 1997-2002 CIMNE


File: gid.info,  Node: Materials file,  Next: Problem and intervals data file,  Prev: Conditions file,  Up: Configuration Files

Materials file (.mat)
---------------------

   This file `NAME.mat' include originally the definition of different
materials through their properties. These are base materials as they
can be used as templates during the pre-processing step for the
creation of newer ones.

   The user can define as many materials as desired and with a variable
number of fields.  All the unused materials will not be taken in
consideration when writing the data input files for the solver.
Alternatively, they can be useful to generate a materials library.

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

   In a similar way as a condition was 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:

     NUMBER: material_number 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
     NUMBER: material_number MATERIAL: material_name
       ...
     END MATERIAL

   If a property of a material change depending on something (one
example would be one property depending on the temperature and 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 apply the suitable property value.

   The declaration of the table requires a pair of lines:

   First, a QUESTION line with a list of alphanumeric values between
parenthesis.
     QUESTION: field_name:(...,optional_value_i,...)
   This values are the name of each of the columns in the table, and
the number of values declared are the number of columns.

   This first line is followed by the actual data declaration: a line
started with the words `VALUE: #N#' 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 multiplication of the number of columns by the number of rows to be
declared.

   The usual case of aplication of this declaration is on the
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, considering a word as a
character string without any blank space amongst them. The strings
signaled between quotes are literal and the ones within brackets are
optional. The interface is case-sensitive, so the uppercase letters
must be maintained. `Default_field_value' and different
`optional_value_i' can be alphanumeric, integers or reals, depending on
the type.

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

   Note that in this file it's not permitted the inclusion of blank
lines between material definitions neither between questions and values.

   NOTE: There are other available options to expand the capabilities
of the materials window. (*note Special fields::.)

* Menu:

* Example Materials File creation ::


File: gid.info,  Node: Example Materials File creation,  Prev: Materials file,  Up: Materials file

Example: Creating the materials file
....................................

   Next is an example of a materials file creation, explained step by
step:
  1. Create and edit the file (`problem_type_name.mat' on 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 name of the file and the directory are the same.

  2. Create the first material, which starts with these lines:

          NUMBER: 1
          MATERIAL: Air
     The first number is used to index the material. Each material will
     be refered  with one unique number (two materials can not share
     the same number). The second parameter is the name of the
     material. Again, a unique material name into this  material file
     is required (do not use blank spaces in the name of the material.)

  3. 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 want. To end the material
     definition, add the following line:

          END MATERIAL

  4. In this example we have introduced some materials; the `.mat' file
     would be as follows:
          NUMBER: 1 MATERIAL: Air
          QUESTION: Density
          VALUE: 1.01
          END MATERIAL
          NUMBER: 2 MATERIAL: Steel
          QUESTION: Density
          VALUE: 7850
          END MATERIAL
          NUMBER: 3 MATERIAL: Aluminium
          QUESTION: Density
          VALUE: 2650
          END MATERIAL
          NUMBER: 4 MATERIAL: Concrete
          QUESTION: Density
          VALUE: 2350
          END MATERIAL
          NUMBER: 5 MATERIAL: Water
          QUESTION: Density
          VALUE: 997
          END MATERIAL
          NUMBER: 6 MATERIAL: Sand
          QUESTION: Density
          VALUE: 1370
          END MATERIAL

  5. The management of the materials defined in the `.mat' file, is
     done in the Materials window (found in the Data menu), in the
     preprocess of GiD.



File: gid.info,  Node: Problem and intervals data file,  Next: Conditions symbols file,  Prev: Materials file,  Up: Configuration Files

Problem and intervals data file (.prb)
--------------------------------------

   The file `NAME.prb' contains all the information about the 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. Example of general problem data can be
the type of solution algorithm used by the solver, the value of the
various time steps, convergence conditions and so on.

   Within this data, the user 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
changing the various 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, considering a word as a
character string without any blank space amongst them. The strings
signaled between quotes are literal and the ones inside brackets are
optional. The interface is case-sensitive, so the uppercase letters
must be maintained. `Default_field_value' and different
`optional_value_i' can be alphanumeric, integers or reals, depending on
the type.

   NOTE: There are other available options to expand the capabilities
of the Problem Data window. (*note Special fields::.)

* Menu:

* Example Problem and intervals data file creation::


File: gid.info,  Node: Example Problem and intervals data file creation,  Prev: Problem and intervals data file,  Up: Problem and intervals data file

Example: Creating the PRB data file
...................................

   Next is an example of a problem data file creation, explained step
by step:
  1. Create and edit the file (`problem_type_name.prb' on this example)
     inside the `problem_type_name' directory (where all your problem
     type files are located).  Except for the extension, the name of
     the file and the directory must be the same.

  2. Start the file with this line:

          PROBLEM DATA

  3. 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'.

  4. To finish the file, add the following line:

          END PROBLEM DATA

  5. The whole file is as follows:

          PROBLEM DATA
          QUESTION: Unit_System#CB#(SI,CGS,User)
          VALUE: SI
          QUESTION: Title
          VALUE: Default_title
          END GENERAL DATA

  6. The management of the options defined in the `.prb' file, is done
     in the Problem Data window (found in the Data menu), in the
     preprocess of GiD.



File: gid.info,  Node: Conditions symbols file,  Next: Unit System file,  Prev: Problem and intervals data file,  Up: Configuration Files

Conditions symbols file (.sim)
------------------------------

   This file `NAME.sim' comprises different symbols to represent some
conditions during the pre-processing stage. The user may define these
symbols by creating, ad hoc, geometrical drawings and the appropriate
symbol will appear over the entity with the applied condition every
time the user asks 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.

   Also the spatial orientation can be defined in this file, depending
on the values taken by the required data. For global definitions, the
user must 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 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 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') makes reference to the
type of variable (independent of the letters case) and `i' is the
number of the field for that particular condition.

* Menu:

* Example Symbols File creation ::


File: gid.info,  Node: Example Symbols File creation,  Prev: Conditions symbols file,  Up: Conditions symbols file

Example: Creating the Symbols file
..................................

   Next is an example of a symbol file creation.  Create and edit the
file (`problem_type_name.sim' on this example) inside the
`problem_type_name' directory (where all your problem type files are
located).  Except for the extension, the name 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 file `.sim' where the user has
defined four different symbols. Each one is read from a file `***.geo'.
There is no indication of how many overall symbols are implemented. GiD
simply reads all the file long through the end.

   The files `***.geo' are obtained through GiD. The user may design a
particular drawing to symbolize a condition and this drawing will be
stored as `PROBLEMNAME.geo' when saving this project as
`PROBLEMNAME.gid'.  The user needs not to be concerned about the symbol
size but has to keep in mind that the origin corresponds to the point
(0,0,0) and the reference vector is (1,0,0). Subsequently, when these
files `***.geo' are invoked from `problem_type_name.sim', the symbol
drawing, appears scaled on the display, at the entities location.

   Nevertheless, the number of symbols and consequently, the number of
files `***.geo', can vary from a condition to another. In the previous
example, for instance, the condition called `Point-Constraints', which
is so declared by the use of `cond', comprises three different symbols.
GiD knows that from the number 3 written below the condition's name.
Next, GiD reads 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.

   Let's imagine that this condition has six fields. First, third and
fifth field values express if there exist constraints along `X-axis',
`Y-axis' and `Z-axis', respectively.  These values are integers and in
case they were null, the concerned degree of freedom would be assumed
to be unconstrained.

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

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

   For the third symbol, got 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, got 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 fields values. Different ways of C-language
expressions are available in GiD.  Thus, the last expression would be
equivalent to put '`(fabs(cond(real,2))>0. || fabs(cond(real,4))!=0. ||
fabs(cond(real,6))>1e-10)''.

   *Note:* As previously mentioned, GiD internally creates a
`PROJECTNAME.geo' 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
`PROJECTNAME.geo' is stored in the `PROJECTNAME.gid' directory, whereas
these user-created files `***.geo' are stored in the
`problem_type_name.gid' directory, being `problem_type_name' the
problem's name.


File: gid.info,  Node: Unit System file,  Next: Special fields,  Prev: Conditions symbols file,  Up: Configuration Files

Unit System file (.uni)
-----------------------

   When GiD is installed, the file `units.gid' is copied within the GiD
directory.  In this file it's defined a table of magnitudes. For each
magnitude there is a set of units and a convertion factor between the
unit and the reference unit. Also are defined the units systems. An unit
system is a set of mangnitudes and the corresponding unit.

     BEGIN TABLE
      LENGTH : m {reference}, 100 cm, 1e+3 mm
      ...
      STRENGTH : kg*m/s^2 {reference}, N, 1.0e-1 kp
     END
     
     BEGIN SYSTEM(INTERNATIONAL)
      LENGTH : m
      MASS : kg
      STRENGTH : N
      ...
      TEMPERATURE : C
     END

   The syntax of the unit file (`problem_type_name.uni') within the
problem type is similar.  Besides, it could include the line:

     USER-DEFINED: ENABLED (DISABLED)

   meaning that the user is able (or not) to define it's own system unit
within the project. If the line does not appear in the file then, it's
assumed as having the value `ENABLED'

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


File: gid.info,  Node: Special fields,  Prev: Unit System file,  Up: Configuration Files

Special fields
--------------

   These fields are useful in order to organize the information within
the data files.  They make the information showed on the data windows
nicest and more readable. In this way the user can concentrate just on
the data properties concerning the current context.

   * Book: With the field Book it is possible to split the data windows
     in 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
          ...

     The same applies to conditions. For general and interval data, the
     field book groups a set of properties.
   * Title: The Title field groups a set of properties on diferent tabs
     of one book. All properties appearing after this field will be
     included on this tab.

          TITLE: Basic
          ...
          Basics properties
          ....
          TITLE: Advanced
          ...
          Advanced properties
          ...

   * Help: With the Help field it's posible to assign a description to
     the data property preceding it. In this way the user can inspect
     the meaning of the property throught the help context function:
     staying for a while with the mouse on the property or clicking the
     right button.

          QUESTION: X_flag#CB#(1,0)
          VALUE: 1
          HELP: If this flag is set, movement is ...

   * Image: The Image field is useful to insert descriptive pictures on
     the data window. The value of this field is the file name of the
     picture relative to the problem type location.

          IMAGE: omega3.gif

   * Unit field: With this feature it's posible to define and work with
     properties having units. GiD is responsible for the convertion
     between units of the same magnitud.

          ...
          QUESTION: Elastic modulus XX axis:#UNITS#
          VALUE: 2.1E+11Pa
          ...

   * Dependencies: Depending on the value, we can define some behavior
     asociated to 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.

       2.  [TITLESTATE,<Title>,<State>] this argument is optional.
          Titlestate should be used to show or hide book labels. Many
          Titlestate 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,
          HIDE, RESTORE.  All these actions change the value of the
          property with the following diferences: SET disables the
          property, HIDE hides the property and RESTORE brings the
          property to the enabled state.

       4. <Pi> is the name of the property to modify.

       5. <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. The state of a field can be
     `disabled', `enabled' or `hidden'.
     Here is an example,
          ...
          QUESTION: Elastic modulus XX axis
          VALUE: 2.1E+11
          STATE: HIDDEN



File: gid.info,  Node: Template File,  Next: Executing an external program,  Prev: Configuration Files,  Up: Customization

Template File
=============

   Once the user has generated the mesh, 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 has the capability of 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 in 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.

   In case more than one data input file is needed, GiD allows the
creation of more files by means of additional files `***.bas' (note
that while `problem_type_name.bas' creates an data input file named
`project_name.dat', successive files `***.bas', -where `***' can be any
name-, create successive files `project_name-1.dat',
`project_name-2.dat' and so on), the new files follow the same rules
than the ones explained next for `problem_type_name.bas'.

   These files work as interface from the GiD's standard results to the
specific data input for any individual solver module.  This allows to
complete the process of running the analysis (*note Calculate::.)  as
one step more within the system.

   In case of an error in the preparation of the data input files, the
programmer has only to fix the corresponding file
`problem_type_name.bas' or `***.bas' and rerun the example, without
having to leave GiD, recompile or, even more, reassign any data or
remesh.

   This facility is due to the structure of the template files. They
are a group of macros (like an ordinary programming language) that can
be read, without need of any compiler, every time the corresponding
analysis file is to be written. This ensures a fast way to debug
mistakes.

* Menu:

* General description::
* Commands used in the .bas file::
* Detailed example::


File: gid.info,  Node: General description,  Next: Commands used in the .bas file,  Prev: Template File,  Up: Template File

General description
-------------------

   All the rules that apply to the file `NAME.bas' are also valid for
the rest of files with extension `.bas'. Thus, everything in this
section will refer explicitly to the file `NAME.bas'. Any information
written into this file, apart from the so-called commands, 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 the programmer wants to write an asterisk into the file he
should write **. The commands are inserted among the text to be
literally translated. Everyone of these commands returns one (*note
Single value return commands::.) or multiple (*note Multiple values
return commands::.) values obtained from the pre-processing. Other
commands mimic the traditional structures to do loops or conditionals
(*note Specific commands::.). It is also possible to create variables
to manage some data. Comparing it to a classic programming language,
the main differences will be the following:

   * The text is reproduced literally, without printing instructions,
     as it is writing-oriented.

   * There are no indices in the loops. When the program begins a loop,
     it already knows the number of iterations to perform. Furthermore,
     the inner variables of the loop change their values automatically.

     All the commands can be divided into three types:

        - Commands that return one single value. This value can be an
          integer, a real or a string. The value depends on certain
          values that are available to the command and on the position
          of the command, within the loop or after setting some other
          parameters.  These commands can be inserted within the text
          and write their value where it corresponds in it. They can
          also appear inside an expression, what would be the example
          of the conditionals. For this example, the user may specify
          the type of the variable, integer or real, except when using
          `strcmp' or `strcasecmp'. If these commands are within an
          expression, no * should precede the command.

        - Commands that return more than one value. Their use is
          similar to that of the previously indicated commands, except
          for the fact that they cannot be used in other expressions.
          They can return different values, one after the other,
          depending on some values of the project.

        - Commands that perform loops or conditionals, create new
          variables, or define some specifications. The latter include
          condition or type of element chosen and also serve to prevent
          line-feeding. These commands must start at the beginning of
          the line and nothing will be written into the calculations
          file. After the command, in the same line, there can be other
          commands or words to complement the definitions, so, in an end
          of a loop or conditional, after the command the user may
          write what loop or conditional was finished.

   The arguments that appear in a command are written immediately
behind it and inside parenthesis. If there are more than one, they will
be separated by commas. The parenthesis might be put without any
argument inside.  This is useful to write something just behind the
command without any separation in the middle. The arguments can be real
numbers or integers, meaning the word `REAL' or the word `INT' (both in
upper or lowercase) that the value to which it points has to be
considered as real or integer, respectively. Other types of arguments
are sometimes allowed, like the type of element, described by its name,
in the command `*set elem', or a chain of characters inserted between
double quotes " for the C-instructions `strcmp' and `strcasecmp'. It is
also possible, sometimes, to write the field's name instead of its
ordering number.

   EXAMPLE:

   Next it's showed a piece of what it could be a `.bas' file. There
are two commands (*nelem and *npoint) which return the total number of
elements and nodes of a project.
     %%%% Problem Size %%%%
     Number of Elements & Nodes:
     *nelem *npoin

   This `.bas' file will be converted into a `project_name.dat' file by
GiD. The contents of the `project_name.dat' file could be something
like this:

     %%%% Problem Size %%%%
     Number of Elements & Nodes:
     5379 4678

   (being 5379 the number of elements of the project, and 4678 the
number of nodes)


File: gid.info,  Node: Commands used in the .bas file,  Next: Detailed example,  Prev: General description,  Up: Template File

Commands used in the .bas file
------------------------------

* Menu:
* Menu:

* Single value return commands::
* Multiple values return commands::
* Specific commands::


File: gid.info,  Node: Single value return commands,  Next: Multiple values return commands,  Prev: Commands used in the .bas file,  Up: Commands used in the .bas file

Single value return commands
............................

   When writing a command, it is generally (if not explicitly mentioned)
independent of the letters case, even a mixture of uppercase or
lowercase would not affect the results.

   * *npoin, *ndime, *nnode, *nelem, *nmats. They return,
     respectively, the number of points, the dimension of the project
     being considered, the number of nodes of the element with the
     highest number, the number of elements and the number of materials.
     All of them are considered as integers and do not carry arguments
     (see `*format', `*intformat'), except `*nelem', which can bring
     different types of elements.  These elements are `Linear',
     `Triangle', `Quadrilateral', `Tetrahedra', `Hexahedra', depending
     on the number of edges of the element and `All', that comprises
     all the possible types. The command `*nmats' returns the number of
     materials effectively assigned to an entity, not all the defined
     ones.

   * *GenData. It must carry an argument of integer type that specifies
     the number of the field to be printed. This number is the order of
     the field inside the general data list. This must be one of the
     values that are fixed for all the problem, independently of the
     interval (*note Problem and intervals data file::.).  The field's
     name can also be the argument, instead, or even an abbreviation of
     it.

     The arguments `REAL' or `INT' to express the type of number for
     the field are also available (see `*format', `*intformat',
     `*realformat', `*if'). If they are not specified, the program will
     print a character string. It is mandatory to write one of them
     within an expression, except for `strcmp' and `strcasecmp'. The
     numeration must start with number 1.

   * *IntvData. The only difference with the previous one is that the
     field must be one of those fields varying with the interval (*note
     Problem and intervals data file::.).  This command must be within
     a loop over intervals (see `*loop') and the program will
     automatically update the suitable value for each iteration.

   * *MatProp. The only difference with the previous ones is that it
     must be within a loop over the materials (see `*loop'). It returns
     the property whose field's number or name is defined by its
     argument. It's recommended the use of names instead of field
     numbers.
     NOTE: If argument is 0, it returns the material's name.

     *Caution:* If there are materials with different number of fields,
     the user must ensure not to print non-existent fields, using
     conditionals.

   * *Cond. The same previous remarks apply here, although now the user
     must notify with the command `*set' (see `*set') which is the
     condition being processed. It can be within a loop (see `*loop')
     over the different intervals in case that the conditions vary for
     each interval.

   * *ElemsNum: returns the element's number.
     *NodesNum: returns the node's number.
     *MatNum: returns the material's number.
     *ElemsMat: returns the number of the material assigned to the
     element.
     All of this commands must be within a proper loop (see `*loop')
     and change automatically for each iteration. They are considered as
     integers and cannot carry any argument. The number of materials
     will be reordered numerically, to begin from number 1 and will
     increase up to the number of materials assigned to any entity.
   * *LayerNum: returns the layer's number.
     *LayerName: returns the layer's name.
     *LayerColorRGB: returns the layer's color in RGB (three integer
     numbers between 0 and 256). If parameter `(1)', `(2)' or `(3)' is
     specified, the command returns the only the value of one color.
     RED is 1, GREEN is 2 and BLUE is 3.
     Commands *LayerName, *LayerNum and *LayerColorRGB must be inside a
     loop over layers; you cannot use this commands in a loop over
     nodes or elements.
     Example:
          *loop layers
          *LayerName *LayerColorRGB
          *Operation(LayerColorRGB(1)/255.0) *Operation(LayerColorRGB(2)/255.0) *Operation(LayerColorRGB(3)/255.0)
          *end layers

   * *NodesLayerNum: returns the layer's number. Must be used in a loop
     over nodes.
     *NodesLayerName: returns the layer's name. Must be used in a loop
     over nodes.
     *ElemsLayerNum: returns the layer's number. Must be used in a loop
     over elems.
     *ElemsLayerName: returns the layer's name. Must be used in a loop
     over elems.
   * *CondNumEntities. The user must have previously selected a
     condition (see `*set'). It returns the number of entities that
     have a condition assigned over them.

   * *LoopVar. This command must be inside a loop and returns, as an
     integer, what is considered to be the internal variable of the
     loop. This variable takes the value 1 in the first iteration and
     increases a unit for each new iteration.

     The parameter `elems,nodes,materials,intervals', used as argument
     for the corresponding loop, allows the program know which one is
     being processed.  Otherwise, if there are nested loops, the
     program takes the value of the inner loop.

   * *Operation. It returns the result of an arithmetical expression
     what should be written inside parenthesis just immediately behind
     the command. This operation must be defined in C-format and can
     contain any of the commands that return one single value. The user
     can force the return of an integer or a real by means of the
     mentioned parameters `INT' or `REAL'. Otherwise, GiD returns the
     type according to the result.
     The valid C functions that can be used are:
        { } `+,-,*,/,(,),=,<,>,!,&,|, numbers and variables'

        { } `sin'

        { } `cos'

        { } `tan'

        { } `asin'

        { } `acos'

        { } `atan'

        { } `atan2'

        { } `exp'

        { } `fabs'

        { } `abs'

        { } `pow'

        { } `sqrt'

        { } `strcmp'

        { } `strcasecmp'

     The following are valid examples of operations:

          *operation(4*elemsnum+1)
          *operation(8*(loopvar-1)+1)

     *Note:* There cannot be blank spaces between the commands and the
     parenthesis that include the parameters.

     *Note:* Commands inside `*operation' do not need to put * at the
     beginning.

   * *LocalAxesNum. It returns the identification name of the local
     axes system, either when the loop is over the nodes or when it is
     over the elements, under a referenced condition.

   * *nlocalaxes. It returns the number of the defined local axes
     system.

   * *IsQuadratic. It returns the value 1 when the elements are
     quadratic or 0 when they are not.

   * *time. It returns the number of seconds elapsed since midnight.

   * *clock. It returns the number of clock ticks (aprox. milliseconds)
     of elapsed processor time.
     EXAMPLE:
          *set var t0=clock
          *loop nodes
            *nodescoord
          *end nodes
          *set var t1=clock
          ellapsed time=*operation((t1-t0)/1000.0) seconds



File: gid.info,  Node: Multiple values return commands,  Next: Specific commands,  Prev: Single value return commands,  Up: Commands used in the .bas file

Multiple values return commands
...............................

   These commands return more than one value in a prescribed order,
writing them one behind another. All of them, but `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.  `LocalAxesDef' or the rest of the
commands without the numerical argument cannot be used inside
expressions. Following, it is displayed a list of the commands with the
appropriate description:

   * *NodesCoord. This command writes the node's coordinates. It must be
     inside a loop (see `*loop') over the nodes or elements. The
     coordinates are considered as real numbers (see `*realformat' and
     `*format').  It will write two or three coordinates according to
     the problem's dimension (see `*Ndime'). If *NodesCoord receives an
     argument inside a loop of nodes, this argument indicates which
     coordinate x, y or z must be written:
     Inside a loop of nodes:
     `*NodesCoord    ' writes three or two coordinates depending on the
     problem's dimension.
     `*NodesCoord(1) ' writes the x coordinate of the actual node of
     the loop.
     `*NodesCoord(2) ' writes the y coordinate of the actual node of
     the loop.
     `*NodesCoord(3) ' writes the z coordinate of the actual node of
     the loop.
     If the argument `real' is given, the coordinates will be treated
     as a real number.
     Example: using *NodesCoord inside a loop of nodes
          Coordinates:
            Node        X                Y
          *set elems(all)
          *loop nodes
          *format "%5i%14.5e%14.5e"
          *NodesNum *NodesCoord(1,real) *NodesCoord(2,real)
          *end nodes
     This command effects a rundown of all the nodes of the mesh,
     listing their identifiers and coordinates (x and y coordinates).

     The contents of the `project_name.dat' file could be something
     like this:
          Coordinates:
            Node        X                Y
              1  -1.28571e+001  -1.92931e+000
              2  -1.15611e+001  -2.13549e+000
              3  -1.26436e+001  -5.44919e-001
              4  -1.06161e+001  -1.08545e+000
              5  -1.12029e+001   9.22373e-002
              ...

     *NodesCoord can also be used inside a loop of elements. In this
     case, it needs an additional argument that gives the local number
     of the node inside the element. After this argument it's also
     possible to give which coordinate has to be written x, y or z.
     Inside a loop of elements:
     `*NodesCoord(4)   ' writes the coordinates of the 4th node of the
     actual element of the loop.
     `*NodesCoord(5,1) ' writes the x coordinate of the 5th node of the
     actual element of the loop.
     `*NodesCoord(5,2) ' writes the y coordinate of the 5th node of the
     actual element of the loop.
     `*NodesCoord(5,3) ' writes the z coordinate of the 5th node of the
     actual element of the loop.
   * *ElemsConec. This command writes the element's connectivities,
     i.e., the list of the nodes that belong to the element, keeping
     the proper sense for each case (anti-clockwise sense in 2D and
     depending on the standards in 3D).  For shells, the user must
     define the sense. However, this command accepts the argument
     `swap' and this implies that the ordering of the nodes in
     quadratic elements will be inverted. The connectivities are
     considered as integer numbers (see `*intformat' and `*format').

     *Note:* In the first versions of GiD, the optional parameter of the
     last command explained was `invert' instead of the present
     (`swap'). It was changed due to technical reasons. If you have an
     old `.bas' file prior to this specification, which contains this
     command in its previous form, when you try to export the
     calculation file, you will be warned about this change of use. Be
     aware that the output file will not be created as the user expects.

   * *GlobalNodes. This command returns the nodes that belong to an
     element's face where a condition has been defined (on the loop
     over the elements).  The sense is the same that the sense of the
     element's connectivities. The returned values are considered as
     integer numbers (see `*intformat' and `*format').
     So, the local numeration of the faces is:

          Triangle:       12  23  31
          Quadrilateral:  12  23  34  41
          Tetrahedra:     123 243 341 421
          Hexahedra:      1234  1562  2673  3784  1485  5876

   * *LocalNodes. The only difference with the previous one is that the
     returned value is the local node's numbering for the corresponding
     element (between 1 and `nnode)'.

   * *ElemsNnode. This command returns the number of nodes of the
     current element. (valid only inside a loop over elements)
     NOTE: This command is only available in GiD version 6.2.0b or
     newer.  Example:
          *loop elems
            *ElemsNnode
          *end elems

   * *LocalAxesDef.  This command returns the nine numbers that define
     the transformation matrix of a vector from the local axes system
     to the global one.  Example:
          *loop localaxes
          *format "%10.4lg %* %* %10.4lg %* %* %10.4lg %* %*"
          x'=*LocalAxesDef
          *format "%* %10.4lg %* %* %10.4lg %* %* %10.4lg %*"
          y'=*LocalAxesDef
          *format "%* %* %10.4lg %* %* %10.4lg %* %* %10.4lg"
          z'=*LocalAxesDef
          *end localaxes

     NOTE: when `%*' is used in the `*format' command, the argument of
     that position is not printed.
   * *LocalAxesDef(EulerAngles). Last command with option `EulerAngles',
     returns three numbers that are the 3 Euler angles that define a
     local axes system.
   * *LocalAxesDefCenter. This command returns the origin of
     coordinates of the local axes defined by the user. The "Automatic"
     local axes do not have a center, so, the point (0,0,0) is
     returned. The index of the coordinate (from 1 to 3) can optionally
     be given to `LocalAxesDefCenter' to get the x, y or z value.

     Example:
          *LocalAxesDefCenter
          *LocalAxesDefCenter(1) *LocalAxesDefCenter(2) *LocalAxesDefCenter(3)


