I.10
The following directives define, run, verify (qualify) and stop the transient
computation which has been defined with all directives
given so far.
Furthermore, by means of a so-called “ED1D input deck” it
is possible to perform
a coupled 1-D/multi-D calculation, see also pages INT.80 and I.23.
< "STRUCTURES" . . . > < "INTERFACES" . . . > < "XFEM" ... > "CALCUL" . . . < "ED1D" {Eurdyn-1D input deck} "ED1D END" > < "PLAY" {interactive commands} "ENDPLAY" > < "QUALIFICATION" . . . > $ "SUITE" ; "FIN" $
These instructions are described in detail on the following pages.
I.15
This directive enables the use of the domain decomposition method that has been recently implemented in EUROPLEXUS. Therefore, only some of the elements are currently available, see the list below.
This directive is optional. However, when used it
MUST APPEAR BEFORE the “CALCUL” directive.
"STRUCTURE" <"DTUN"> |[ "AUTO" <"PMET"> <"ROB"> <"CINI"> ... ... <"WFIL" <ndwfil>> <"DACT" /LECDDL/> <"DPRE" ipre> ; nbdo * ( |[ "DOMA" /LECT/ <"IDEN" ndom> <$["DTMX" dtmx ; "DTFX" dtfx]$> ; "MODA" /LECT/ <"IDEN" ndom> ... ... "FICHIER_VIBRATIONS" <FORMAT> <ndfich> ... ... <"POST_TRAITEMENT" $["TOUS" ; "CHPO"]$ > ... ... <"NOFO"> ]| ) ]|
The elements currently available for calculations with domain decomposition are:
in 2D : COQU, TRIA, BARR, MEMB, CL2D, CAR1, CAR4, COQC, Q92 , Q93 , COQI, ED01, CL2S, CL22, Q41L, Q42L, FUN2, T3VF, Q4VF in 3D : CUBE, COQ4, POUT, CL3D, BR3D, PR6, TETR, PRIS, PMAT, CL3T, CUB8, APPU, MECA, T3GS, FL38, DKT3, SHB8, FUN3, Q4G4, CL3Q, Q4GR, Q4GS, ASHB, T3MC, TEVF, PYVF, PRVF, CUVF
The code initially performs the following checks:
In a calculation by domain decomposition, the following terminology
applies:
It is important to note that users normally have limited control over time
cycles, which are managed internally by the code according to
the characteristics of each subdomain. All time-related quantities,
such as for example those of the CALCUL directive (see page I.20)
or the chosen instants for data printing and storage (see the
ECRITURE directive, page G.70),
concern time steps (i.e. sync steps) as defined above, and not
time cycles.
The user may explicitly control the sync step in the following ways:
The user may explicitly control the cycles in the following ways:
Note, however, that within each time step the time cycles vary in general
from subdomain to subdomain, and vary in time for a given subdomain,
even in the case that the user chooses OPTI PAS UTIL and a fixed
time step, except in the case that a fixed cycle value
dtfx value is explicitly specified.
When the DTUN keyword is used, subdomains are forced to follow one
unique time scale. According to options set in the OPTION directive
and to stability conditions on all subdomains, one single time-step is computed
at each cycle and given to each subdomain. Subdomains are thus always
synchronized.
Since the behaviour of the present domain decomposition model as regards
time stepping depends upon the corresponding user option (i.e. upon
PAS AUTO or PAS UTIL), it is advised to specify the
STRUCTURE directive after any options that set the time stepping
mode (but before the CALCUL directive, as already noted).
When option "POST" "CHPO"
is activated, the CHAMELEMS are to be computed out of EUROPLEXUS from the CHAMPOINTS with a linear
elastic constitutive law, which is the only valid within a modal subdomain.
Example 1 :
OPTION PAS AUTO STEP IO ... STRUCTURE 3 DOMA LECT zone1 TERM IDEN 91 DOMA LECT zone2 TERM IDEN 92 DTMX 5e-6 MODA LECT zone3 TERM IDEN 93 FICH FORM POST TOUS NOFO CALCUL TINI 0.0 DTMAX 40e-5 NMAX 80000 TFIN 350e-3
The computational domain consists of three subdomains.
The stability time cycle of the first
subdomain is computed automatically by the code. The stability cycle of
the second subdomain is the minimum between the computed value and 5E-6.
The third subdomain is replaced by a modal basis, with modes and matrices
given in file ’<base_name>.msh’ (i.e. the same file
that contains the CASTEM 2000 mesh). Both the CHAMELEMS the CHAMPOINTS
but no external forces are computed within this subdomain.
The sync step is automatically computed by the code as
the minimum value between 40E-5 (DTMAX) and
1.0 times the maximum stability step over all subdomains (recall that
by default sdfac equals 1.0).
Furthermore, the selected printing and storage times will be
precisely matched by adapting the sync step (OPTI STEP IO).
The three subdomains are identified as ’91’,
’92’ and ’93’ as far as interface declarations are
concerned (see the INTERFACES directive next).
Example 2 :
OPTION PAS UTIL ... STRUCTURE 3 DOMA LECT zone1 TERM DTFX 1e-6 DOMA LECT zone2 TERM DTMX 5e-6 DOMA LECT zone3 TERM CALCUL TINI 0.0 PASF 40e-5 NMAX 80000 TFIN 350e-3
The computational domain consists of three subdomains.
The stability cycle of subdomain 1 is fixed to the constant value 1E-6.
That of subdomain 2 is the minimum between its
stability value and 5E-6. That of subdomain 3 is dictated only
by local stability. The sync step is constant and has the value 40E-5.
Printout and storage of results will occur at the sync steps
whose times are greater than or equal to the chosen values. This is because
the OPTI STEP IO or OPTI STEP IOT options may not
be used in conjunction with OPTI PAS UTIL, i.e. the sync step
(being constant) may not be adapted.
MPI calculations
With fixed domain decomposition, the number of parallel threads must be
equal to the number of declared subdomains.
For automatic domain decomposition, an external file can be entered to provide
elementary weights, in order to optimize load balancing. Each line of the weight
file is composed of 2 integers: first the number of the concerned elementary
entity (finite element, finite volume, SPH particle...), second the weight
associated to it.
Classically, EUROPLEXUS is used to generate the weight file (see page I.20).
To generate the file from scratch, elementary numbers can be found in the
listing file of a previous run with the same model. Every elementary entity,
except CL elements and debris elements, must be given a weight.
If no weight file is used, all weights are set to 1.
Automatic decomposition using Recursive Orthogonal Bisection consists in
successive recursive splittings of the domain along available space directions
with circular permutations among them. Some directions may be deactivated, either by
the user (DACT keyword) or automatically by the program if the bounds of
the model along these directions are too small.
By default, the first splitting direction is the one along which the spatial extension of the
model is maximal. However, one specific starting direction can be forced using
DPRE keyword.
Classically, each splitting involved in the algorithm consists in creating from
1 part of the model 2 subparts of equal weight, yielding that the number of used
threads must be a power of 2. However, the proposed algorithm allows to use any
number of threads, by adjusting the number of levels of the recursive
decomposition and the number of subparts per part created at the last level, 2
subparts per part being created at every other levels.
For example, with 12 threads, 3 levels will be considered, with 3 subparts per
part at the last level (2*2*3=12), whereas with 10 threads, 2 levels will be
considered, with 5 subparts per part at the last level (2*5=10).
I.16
This directive allows to set options for the treatment of connections
between subdomains.
It also allows the explicit declaration of interfaces between couples of
sub-domains. These interfaces may correspond to
matching or non-matching meshes.
In the case of matching meshes, interface declaration is optional, provided
the interface nodes are the same (i.e., have the same index) for
the two sub-domains. If only the geometric points are identical (i.e.,
coordinates are the same), but each subdomain has its own nodes
(with different indexes), a compatible interface
has to be declared (see the COMP keyword below).
In the case of non-matching meshes, this directive is mandatory.
The STRUCTURE directive must appear before this directive.
"INTERFACE" $[ "LINK" ; "NOLI" ]$ $[ "MULT" ; "NOMU" ]$ ... ... < nbinterf * ( |[ "COMP" ; "MORTAR" ; "OPTIMAL" ]| <"TOLE" tole> ... ... "DOMAINE" ndom1 /LECTURE/ "DOMAINE" ndom2 /LECTURE/ ) >
Handling multiple time scales in a multi-domain framework requires a special
treatment of the interface connections using Lagrange multipliers. This
treatment is not avalaible for generic kinematic links, so that multiple
time scales option must be deactivated in order to couple interface connections
to other kinematic links, which may thus involve more than one subdomain. This
is done by automatically activating the DTUN option in the STRUCTURE
directive. This is also the case when the treatment of connections between
matching meshes with coincident nodes is accelerated by not using Lagrange
multipliers.
In those cases, multiple time scales in the model can still be taken into account by using
the PART keyword in the OPTION directive.
When using the mortar method, the sub-domains whose mesh is used to
discretize Lagrange multipliers has to be specified.
It is the second one (ndom2) in the order of declaration
of the sub-domains concerned by the interface.
When using interfaces with non-matching meshes, so-called CLxx
elements (see pages INT.90 and INT.100) have to
be affected to interface regions of each sub-domain. These
elements must be given the “phantom” material (MATE FANT) with
density equal to zero.
The treatment of non-matching meshes with 3D solid elements is restricted
to hierarchical meshes. In this case, the mortar method
and the optimal method are identical, and a mortar interface has
to be declared, with the second sub-domain corresponding
to the finest mesh.
The mortar method may be used with any element types in 2D,
but only with shell element types in 3D.
When using the mortar method
with linear interfaces (2-noded element sides),
there must be at least one geometrical point that has the same
coordinates, within the tolerance tole defined above,
in the two facing meshes. The node indexes (node numbers) of this point
can be different in the two meshes.
This is necessary because the interface model uses the point’s coordinates
internally in order to define a reference frame on the interface.
Example 1 :
STRUCTURE 3 DOMA LECT zone1 inte12 inte13 TERM IDEN 91 DOMA LECT zone2 inte21 inte23 TERM IDEN 92 MODA LECT zone3 inte31 inte32 TERM IDEN 93 FICH FORM 'fich.mrd' POST TOUS NOFO ... INTERFACE 3 COMP TOLE 1.E-2 DOMA 91 LECT inte12 TERM DOMA 92 LECT inte21 TERM MORTAR TOLE 1.E-2 DOMA 92 LECT inte23 TERM DOMA 93 LECT inte32 TERM OPTIMAL DOMA 91 LECT inte13 TERM DOMA 93 LECT inte31 TERM
The computational domain consists of three sub-domains. Three interfaces are declared:
Note that inte12, inte21 are nodes groups, whereas inte23, inte32, inte13, inte31 are elements groups.
I.17 - October 2012
This directive enables the use of the eXtended Finite Element Method (X-FEM). It uses a specific Level-set mesh to describe the crack in space.
The formulation of X-FEM is given by a standard part and an enriched one as follow:
Ū = |
| + |
| (12) |
This formulation allows to take into account a displacement discontinuity in the mechanical mesh (a crack). And the characterization of propagation law makes the crack propagate through the mesh without remeshing at any time. But enriched element are used in order to describe the discontinuity with additionnal degrees of freedom. The corresponding available elements are XCAR and XCUB for 2D and 3D.
The model is described in reference [], [].
"XFEM" "NI" ni "NJ" nj "DX" dx "DY" dy "XZER" xzer "YZER" yzer "FISX" fisx "FISY" fisy "FISC" fisc "PRBX" prbx "PRBY" prby "PRBC" prbc "ORDR" ordr "KICR" kicr "RAYO" rayo "CHOI" choi "CR" cr <"NK" nk "DZ" dz "ZZER" zzer "FISZ" fisz "PRBZ" prbz "RPLA" rpla "NCOU" ncou > /LECTURE/
The localization of the initial crack is given by 2 plans. The first one defines the
surface of the crack by: (level-set φ_{1})
fisx · X + fisy · Y + fisz · Z + fisc =0 (13) |
The corresponding level-set is:
φ_{1}(X,Y,Z)= |
| (14) |
And the second one defines the front of the crack: (level-set φ_{2})
prbx · X + prby · Y + prbz · Z + prbc =0 (15) |
The corresponding level-set is:
φ_{2}(X,Y,Z)= |
| (16) |
The crack is the isozero φ_{1} and the negative part of φ_{2}. Both level-sets are exported in paraview output with the keyword XLVL. So the representation of the crack in possible in paraview by doing the negative part of PHI2 on isozero PHI1.
Example 1:
... ECRITURE ... FICHIER FORMAT AVS PRVW FREQ 10 VARI DEPL XLVL ECRO ECRC LECT 2 TERM ... XFEM NI 300 NJ 200 NK 100 DX 0.0005 DY 0.0005 DZ 0.00025 XZER 0.03 YZER 0.01 ZZER -0.004 FISX -0.2 FISY 1. FISZ 0. FISC -0.026 PRBX 5. PRBY 1. PRBZ 0. PRBC -0.416 ORDR 8 KICR 12.E6 RAYO 0.001 CHOI 2 CR 250. RPLA 0.003 NCOU 7 LECT MAILX ... CALCUL TINI 0.0 DTMAX 40e-5 NMAX 80000 TFIN 350e-3
Bibliography:
Belytschko T., Black T., "Elastic crack growth in finite elements with minimal remeshing. International Journal for Numerical Methods in Engineering (1999) 45:601–620.
Moës N., Dolbow J., Betlytschko T., "A finite element method for crack growth without remeshing", International Journal for Numerical Methods in Engineering (1999) 46:131–150.
Moës N., Gravouil A., Belytschko T., "Non-planar 3D crack growth by the extended finite element and level sets - Part I: Mechanical model", International Journal for Numerical Methods in Engineering (2002) 53:2549–2568.
Gravouil A., Moës N., Belytschko T., "Non-planar 3D crack growth by the extended finite element and level sets - Part II: Level set update", International Journal for Numerical Methods in Engineering (2002) 53:2569–2586.
Menouillard T., Réthoré J., Combescure A. and Bung H., "Efficient explicit time stepping for the eXtended Finite Element Method (X-FEM)", International Journal for Numerical Methods in Engineering (2006) 68:911–939.
Menouillard T., "Dynamique explicite pour la simulation numérique de propagation de fissure par la méthode des éléments finis étendus", Thèse de Doctorat INSA de Lyon 2007.
I.20
This directive starts the time solution
of a given problem. The keyword
CALCUL is compulsory and should appear
after the data sets A, B, C, D, E, F, G and H.
The user can specify the initial and final times of
the computation, the value of or constraints on
the time step and the maximum number of
computation steps.
"CALCUL" "TINI" tini "TEND" tend < "NMAX" nmax > < "DTMI" dtmin > < "DTMA" dtmax > < "TFAI" tfai > < $[ "HIST" /PROG/ ; "PASFIX" pfix ]$ > < "PAS1" pasone > < "SDFA" sdfac > < "LBMS" nfreq > < "LBNS" nstep > < "LBMD" mxdev > < "LBST" > < "LBPW" ndwfil > < "LBFT" >
The word CALCUL is compulsory and should appear only once.
If a user does not have an idea of the stability
step for a given problem, he can run the program with the
If a user specifies PAS UTILISATEUR, he is responsible for
the stability of the computation, because EUROPLEXUS does
not check the stability in this case.
This option may therefore lead to instabilities in the calculation,
and should only be used in special cases.
The maximum value of the time step enables the time
step to be limited in the case of the option PAS AUTOMATIQUE
or PARTITION.
The computation stops when either the maximum number
of steps or the final time is reached.
A computation in PAS AUTO or PART also stops if
the stability step becomes lower than the minimum value.
If HIST is used, remember to dimension adequately
(see TTHI on page A.105).
Note that, in multi-domain computations, all time-related quantities
in the CALCUL directive refer to sync steps and not to
subdomains cycles (see directive STRUCTURE on page I.15).
Load-balance measuring for MPI calculations
This section is still under strong development.
Load-balance is a key point to achieve parallel performance. Load-balance measuring
consists in measuring time taken by each thread to perform computational tasks within
a given number of time steps.
The first measuring period starts at the first step of the simulation. After that, the
number of time steps between the starting steps of two successive measuring
periods is given using LBMS keyword. Measuring options are activated as
soon as a positive integer is read after LBMS keyword.
The number of time steps within a measuring period is given using LBNS keyword,
which should be smaller than the interval between two measuring periods to produce
accurate results. Default value is 100.
Quality of load-balance is estimated through the value of the standard deviation
of the quantity of interest. If the quantity is well distributed among the
threads, standard deviation should be close to 0. 2 quantities are currently considered:
first, the time needed to perform elementary computations, which is controlled
by the quality of domain decomposition, second, the time needed to perform every
computational tasks, including treatment of links. LBMD is used to enter
a maximum authorized standard deviation for both quantities, generating a warning
message if it is overcome at the end of a measuring period. The calculation can be
forced to stop in the case of unauthorized standard deviation concerning
elementary computations (LBST keyword), as it indicates that domain decomposition
should be improved.
Using time measures during a period, the program is able to estimate the
computational cost of elementary entities (finite elements, finite volumes,
SPH particles...), as far as elementary operations only are concerned. A weight
file can be written using LBPW keyword, to be used to improve automatic
domain decomposition (see page I.15).
Measured weights can be filtered prior to file writing, to account for numerical
noise in measures due to execution environment. Current filter consists in
computing a global cost for groups of elements instead of individuals. Elements
are grouped with respect to the couple of parameters (type of element, type of
material). Group weight is then equally divided among concerned elements.
This can produce bad results and should be used with care. Raw weights and filtered weights can be visualized using PVTK output file.
I.23
This directive allows to specify a so-called “EURDYN-1D input deck”,
i.e. a set of input data to be read by the EURDYN-1D module (ED1D) that
is now embedded within EUROPLEXUS. In this way it is possible to
perform a coupled 1-D/multi-D calculation, as described on
page I.80.
The ED1D input deck must be included within the
normal EUROPLEXUS input file, immediately after the CALCUL
directive and before any additional EUROPLEXUS directives
(for example, QUALIFICATION).
The ED1D input deck must be immediately preceded by
a line containing ED1D
(capitals, starting in column 1, followed only by blanks if any)
and be immediately followed by a line containing ED1D END
(capitals, starting in column 1, followed only by blanks if any).
. . . "CALC" . . . (see CALCUL directive, page I.20) * *====================================================== ED1D (as many ED1D data as needed to describe the 1D part of the numerical model) ED1D END *====================================================== * <"PLAY" . . . or "QUAL" . . . or "SUIT" or "FIN">
The keyword ED1D
must appear as such and start in column 1.
There must not be any other data on the same line.
The keywords ED1D END
must appear as such and start in column 1.
There must not be any other data on the same line.
The contents of the ED1D data deck proper (i.e. the lines contained
between ED1D START
and ED1D END
) is described in the EURDYN-1D
manual, listed in the References: ([]).
By default, EUROPLEXUS reserves a memory of 50,000 REAL*4
for the ED1D data. If necessary the size of this memory can be
increased by the DIME ME1D keyword, see Page A.67.
I.24
This directive allows to execute a set of “interactive” commands,
i.e. any of the commands described on Pages A.25 and O.10, by reading
them from a file (actually, from the regular EUROPLEXUS input file)
rather than from the keyboard.
If present, this directive must immediately follow the CALC
directive (and the optional ED1D ... ED1D END directive, if present).
Normally, interactive commands are typed by the user at the keyboard.
With the present directive, it is possible to store such
commands in the regular EUROPLEXUS input file,
with the advantage that a given “interactive” calculation may be repeated
identically as many times as needed.
This feature is especially useful for the automatic execution
of calculations with intermediate visualizations (TRAC) and
for the automatic generation of animations (AVI).
After reading the PLAY directive, the code continues to read
the following commands from the regular EUROPLEXUS input file,
but interprets them as interactive commands (i.e. like if they were typed
at the keyboard), until the
termination sequence ENDPLAY is encountered. Then, normal
input file reading (again from the regular EUROPLEXUS input file) is restored.
. . . "CALC" . . . (see CALCUL directive, page I.20) * <"ED1D" {Eurdyn-1D input deck} "ED1D END"> * *=================================================================== PLAY (as many `interactive' commands (see Pages A.25 and O.10) as needed) ENDPLAY *=================================================================== * <"QUAL" . . . or "SUIT" or "FIN">
The keyword PLAY must appear as such and start in column 1.
There must not be any other data on the same line.
The keyword ENDPLAY must appear as such and start in column 1.
There must not be any other data on the same line.
The available interactive commands are listed on page A.25.
I.25 - Oct 14
This directive allows to verify (qualify) the results of a calculation by comparing them with given reference values.
The keyword VALIDATION is still accepted in place of QUALIFICATION
for backward compatibility. However, new input files should
always use the keyword QUAL.
The qualification is normally done at the final time of the transient
calculation. However, when reading a results file
it can also be done at an intermediate time by
using the SORT ARRE commands, see comments below and Page ED.40.
"QUAL" <"AUTO"> ( |[ "COOR" ; "DEPL" ; "VITE" ; "ACCE" ; "FEXT" ; "MASN" ; "ADFT" ; "MCPR" ; "MCRO" ; "MCTE" ; "MCVI" ; "MCMF" ; "SIGN" ; "ECRN" ; "FINT" ; "FLIA" ; "FDEC" ; "PFSI" ; "PFMI" ; "PFMA" ; "CONT" ; "EPST" ; "ECRO" ; "ENEL" ; "RHO" ; "MASE" ; "EPAI" ; "VCVI" ; "RISK" ; ; "BILA" ; "WINT" ; "WEXT" ; "WCIN" ; "WECH" ; "TIME" ; "COUR" icourb ]| $[ |[ "COMP" icomp ; "NORM" ]| <"GAUS" igaus> ]$ "REFE" valref "TOLE" valtol /LECTURE/ )
igauss
=1.
/LECTURE/
are
redundant.
/LECTURE/
are
redundant.
Only one node or element must be concerned by the validation.
The specification of a Gauss point makes sense only for parameters
related to elements, such as: CONTR
, EPST
or ECRO
.
It is possible to check as many values as needed, by repeating the name
of the variable. The calculation will be considered correct if
all checks are correct.
By default the qualification is done at the final time of the calculation.
When reading a results file, it is possible to perform the qualification
at a different time (not the final one), by using
the SORT ARRE command, see Page ED.40.
This can be useful in case the “signal” (monitored quantity)
to be checked has either a very small value or a very large time
derivative at the final time, while it has a more “stable”
value (plateau) at a previous time.
It is sometimes tedious to prepare an input data set for a new
test case or benchmark calculation, especially when many quantities must be
verified. In some cases, the reference values
are not well known a priori from physical considerations, analytical
solutions or experimental data. Therefore, sometimes these values are
computed by the code itself.
Although this is in some sense a misuse
of the QUAL directive (because it is no longer a true qualification
of results!), it may be useful e.g. to verify non-regression of code
results during the development phase.
In such cases, the AUTO directive may speed up the process of preparing
the input file, in the following way. First, write the qualification
directives for the desired quantities, but by setting arbitrary reference
values (e.g. all zero). Specify the AUTO directive immediately after
QUAL and run the code.
In this way, qualification is computed normally, but for each verified
quantity the code writes on the listing an extra line, introduced by
the sequence AQ:, and containing the qualification directive with
the ’correct’ reference value (i.e. the one found by the code).
By searching all such lines in the listing, cutting them and pasting into the
input file, it is possible to obtain a ‘correct’ input file
much more rapidly (and with less errors) than by
typing in the correct reference values by hand. Do not forget
to remove the AUTO keyword once done the job.
Example of using the command COUR:
GRAPH COURBE 52 'RR-P2' distance lecture OO P2 term ... QUALIF COURBE 52 REFE 1.2 TOLE 1e-4
The expected and obtained values are printed on the listing, together with the relative error, which is compared with the tolerance.
For each correct (respectively incorrect) check, the phrase:
==> VALIDATION : SUCCES
is printed on the listing
(resp. ==> VALIDATION : ECHEC
).
At the end of the calculation, if all is fine the phrase:
==> LE CALCUL EST CORRECT !
is printed, else:
==> LE CALCUL EST FAUX !
.
I.30
The word "SUITE" written immediately after the instruction "CALCUL"
enables the next data set to be read, and the corresponding case to
be processed, immediately after the first (or current) computation.
Using the word "SUITE" placed after each data set, the user
can enter as many data sets as he wants.
The last set must end with the word "FIN".
$[ "SUITE" ; "FIN" ]$
The word "SUITE" is the only word of the directive. It must
immediately follow the instruction "CALCUL" .
The word "FIN" is compulsory at the end of the data.