The keywords of this group enable the definition of the problem, and the dimensioning (memory allocation) of the computation.
These keywords are described in detail in the following pages.
The title, composed of a maximum of 72 characters, is the first card of the data set and is compulsory.
The contents of this data card is printed at the top of each page edited by EUROPLEXUS together with the date of the run.
These keywords are used to obtain an echo on the terminal or console window of the input data being precessed and to check up the syntactical correctness and the coherence of the data.
< $[ "ECHO" ; "NOEC" ]$ >
The "ECHO" optional keyword produces an echo on the screen or terminal of the input file directives as they are being processed. If the input file is very long, this may be annoying. By default no echo is produced. See also the option OPTI ECHO, Page H.50, which may be used at any point of the input file after the dimensioning.
The "NOEC" optional keyword disables the echo on the screen or terminal of the input file directives as they are being processed. By default no echo is produced. See also the option OPTI NOEC, Page H.50, which may be used at any point of the input file after the dimensioning.
The CONV directive can be used to execute EUROPLEXUS interactively, i.e. in the foreground (as opposed to the default batch or background execution). In this execution mode, the user pilots the advancement of the computation, and the results at selected time instants can be either visualized on graphic screens of various types (on-screen rendering), or be stored in graphic files of various types (off-screen rendering), including animation files.
< "CONV" $[ "TEKT" ; "WIN" ; "PS" ; "MIF" ]$ >
When interactive execution is chosen, EUROPLEXUS reads the input data-set as usual, performs step 0 to initialise the computation, then prompts the user for commands from the keyboard with the phrase: COMMANDE ?.
The user can then issue various commands and subcommands typically from the keyboard in order to pilot the computation. For example, he can ask the program to perform a certain number of steps, then to pause again for further commands. Each time the calculation is paused, the current computational model can be visualized (e.g. by means of the built-in OpenGL-based visualization module) and information concerning the computation (time step, CPU time, etc.) can be printed. Furthermore, the current time step can be varied by the user.
As an alternative to typing commands by hand from the keyboard, such commands may be included in the regular EUROPLEXUS input file by enclosing them into a special directive PLAY ... ENDPLAY as described in Section 13.6 (Page I.24) and in Section 14.7 (Page ED.140).
All EUROPLEXUS interactive commands are described in detail in Section 15 (Group O).
This Section gives some information about the management of files related to the EUROPLEXUS program.
The code tries whenever possible to use default values both for the file names that it needs during the calculation, and for the associated logical unit numbers.
The idea is that logical unit numbers (a concept specific only to FORTRAN) are irrelevant for the user and should be totally transparent to him or her. What does matter for users is file names.
In many cases the code helps users by providing default values for such names (the behaviour may depend on the platform, though, see below). Of course, users are free to choose file names (and even unit numbers) if for any reason they find such defaults inconvenient.
Under the MS-Windows platform default file names are built automatically by the code by using the base name of the (main) input file used in the run.
For example, suppose that the main input file is called
test01.epx and resides on a directory
D:\Work. The user
may launch the program for example by opening a console
window on the directory
D:\Work (i.e., such that
is the current directory) and by typing a command such as:
epx_bench -l test01
The actual command may vary depending on the implementation.
The code interprets the name passed on the command line (after removing
any options such as the
-l above) as the name of the main input file.
It removes the extension
.epx from this name, if present, and uses
the resulting string as the base name for default file names.
Thus, the user may give a full file name, complete with its path,
Suppose now that for run
test01 the user needs to read a CASTEM 2000
mesh and wants to produce results for ALICE TEMPS and CASTEM 2000.
The first task may be accomplished by the CAST directive (see page A.30).
If the mesh file is formatted, and the global (main) mesh object
model, this directive may take any of the following
1. CAST FORM `test01.msh' model 2. CAST FORM 9 model 3. CAST FORM model
In the first form, the file name containing the mesh is given explicitly. The code associates this name to the default unit number, which for CASTEM mesh reading is number 9.
In the second form, the unit number is given explicitly. The code
uses the given number as unit number and opens a file without
specifying its name. This results in different behaviour
depending on the platform. Under MS-Windows, a file
In the third form neither the name nor the unit number are
specified. The code uses the default file name (
in this case) and the default unit number (9).
It is clear that, whenever possible, the third form is preferable. This requires, however, that the mesh file name matches the main input file name (and is on the same directory).
When either of these conditions is impractical, the first form should be used by preference (name chosen by the user, unit number chosen by default by the code).
The second syntax is obsolete and should be avoided in new inputs.
The task of producing results files may be accomplished similarly, by the ECRI directive (see page G.70). For example, for the ALICE TEMPS output, this directive may take any of the following forms:
1. ECRI FICH ALIC TEMP 'test01.alt' /CTIME/ . . . 2. ECRI FICH ALIC TEMP 11 /CTIME/ . . . 3. ECRI FICH ALIC TEMP /CTIME/ . . .
Under the Unix platform(s), the same concepts apply as seen above.
Let us assume for example that the main input file is called
test01.epx and resides on a directory
The user may run the program starting from his work directory
My_dir) by the command:
The mesh file will be sought in this directory under the name
test01.msh. If some other input files are required, they will
also be sought in this directory, under the same name but
a different extension.
The same rule applies to output files, in particular to the listing file.
However, for reasons related to efficient exploitation of disk space, output files may of course be directed to special directories. It is therefore recommended to contact your system administrator to learn about local disk space policies.
Under the MS-Windows platform, there exist other ways of launching the program, alternative to the one (command line) assumed in the above example.
For example, a user might double click on the EUROPLEXUS executable
or on an icon (shortcut) to this executable, or on the input file
test01.epx (provided file association is used), etc.
Whenever a file name is not directly available (like in the first two alternative methods listed above), the program prompts interactively the user for such a name. The behaviour is thereafter identical to the case of command-line execution.
Currently, default file names are available for the following directives:
This directive allows to open a file directly from the input data, by specifying its logical unit number and its name.
It may be used whenever either the user wants to override a file choice made by default by the code (example: a very long calculation requires its results file to be written to a remote disk, due to space problems), or to force opening of a unit that is otherwise not opened by the code.
Note, however, that including this directive in input files generally renders them not portable across different platforms or even different machines belonging to the same platform. In fact, absolute (full) file names are usually required.
For this reason, it is preferable to use the short file name syntax (or even the default name syntax) described in the previous sections whenever possible.
"OPNF" < "FORMAT" ; "WXDR" ; "RXDR" > nfic 'nomfic'
It is forbidden to open explicitly the logical unit numbers 0, 5, 6 and 7, that are reserved in most operating systems. Other unit numbers reserved by EUROPLEXUS are 15, 16 and from 91 onwards.
The way of coding the file name depends upon the operating system:
For other operating systems, please contact your system administrator.
This directive allows to define a directory for output files.
Like for EXPLICIT FILE OPENING, the rules for the name of the given directory may vary from one platform to another.
"OPNF" "DRST" |[ 'nomdir' ; "PWD0" ]|
In the case of an UNIX system, the defined directory is an absolute path. In the case of a WINDOWS system, the directory is given as a relative path.
In both cases, if given directory does not exist, it is created.
A.30 - Feb13
1/ To define the mesh type that will be used:
2/ To define the general type of computation:
3/ To define some general options about the form of printed results (useful to reduce the size of the output listing in extremely large test cases)
$[ $[ "GIBI" ; "CASTEM" ]$ <$[ "FORM" ; "XDR" ; "BINA" ]$> <$[ ndis ; 'file_name' ]$> 'nomobjet' ; "IDEA" <$[ ndidea ; 'file_name' ]$> < "REWR" > < "MAPP" > ; "MEDL" 'file_name' ; "KFIL" 'file_name' ; ]$ |[ "DPLA" ; "CPLA" ; "AXIS" <"HOLE" hole> ; "TRID" ]| < $[ "LAGR" ; "EULE" ; "ALE" ]$ > < "NAVIER" > < "HOMO" nhtube > < "MBETON" nssc > < "FRQR" nfrqr > < "SPCO" sphcon > < "LAGC" > < "MBACON" < "POST" > > < "SAUVEGARDE" ... > < "REPRISE" ... > < "ADDF" < "NAVS" > < "TEMP" > < "TURB" > > < "MECA" > < "MEDE" > < "EROS" <ldam> <CROI> <LIMI> > < "RISK" < "PROB" |[ "FERR" ; "YETP" ]| > < "LUNG" |[ "BAKE" ; "LEES" ]| > < "SPLI" >
< "SCLM" ... > < "BMPI" > < "ADAP" "MLVL" rlvl < ( 'nomelm' rlel ) > > < "CFVN" >
The “probit” functions for risk estimation are taken from:
The CASTEM directive is meant to read data produced by CAST3M and saved by the directive "SAUV". It will read also objects of type ’champoint’ explicitly stored, together with the mesh, by CAST3M.
On the other hand, the GIBI directive is meant to read only mesh objects (maillage) produced by CAST3M and saved by the directive "SORT". No champoints may be stored by CAST3M with this directive, therefore they may not be transmitted to EUROPLEXUS.
The syntax in CAST3M is:
Assume we have an object
'mymesh' of type
write on the file
'myfile.msh' on the current directory.
. . . OPTI SORT 'myfile.msh' ; SORT mymesh ; . . .
Assume we have an object
'mymesh' of type
and an object
'mychampnt' of type
'champoin' to write
on the file
'myfile.msh' on the current directory.
. . . OPTI SAUV FORM 'myfile.msh' ; SAUV FORM mymesh mychampnt ;
. . . OPTI SAUV 'myfile.msh' ; SAUV mymesh mychampnt ;
. . . OPTI SAUV BINA 'myfile.msh' ; SAUV BINA mymesh mychampnt ;
Note that, if the data have been produced by CAST3M in formatted mode, then the keyword FORM may optionally be used in the EUROPLEXUS directive, for clarity, but it is not necessary, since this is the default reading mode for this directive.
On the other hand, if the data have been produced by CASTEM in "XDR" (rep. "BINA") mode, then the keyword XDR (resp. BINA) is mandatory in the EUROPLEXUS directive.
Note also, the XDR mode is the default mode for CAST3M output "SAUVER" file.
In the case of the "GIBI" directive, the mesh file is always formatted.
If neither the keyword "GIBI" nor "CASTEM" appear, the program assumes that the mesh is directly given in the main input file under the form of a list of coordinate values, and as many lists of node index (topology) values as there are element zones. This format is also known as the ‘COCO’ type format.
This form allows also to use meshes issued from mesh generators other than CASTEM-GIBI or even, in case for example the mesh is quite simple, to enter this data directly, or to generate them by an independent software. For more information, consult the ’GEOM’ directive.
The type of problem directive must be specified and contain at least one keyword (at least 2 for non-Lagrangian cases), for example:
The various options are mutually incompatible.
When the IDEA directive is used, the program reads the mesh from an I-DEAS ‘universal file’. This file may contain other information besides the mesh, but the extra information is ignored.
The program interprets the following information: 1) nodal coordinates (dataset 781 or 2411) ; 2) element topology (dataset 780 or 2412); 3) permanent groups (dataset 752 or 2429 or 2430). Permanent groups are identified by a name, which can then be used in the EUROPLEXUS input file (like in the case of CASTEM mesh) to identify the corresponding list of nodes or elements.
Note that normally I-DEAS universal files do not have consecutive node or element numbers, while EUROPLEXUS requires consecutive numbering (and starting from 1). In order to solve this problem, use the optional REWR directive: the code reads the universal file (use extension ‘.unv’), re-orders the mesh numbering and writes the result in a new universal file (same name but with the characters ’new’ appended). Nodes are re-ordered simply by eliminating ‘holes’ in the numbering. For the elements, however, a subdivision into homogeneous ‘blocks’ of the same element type, material and physical properties (geometrical complements) is performed. A summary of the resulting blocks is printed on the listing.
Elements are re-ordered subdividing them into homogeneous ‘blocks’ of the same element type, material and physical properties (geometrical complements). This permits the mapping of the I-DEAS element library onto the EUROPLEXUS one, for the relation between I-DEAS and EUROPLEXUS element libraries is not unique. The ordering criterion followed by the procedure is: [material property number] - [element type number] - [physical property number]; as an example, if some elements have to be declared as the last ones (i.e. CLxx elements when present), they must be associated to the highest material number in the I-DEAS mesh.
A list of the resulting blocks is printed on the listing, containing the number of elements, the element type in I-DEAS mesh and a list of possible choices for the corresponding EUROPLEXUS element type; these informations are useful in order to set up the declaration of the geometry in the EUROPLEXUS input file (see 5.3).
The MAPP optional directive may be used in order to stop the code right after writing the re-ordered universal file.
Example 1: EUROPLEXUS input file:
$------------------------------------- Example of use of IDEAS universal file: 1. file re-writing IDEA 'myfile.unv' REWR MAPP DIME TERM FIN
This input reads in universal file ‘myfile.unv’, re-orders the mesh and produces a new universal file ‘myfile.unvnew’.
It is important to note that in order to post-process the EUROPLEXUS results with I-DEAS, use should be made of the reordered universal file (myfile.unvnew in the above example).
Example 2: EUROPLEXUS input file:
$------------------------------------- Example of use of IDEAS universal file: 2. actual computation IDEA 'myfile.unvnew' DIME ... (problem definition, using 'permanent group' names) FIN
In this second example, the geometry is read from the re-ordered universal file, and in any successive input directive the names of permanent groups may be used to define element or node lists. The syntax is the same as with CAST3M objects.
When the MEDL directive is used, the program reads the mesh from a MED file. This file may contain other information besides the mesh. If the file comes from EPX or Code_Aster, displacements, velocities, strains, stresses and internal variables could be read and used for the initialization. (See description on page GBE_0180). Other extra informations are ignored.
From the elements families and from the nodes families the program reconstructs the elements groups and the nodes groups. Groups are identified by a name, which can then be used in the EUROPLEXUS input file (like in the case of CASTEM mesh) to identify the corresponding list of nodes or elements. The elements groups described in a MED file are homogeneous ‘blocks’ of the same geometric support.
Note that the MED elements numbers are not necessarily the EUROPLEXUS elements numbers.
A summary of the resulting blocks is printed on the listing.
For an axisymmetric computation, the program considers a sector of ONE RADIAN. Therefore, all the forces, added masses, etc. must be defined correspondingly.
This has to be taken into account in particular when defining the mass associated to a material point: the “true” mass shall be divided by 2π.
If the whole force is Ftot, the force to be introduced in EUROPLEXUS is:
EUROPLEXUS includes a module for the modeling of advection-diffusion phenomena. This module stems from the TRAFLU-2D and TRAFLU-3D codes developed at JRC Ispra in the late eighties [53, 54].
The module is activated by using elements of type ADQ4 (in 2D) or ADC8 (in 3D), the ADFM material, specific generalised “loads” (see page F.320) and initial conditions (see page E.85), and specific options (see page H.70). Here is a synthetic description of these models, borrowed from .
The model uses a quasi-explicit finite element algorithm for the solution of the basic equations describing combined conductive and convective transfer of heat in a liquid. The presence of enclosing solid (rigid) structures is accounted for.
The governing equations in the fluid region are the incompressible Navier-Stokes equations and the thermal energy equation. These equations are treated in an Eulerian frame of reference and they are expressed in terms of primitive variables: velocity, pressure and temperature.
The flow is assumed to be laminar and the fluid Newtonian and incompressible within the Boussinesq approximation. Either the velocity components or the total surface stress are specified as boundary conditions for the Navier-Stokes equations.
The governing equation in the solid is the transient heat conduction equation. Boundary conditions are of prescribed temperature, imposed normal heat flux and heat transfer by convection or radiation.
Spatial discretization is achieved by means of four-node quadrilateral elements in 2D (ADQ4) or eight-node hexahedral elements in 3D (ADC8) with multi-linear velocity and temperature fields. The pressure is assumed uniform over each fluid element.
A fractional step method is employed for time integration of the Navier-Stokes and thermal energy equations. This consists of three distinct steps dealing, respectively, with the advective terms, the viscous/diffusion terms and the pressure/incompressibility terms.
A second-order explicit Taylor-Galerkin method is used in the advection step, where the mass matrix is retained in its consistent form to improve phase accuracy.
A first-order explicit Euler method is used in the viscous-diffusion phase. Here the mass matrix is put into diagonal form.
Finally, a first-order implicit method is used in the pressure phase for the momentum equations. The pressure field itself is obtained as solution of a linear algebraic system arising from the discrete form of the incompressibility condition.
To define the type of printed output listing. If nothing is specified, in extremely large model computations the standard listing could be very large. Therefore, it may be useful to selectively reduce the printed information via the following directives.
< $ "LIST" | "COOR" ; "ELEM" ; "GIBI" ; "GRIL" ; "EPAI" ; "NORM" ; "NONE" | "TERM" $ >
By default, i.e. in the absence of the LIST directive, all the above quantities are printed out in the normal way. When the LIST directive is encountered, all the above printouts are inhibited, i.e. the effect is the same as with LIST NONE. Any of the keywords COOR ... NORM may then be used to re-activate the printing of selected quantities. In this case, however, printing of sequences of integer numbers occurs in a “compact” way, in the sense that any sequence of four or more consecutive numbers n1, n2, ..., nn is listed simply as ’n1 to nn’. In many cases this allows important savings in the quantity of output data.
For example, the directive:
LIST NONE ELEM EPAI TERM
would print only the mesh topology and element thicknesses.
To obtain the most compact listing, use LIST NONE TERM.
Another way of obtaining a compact listing is the option OPTI NOPR, see Page H.50. However, that directive does not allow selective printout.
Optional global options to set for MPI calculations:
< "SCLM" <"DTUN"> <"PMET"> <"ROB"> <"CINI"> <"WFIL" <ndwfil>> <"DACT" /LECDDL/> <"DPRE" ipre> <"IOPT" iopt> > < "BMPI">
Keywords to be used with SCLM option are very close to the ones dedicated to the STRUCTURE directive with automatic domain decomposition activated (keyword AUTO, see page I.15). Indeed, to provide an optimized memory distribution, the domain decomposition has to be defined and performed before the global data structure is built and initialized, which is not the case when using the STRUCTURE directive just before launching the calculation. Only automatic domain decomposition can be defined this way. See comments on page I.15 for a complete description of keywords DTUN, PMET, ROB, CINI, WFIL, DACT, DPRE.
When activating memory optimization for MPI calculations with SCLM option, the STRUCTURE directive must not be used, since domain decomposition has already been defined.
IOPT keyword is used to define the level of memory optimization: the more agressive the optimization is, the more restrictions upon output and qualification there are.
TIP: The right way to deal with restrictions imposed by SCLM option is to write an ALICE file during the parallel calculation within a series of time-steps of interest and then to generate the desired output files and perform the desired qualifications from this file.
Allocation of memory for the problem variables.
The dimensioning of variables data is specified by keywords, which enable the user to reserve for a given problem only the memory that will be really necessary to perform the computation. All the dimensions are maximum values, their value by default is 0 (unless a different value is specified in the description).
On the following pages, the keywords have been classified according to the data they affect. Actually, they can be provided in any order. These keywords together form the directive "DIMENSION".
These dimensions concern the geometry (elements) and, in ALE computations, the motion of grid nodes.
The overall syntax is as follows:
< NPOI np > < NDDL nd > < "typ1" n1 "typ2" n2 ... > < ADAP NPOI np <NIND ni> <NVFI nvfi> <NTHR nthr> <NPIN npin> "typ1" n1 "typ2" n2 ... ENDA > < DECO NPOI np ENDD > < NALE nale > < NBLE nble > < NGPZ mxngpz > < ME1D me1d >
< "NPOI" np > < "NDDL" nd >
Normally EUROPLEXUS detects automatically the exact number of nodes (and the number of degrees of freedom), the exact number of each element types required, from the input file or from the associated mesh file. Therefore, the directives NPOI, NDDL and TYPi are usually not necessary.
These directives are needed only in special cases, whereby EUROPLEXUS has to create additional nodes (not specified in the input nor in the associated mesh file) after the reading of the geometry: for example a pipeline circuit with a bifurcation, a rigid body, or in case of remeshing.
The number of the different elements that will be used in the problem is specified (if necessary).
| "typ1" n1 "typ2" n2 ..... |
Normally EUROPLEXUS detects automatically the exact number of each element type required, from the input file or from the associated mesh file. Therefore, theses directives are usually not necessary. These directives are needed only in special cases, whereby EUROPLEXUS has to create additional elements (not specified in the input nor in the associated mesh file) after the reading of the geometry: for example a pipeline circuit with a bifurcation, a rigid body, in case of remeshing, or in case of flying debris.
The various elements are described on page INT 80.
If you use 1-D elements (except ED1D), the directives:
are mandatory in the definition of the problem type (page A.30).
This optional sub-directive allows to set the dimensions for the automatic mesh refinement during a computation, as required e.g. in adaptivity. The directive syntax is similar to that described in the previous pages for the “base” mesh. The user must define the maximum number of nodes, of degrees of freedom, and of elements (for each element type which can be refined) that are allowed to be “created” during the transient calculation. This is referred to as the “extension” zone as opposed to the “base” zone containing the base (normal) mesh. The optional directive must be terminated by the keyword ENDA.
< ADAP NPOI np <NIND ni> <NVFI nvfi> <NTHR nthr> <NPIN npin> "typ1" n1 "typ2" n2 ... ENDA >
The number of degrees of freedom in the extension memory zone (i.e. the dofs relative to the adaptive nodes) is automatically computed by the code as the number of nodes in the extension zone (np) multiplied by the space dimension (2D or 3D). This implies of course that only elements whose nodes do not have any rotational dofs can be used in adaptivity, for the moment.
This optional sub-directive allows to set the maximum number of created nodes during a computation as required for this numerical method (Automatic Separation of the Elements). Automatic separation of the elements is only available for CUB8 elements affected by the BOIS (wood) material. More explanations can be found in . The optional directive must be terminated by the keyword ENDD.
< DECO NPOI np ENDD >
For the moment this method (Automatic Separation of the Elements) is only available for CUB8 elements affected by the BOIS (wood) material.
< "NALE" nal > < "NBLE" nbl >
< "NGPZ" mxngpz >
< "ME1D" mead >
Dimensions relative to the materials used.
< "LMAS" lmas > < "ECRO" lecr > < "PYRO" mxpyro >
Normally EUROPLEXUS detects automatically the exact length of the ECR vector associated to materials, from the input file. Therefore, the directive ECRO is usually not necessary. This directive is needed only in special cases, whereby EUROPLEXUS has to create additional elements (not specified in the input nor in the associated mesh file) after the reading of the geometry: for example a pipeline circuit with a bifurcation, a rigid body, or in case of remeshing.
It is compulsory to enter the size of the consistent mass matrix, when the computation includes the material "MHOM".
Dimensions relative to the couplings.
< "MXLI" maxlie > < "LNOD" maxnod> < "LCOF" maxcof > < "GLIS" nslid nemax > < "JONC" njonc > < "NPEF" nmpef "NPTS" nomax > < "SOLI" nsol > < "MECA" nmeca > < "FSSA" mxfssa > < "FSSL" mxfssl > < "FSSF" mxfssf > < "NBJE" nbjeux > < "VCON" mxvcon >
Normally EUROPLEXUS detects automatically the exact number of LIAISONS parameters required, from the input file. Therefore, the directives MXLI, LNOD, LCOF, ... are usually not necessary. These directives are needed only in special cases, whereby EUROPLEXUS has to create additional nodes or additional elements.
Dimensions relative to printout and storage keywords.
< "MTTI" mttime > < "MNTI" mntime > < "NFRO" nfront > < "NPFR" npfron > < "NEPE" nepedi >
Dimensions relative to the calculation run.
< "TTHI" mtthis >
Dimensions relative to advection-diffusion problems as declared by keyword "ADDF" above in this section.
< "ELSN" mxelsn "BWDT" mxbwdt "TPOI" mxtpoi "ELGR" mxelgr "CVEL" mxcvel "GRPS" mxgrps >
The word "TERM" marks the end of the dimension, it must appear.