@@ -1650,10 +1650,10 @@ In this example, we are dealing with 3 ~mesh~ variables.
duplication of the mesh in memory.
- Then, the variable ~m3~ is defined to refer to a *new* mesh (called
$\mathcal{M}_b$. It is /similar/ to $\mathcal{M}_a$, but it is *not* the
same one! When ~m3~ is defined two meshes $\mathcal{M}_a$ and
same one! When ~m3~ is defined, two meshes $\mathcal{M}_a$ and
$\mathcal{M}_b$ (and two distinct connectivities) are resident in
memory.
- Finally, the last instruction (~m3 = m1;~) sets ~m3~ to also refer
- Finally, the last instruction (~m3 = m1;~) sets ~m3~ to also refer to
$\mathcal{M}_a$. Since no other variable refers to $\mathcal{M}_b$,
this mesh is destroyed (memory is freed). At the end of the program,
all the variables ~m1~, ~m2~ and ~m3~ are referring to $\mathcal{M}_a$
...
...
@@ -1755,9 +1755,9 @@ is the operator ~=~.
**** Use of compound types
Actually using compound types the way it is presented in this
paragraph is not recommend. The purpose of compounds types and
compound affectations is related to functions. As one will see in
section [[functions]], functions can return compound values, thus compound
paragraph is not recommend. The purpose of compound types and compound
affectations is related to functions. As one will see in section
[[functions]], functions can return compound values, thus compound
affectations (or definitions) are needed to get returned values in
that case.
...
...
@@ -1801,7 +1801,7 @@ Observe that the special value ~0~ is used there.
**** Tuple purpose
Tuples variables are just lists of data of the same type. In the ~pugs~
Tuple variables are just lists of data of the same type. In the ~pugs~
language, one cannot access to a specific value of the list nor alter
one of them. This is not something that should ever change. Tuples are
not arrays! The ~pugs~ language is not meant to allow low-level
...
...
@@ -1816,10 +1816,10 @@ boundary conditions to a method.
The ~pugs~ language supports classical statements to control the data
flow. For simplicity, these statements syntax follow their ~C++~
counterpart. The only statement that is not implemented in ~pugs~ is the
~switch...case~. This may change but in the one hand, up to now it was
never necessary (up to now, we did not encountered the need to chain
~if...else~ statements), and on the other hand, keeping the language as
simple as possible remains the policy in ~pugs~ development.
~switch...case~. This may change but in the one hand, up to now it has
never been necessary (up to now, we did not encountered the need to
chain ~if...else~ statements), and on the other hand, keeping the
language as simple as possible remains the policy in ~pugs~ development.
*** ~if...else~ statement
...
...
@@ -1902,11 +1902,11 @@ are optional. The ~condition~ argument, if it is present, *must* be a
boolean value (type ~B~). If it is absent, the default value ~true~ is
used.
- The ~declarationinstruction~ is execute only *once* /before/ the beginning
- The ~declarationinstruction~ is executed only *once* /before/ the beginning
of the loop. The lifetime of the variable declared here is defined
by the ~for~ instruction itself.
- The ~condition~ is evaluate /before/ each loop.
- The ~condition~ is evaluated /before/ each loop.
- The ~postinstruction~ is executed /after/ each loop.
...
...
@@ -1986,7 +1986,7 @@ The ~statement~ is either a single instruction or a block of
instructions. The ~condition~ is an expression of boolean value (type
~B~).
This time is the ~condition~ is not satisfied (~false~ when reaching the
This time if the ~condition~ is not satisfied (~false~ when reaching the
~while~ instruction), the ~statment~ is never executed.
An example of the ~while~ loop is the following.
...
...
@@ -2167,10 +2167,10 @@ Using compound types as input and output, one can write
This meaningless example produces the following result.
#+results: R22-R-string-to-R-string-function
**** Lifetime of functions arguments
**** Lifetime of functions' arguments
The arguments used to define a function are *local* variables that
exists only during the evaluation of the function.
The arguments used to define a function are *local* variables that exist
only during the evaluation of the function.
Let us consider the following example
#+NAME: lifetime-of-function-args
...
...
@@ -2187,7 +2187,7 @@ This gives the expected result: the value of the variable ~a~ is
unchanged.
#+results: lifetime-of-function-args
**** Non-arguments variables in function expressions
**** Non-argument variables in function expressions
Here we discuss rapidly of using variables (which are not arguments)
in function expressions.
...
...
@@ -2210,7 +2210,7 @@ Running the example, one gets
#+results: non-arg-variables-in-functions
While the function itself is a constant object, one sees that since
the value of ~a~ is changed, the value function is implicitly
modified. /This is a dangerous feature and should be avoid!/
modified. /This is a dangerous feature and should be avoided!/
Since functions themselves are variables one can use functions in
function expressions.
...
...
@@ -2287,7 +2287,7 @@ functions. They differ from user-defined functions in three points.
- Builtin functions can have no parameter or no returned value.
- Builtin functions are polymorphic. More precisely, this means that
the signature of a builtin function is also defined by its expected
arguments types.
argument types.
- Builtin functions can take user-defined functions as parameters.
- user-defined functions cannot take functions as parameters
- builtin functions cannot take builtin functions as parameters
...
...
@@ -2339,15 +2339,14 @@ One can access to the list of available modules inside the language.
#+END_SRC
The output lists all available modules
#+RESULTS: get-available-modules
Let us comment a bit this output. One notices that there are two kind
Let us comment a bit this output. One notices that there are two kinds
of modules. Modules that are automatically imported (tagged with a ~*~)
and the other ones.
In this section we will not describe exhaustively the whole module
contents but will give the basic information that should allow the
user to find his way. To do so, it is important to examine carefully
the content of the ~core~ module, since it contains some helper
functions.
content but will give the basic information that should allow the user
to find his way. To do so, it is important to examine carefully the
content of the ~core~ module, since it contains some helper functions.
*** The ~core~ module
...
...
@@ -2475,8 +2474,8 @@ Running this example gives
***** ~ofstream: string -> ostream~
This function is used to create an ~ostream~ that actually write to the
file which name is given by the ~string~ argument. One should notice
This function is used to create an ~ostream~ that actually writes to the
file whose name is given by the ~string~ argument. One should notice
that the file is *created* at the function call. If a file with the same
name existed, it is *erased*.
#+NAME: ofstream-example
...
...
@@ -2566,7 +2565,7 @@ as ${(x^y)}^z$. Thus, using the ~pow~ function avoids any confusion.
*** The ~mesh~ module
This is an important module. It provides mesh utilities tools.
This is an important module. It provides mesh utility tools.
#+NAME: get-module-info-mesh
#+BEGIN_SRC pugs :exports both :results output
cout << getModuleInfo("mesh") << "\n";
...
...
@@ -2586,7 +2585,7 @@ A ~boundary~ can designate a set of nodes, edges or faces. The ~boundary~
#+BEGIN_warning
A ~boundary~ *cannot* be used to refer to an interface (/ie/ an inner set of
items)..
items).
#+END_warning
***** ~zone~
...
...
@@ -2598,7 +2597,7 @@ precised when it is associated with a ~mesh~.
***** ~mesh~
The type ~mesh~ is an *abstract* type that is used to store meshes. A
variable of that type can refer for instance unstructured meshes of
variable of that type can refer for instance to unstructured meshes of
dimension 1, 2 or 3.
The following binary operator is provided.
...
...
@@ -2634,7 +2633,7 @@ This type is used to designate kinds of items (cell, face, edge or node).
The type ~item_value~ is an abstract type use to designate arrays of
values defined on the entities of a ~mesh~. Actually, these values are
not associated to the mesh itself but on the *connectivity*. The values
not associated to the mesh itself but to the *connectivity*. The values
on the entities can be of type ~B~, ~N~, ~Z~, ~R~, ~R^1~, ~R^2~, ~R^3~, ~R^1x1~, ~R^2x2~
and ~R^3x3~. Entities themselves can be cells, faces, edges or nodes.
...
...
@@ -2645,17 +2644,16 @@ By now, no mathematical operation is defined on ~item_value~ variables.
#+END_warning
Moreover, ~item_value~ variables can be post processed. Observe that
edges or faces values cannot be post processed since neither ~VTK~ nor
edge or face values cannot be post processed since neither ~VTK~ nor
~Gnuplot~ can handle these data.
***** ~sub_item_value~
This abstract type is handle values defined on the sub items of the
This abstract type handles values defined on the sub items of the
items of a ~mesh~. Similarly these values are attached to a *connectivity*
and not to a mesh. Values can bed of type The values on the entities
can be of type ~B~, ~N~, ~Z~, ~R~, ~R^1~, ~R^2~ or ~R^3~. An example of
~sub_item_value~ is the $\mathbf{C}_{jr}$ vectors which are defined at each
node of each cell.
and not to a mesh. The values associated to the sub items can be of
type ~B~, ~N~, ~Z~, ~R~, ~R^1~, ~R^2~ or ~R^3~. An example of ~sub_item_value~ is the
$\mathbf{C}_{jr}$ vectors which are defined at each node of each cell.
These variables are used to pass data from one function to
another. They cannot be post processed.
...
...
@@ -2695,7 +2693,7 @@ Creates a zone descriptor from a ~string~ name
****** ~zoneTag: Z -> zone~
Associates a zone descriptor from zone tag
Associates a zone descriptor from a zone tag
#+BEGIN_SRC pugs :exports both :results none
import mesh;
...
...
@@ -2707,9 +2705,10 @@ Associates a zone descriptor from zone tag
Creates a cartesian mesh of dimension $d\in\{1, 2, 3\}$. The produced
cartesian grid is aligned with the axis and made of identical cells.
The two first arguments are two opposite corners of the box (or
The first two arguments are two opposite corners of the box (or of the
segment in 1d) and the list of natural integers (type ~(N)~) sets the
number of *cells* in each direction. Thus size of the list of ~N~ is $d$.
number of *cells* in each direction. Thus the size of the list of ~N~ is
$d$.
For instance one can write:
#+BEGIN_SRC pugs :exports both :results none
...
...
@@ -2866,8 +2865,8 @@ The ~mesh~ is represented in Figure [[fig:gmsh-hybrid-2d]].
#+RESULTS: diamond-dual-img
#+BEGIN_note
The mesh storage mechanisms in ~pugs~ is such that the diamond dual mesh
is built only once. This means that is one writes for instance
The mesh storage mechanism in ~pugs~ is such that the diamond dual mesh
is built only once. This means that if one writes for instance
#+BEGIN_SRC pugs :exports both :results none
import mesh;
...
...
@@ -2931,7 +2930,9 @@ available in parallel
#+END_warning
***** Item types
The following functions are used to refer to ~item_type~
\\
The following functions are used to designate a specific ~item_type~
- ~cell: void -> item_type~
- ~face: void -> item_type~
- ~edge: void -> item_type~
...
...
@@ -2964,8 +2965,8 @@ In this example, we set three arrays defined at all nodes, all the
This function allows to compute a new mesh as the transformation of a
given mesh by displacing its nodes through a user defined function.
For a mesh of dimension $d$, the mesh must be a function $\mathbb{R}^d
\to\mathbb{R}^d$.
For a mesh of dimension $d$, the transformation must be a function
$\mathbb{R}^d \to\mathbb{R}^d$.
#+BEGIN_SRC pugs :exports both :results none
import mesh;
...
...
@@ -3067,10 +3068,10 @@ different meshes produced in this example are displayed in Figure
unset ytics
set square
set terminal png truecolor enhanced size 640,640
plot '<(sed "" $PUGS_SOURCE_DIR/doc/relax_example_m0.gnu)' lt rgb "green" w l, '<(sed "" $PUGS_SOURCE_DIR/doc/relax_example_m1.gnu)' lt rgb "blue" w l, '<(sed "" $PUGS_SOURCE_DIR/doc/relax_example_m2.gnu)' lt rgb "black" w l
plot '<(sed "" $PUGS_SOURCE_DIR/doc/relax_example_m0.gnu)' lt rgb "black" w l, '<(sed "" $PUGS_SOURCE_DIR/doc/relax_example_m1.gnu)' lt rgb "blue" w l, '<(sed "" $PUGS_SOURCE_DIR/doc/relax_example_m2.gnu)' lw 2 lt rgb "red" w l
#+END_SRC
#+CAPTION: Example of meshes relaxation. The relaxed mesh $\mathcal{M}_2$ (black) and the original meshes in green ($\mathcal{M}_0$) and blue ($\mathcal{M}_1$).
#+CAPTION: Example of meshes relaxation. The relaxed mesh $\mathcal{M}_2$ (red) and the original meshes in black ($\mathcal{M}_0$) and blue ($\mathcal{M}_1$).
plot '<(sed "" $PUGS_SOURCE_DIR/doc/gp_sin.gnu)' lw 2 w lp
#+END_SRC
#+CAPTION: Example of produced gnuplot results from the ~gnuplot_writer~. One can compare ths produced result to the one of the ~gnuplot_1d_writer~ given in Figure [[fig:writer-gp-1d-sin]]
#+CAPTION: Example of produced gnuplot results from the ~gnuplot_writer~. One can compare the produced result to the one of the ~gnuplot_1d_writer~ given in Figure [[fig:writer-gp-1d-sin]]
#+NAME: fig:writer-gp-sin
#+ATTR_LATEX: :width 0.38\textwidth
#+ATTR_HTML: :width 300px;
...
...
@@ -4722,7 +4723,7 @@ outputs.
The used format is one file in the ~vtu~ format for each parallel domain
(and eventually each time). The output is done using binary data for
performance reasons. For each time step a ~pvtu~ file is generate to
performance reasons. For each time step a ~pvtu~ file is generated to
handle parallelism. And for a complete time series, a ~pvd~ file is
produced. This is the file that should be loaded.
...
...
@@ -4755,9 +4756,9 @@ effectively generate the post processing files.
****** ~write: writer*(output) -> void~
As parameters, it takes a ~writer~ that is not a time series one and a
list of ~output~ (which are named discrete functions that are defined on
the *same* mesh).
As parameters, it takes a ~writer~ (that is not a time series writer)
and a list of ~output~ (which are named discrete functions that are
defined on the *same* mesh).
We have already shown a lot of examples of use of the ~write~
