Grids implementation

Riccardo Rigon, Francesco Serafin, Niccolò Tubini
Grids
Hints for a Java implementation
R.Rigon-IltavolodilavorodiRemowolf

Performances that matters are humans’ ones first.
Machine performances come second.
HPC is not FORTRAN, not even C++. It is good design
supported by fast and appropriate algorithms (and, if
needed, FORTRAN, C++, or even ASSEMBLER).
Before arriving to the ultimate optimisation,
I use Java

3
To begin
Getting closer the the implementation of a smart OO grid. A reader
can be find of some interest to read the previous series of slides about
Grids. We also assume to have already built the grids and
annotated somewhere its properties. Three questions arise:
which is a (the) minimal set of information necessary to store for
describing the grid; which is the whole set of information and which is
the information useful for a particular task. Here we mostly assess
the first.
As a preliminary work, these slides will go to various reordering/
refactoring.
Introduction
Rigon, Serafin,Tubini

4
The 3d case

5
*Nodes - They are essential because they can be used as
index position for edges and faces
*(Edges - Compose by ordered pairs of links to nodes'
index )
Faces - Composed by ordered groups of links to nodes
index - Any groups contains a number of elements equal
to the nodes belonging to the same face (which can be
variable) - The index of any faces group should be visible
to volumes and to dual edges because they need to use it
Volumes - Composed by ordered groups of links to faces
(which can be of variable dimension) - The index of
volumes should be visible to dual nodes.
Elements

6
*Dual Nodes - inherits from or is the index of the volumes
(equals the volume index)
Dual Edges - Composed by groups of links to dual
nodes (in variable number). The number of elements in
group equal the number of faces.
Elements

7
Cells
The cw complex seems to be composed by elements that repeats the same scheme
We can call this element a list of cells
1
2
3
1
2
4
5
6
7
99
17
22
45
-1 1 2 34
cell

8
Cells
According to our grid analysis, the more complicate case is the one where, we
have the possibility to store information about the cells and their dual, as the
case of faces in 3D
We can call this element a list of cells
cell
index
dual cell
boundary cell

9
Cells
A specialised case can be when all the cells are of the same type, so the number
of elements in cells is fixed and, in principle, can be stored in simpler containers.
cell
index
dual cell

10
A simple example
Consider as an example this “house” composed by a cube and two tetrahedrons
1
2
3 4
5
6
7
8
9
Let’s number the nodes and the faces (red for the cube, blue for the lef
trtrahedron, green for the right one

11
We can number also the volumes:
1
2 3
A simple example
1
2
3 4
5
6
7
8
9

12
Nodes and edges can be represented as follows
Nodes and edges
1 2 3 4 5 6 7 8 9Nodes
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16Edges
1
2
2
3
3
5 5
11
3
3
4 5
2 6
7
7
9 9
84
5 8
6 4
9
3
7 7
6 5
8
Where numbers in black squares are a reference to edges number, and
numbers blue squares are a reference to nodes number, and, for example,
edge 1 connects node 1 and 2. Nodes are put in order and this represent
also they (arbitrary) orientation. However, these groups of cells can be
omitted in our subsequent work.

13
1 2 3 4 5 6 7 8 9 10 11 12 13
3
2
7
6
5
2 4
45
3
3
2 1
2 3
1
3
2 1
42
1 1
3 4
3
5
4
9
8
6
5 8
faces and volumes
9
9
7
7 5 5 5 53 4 5
6
1 2 3
2
1
8
7
11
9
4 10
9
6
5
13
123
Faces
Volumes
Numbers in dark green squares are
referred to Faces. Number in blue
squares are referred to Nodes.
Numbers in orange squares refer to
Volumes

14
1
2 3
dual nodes and dual edges
So far we did not care of the dual
nodes and edges. They are relevant
because dual edges marks the
connectivity between volumes. Dual
e d g e s a r e i n a o n e t o o n e
correspondence with the neighbors’
faces (not with the volume faces).
Dual nodes are in a one-to-one
correspondence with the volumes.
Empty circles, visible (continuous
lines) or invisible (dotted lines)
represents connections with space
external to the CW-complex.

15
dual nodes and dual edges
Dual nodes and dual edges constitute a 3-dimensional graph. The tables
represent the nodes and the dual edges.
1
2 3
1 2 3
Dual Nodes
1 2 3 4 5 6 7 8 9 10 11 12 13
2
1 1 1 1 1 1 2
3
2 2 32 3
3
3
Dual Edges
Boundary Boundary

16
1 2 3 4 5 6 7 8 9 10 11 12 13
3
2
7
6
5
2 4
45
3
3
2 1
2 3
1
3
2 1
42
1 1
3 4
3
5
4
9
8
6
5 8
9
9
7
7 5 5 5 53 4 5
6
1 2 3 4 5 6 7 8 9 10 11 12 13
2
1 1 1 1 1 1 2
3
2 2 32 3
3
1
Faces
Dual edges
Edges
represented
by Nodes
Dual edges
represented
by ordered
dual nodes
faces and dual edges

17
1 2 3 4 5 6 7 8 9 10 11 12 13
3
2
7
6
5
2 4
45
3
3
2 1
2 3
1
3
2 1
42
1 1
3 4
3
5
4
9
8
6
5 8
9
9
7
7 5 5 5 53 4 5
6
2
1 1 1 1 1 1 2
3
2 2 32 3
3
1
Faces
Edges
represented
by Nodes
Dual edges
represented
by ordered
dual nodes
Because dual edges are in a one-to one correspondence with
Faces we can avoid to number them, as illustrated below
faces and dual edges

18
2 3Dual Nodes 1
1 2 3
2
1
8
7
11
9
4 10
9
6
5
13
123
Volumes and dual Nodes
Volumes
Faces
Also Dual Nodes and Volumes are in a one-to one
correspondence.

19
2 31
2
1
8
7
11
9
4 10
9
6
5
13
123
Therefor the same simplification applies.
Volumes and dual Nodes

20
At this point we have enough information to try a deployment. A cw-
complex can be a class, with two elements volumes and faces. Edges,
Nodes, dual Nodes and Dual Edges can be implicitly represented.
First hints for deployment
Complex3D
-faces: ?
-volumes: ?
We still do not know which type faces and volumes can be. Also on the
methods acting on this class we will discuss later

21
Actually, if we let dual Edges to be explicit, the class could be designed with the
following fields. Each of the field is a bidimensional matrix.
ArrayList volumes = ArrayList<Cells>
Complex3D
-faces: int[][]
-volumes: int[][]
-dualEdges: int[2][]

22
2
1 1 1 1 1 1 2
3
2 2 32 3
3
1
dualEdges
-1 -1 -1 -1 -1 -1 -1 -1 -1 -1
3
2
7
6
5
2 4
45
3
3
2 1
2 3
1
3
2 1
42
1 1
3 4
3
5
4
9
8
6
5 8
9
9
7
7 5 5 5 53 4 5
6 -1 -1 -1 -1-1 -1 -1
faces
2
1
8
7
11
9
4 10
9
6
5
13
123
-1
-1
-1
-1
volumes
The matrixes which contain just the links part, while the number of the Dual Edges,
Faces, and Volumes is left implicit (and equal to the number of columns).

23
Because the number of rows is irregular these matrixes must contain a No DATA
indicator which in the figure below is “-1”
2
1 1 1 1 1 1 2
3
2 2 32 3
3
1
dualEdges
-1 -1 -1 -1 -1 -1 -1 -1 -1 -1
3
2
7
6
5
2 4
45
3
3
2 1
2 3
1
3
2 1
42
1 1
3 4
3
5
4
9
8
6
5 8
9
9
7
7 5 5 5 53 4 5
6 -1 -1 -1 -1-1 -1 -1
faces
2
1
8
7
11
9
4 10
9
6
5
13
123
-1
-1
-1
-1
volumes

24
Another option would be to use the Java ArrayList collection to store the data
3
2
7
6
5
2 4
45
3
3
2 1
2 3
1
3
2 1
42
1 1
3 4
3
5
4
9
8
6
5 8
9
9
7
7 5 5 5 53 4 5
6
faces
ArrayList<Integer[]> faces= new ArrayList<Integer[]>(…);
ArrayList<Integer[]> volumes= new ArrayList<Integer[]>(…);
ArrayList<Integer[]> dualEdges= new ArrayList<Integer[]>(…);
In this case, as soon as we take care appropriately in the constructor,
the single vectors inside each element of the ArrayList, we do not need
to have the same number of elements in the interior vector of Integer.

25
Complex3D
-faces: ArrayList<Integer[]>
-volumes: ArrayList<Integer[]>
-dualEdges: ArrayList<Integer[2]>
In this case, the class UML could be as follows:
We can ask, obviously, if using the class Integer (instead of the native type int,
can slow down operations. We can also ask if, in some cases it could be of
interest to use ArrayLinkedList, instead of ArrayList.
-nodes: ArrayList<Integer[]>

26
We can actually also define two ancillary classes, i.e. a class Cell3D and a
class Cell3DWithDual
Cell3D
-cell: int[]
Cell3DWithDual
cell: int[]
dual: ArrayList<Integer[]>
cellDual: int[]
Instead of bare-bones vector, we could consider to have ArrayList(s), i.e.:
This would facilitates some operations but could have some computational cost
to be evaluated

27
C o m p l e x 3 D i s a
composition of the two
other classes
Complex3D
-faces: ArrayList<CellWithDual>
-volumes: ArrayList<Cell>
Cell3D
Cell3DWithDual
cell: int[]
cellDual: int[]
cell: int[]

28
We do not know a-priori which solution is the best. At moment however, we
could record the fact that we could have different implementation of
Complex3D. Therefore, we should promote the class to a more abstract
entity, like, for instance an interface.
Complex3D
Methods here
In this case, we are not expected to specify the fields of the interface, but just
the methods. The two concrete classes we draw before become then classes
that implements Complex3D.

29
Methods (all of them do not require any other information than topology)
check connectivity(): verifies the connection between pieces -
this is complicate
distance(): minimum topological distance between two nodes, two
edges, two faces or two volumes (so, this probably pertains to
Cell or CellawithDual classes)
split(): separates a mesh into two or more parts
merge():joins two or more meshes that have some boundary in
common or declare the merging point
refine(): adds internal cells to a grid
coarse(): eliminates internal cells and nodes
boundary(): searches for the boundary of a mesh
reorder(): reorders the mesh, for instance by putting all the
boundary cells at the beginning of the container
count(): counts the number of elements of a certain type.

30
2D
Nodes 1 2 3 4 7 12 13 99
Faces 1 2 3 4 5 6 7
12
4
7
4
7
4 2
24
1
3
2
4
3
13 13 99 99 99 4 12
1
2
3
12 13
7
99
4
1
2
34
5
6
7
Edges
6 1 2 5 7 72 16 17 23 29 31 37 41 43
13
4
7
4
99
4 2
44
3
12
4 2
99
7 1 1 2 3 12 7
99 99 2 123 13 13
1
2
16
5
7
6
72
17
23
29
37
41
43
31

31
1
2
34
5
6
7 1 2 3 4 5 6 7Dual Nodes
Dual Edges
1
2
16
5
7
6
72
17
23
29
31
37
41
43
6 1 2 5 7 72 16 17 23 29 31 37 41 43
2
1
3
2
4
3 4
76
6
7
1 4
5
3 5 5 6 7 1 2
2D

32
1 2 3 4 5 6 7Dual Nodes
Dual Edges
6 1 2 5 7 72 16 17 23 29 31 37 41 43
2
1
3
2
4
3 4
76
6
7
1 4
5
3 5 5 6 7 1 2
Faces 1 2 3 4 5 6 7
12
4
7
4
7
4 2
24
1
3
2
4
3
13 13 99 99 99 4 12
Nodes 1 2 3 4 7 12 13 99
2D

33
6 1 2 5 7 72 16 17 23 29 31 37 41 43
2
1
3
2
4
3 4
76
6
7
1 4
5
3 5 5 6 7 1 2
13
4
7
4
99
4 2
44
3
12
4 2
99
7 1 1 2 3 12 7
99 99 2 123 13 13
Dual Edges
Edges
Because Edges and dual edges are in a one-to-one correspondence they
can be treated together
2D

34
In this case, therefore, the class UML could be as follows:
Complex2D
-edges: ArrayList<CellWithDual>
-faces: ArrayList<Cell>
Cell2D
Cell2DWithDual
cell: int[]
cellDual: int[]
cell: int[]
2D

35
It can be observed that, except for the names, the structure of the
Complex2D class is the same that Complex2D. Therefore, we can
abolish the 3D and 2D and make the concrete classes an
implementation of the CWComplex interface/or abstract class. Also the
class Cells and CellsWithDual can be unified.
CWComplex
-faces: ArrayList<Cell>
2D

36
1D
Primal (Nodes plus Edges)
Dual (Nodes Plus Edges)
Nodes 1 2 6 3 12 4
1 2 36 412
13 99
Edges
11 13 17 19 23
11 13 17 19 23
11 13 17 19 23
Dual Nodes
1
2
2
6
6
3 12
43
12

37
Complex1D
-edges: ArrayList<Cell(2)>
1D
rename(): rename the nodes in order they are indicated by a
continuous sequence of numbers

38
Ordering bring in simplification
Primal (Nodes plus Edges)
Dual (Nodes Plus Edges)
Nodes 1 2 3 4 5 6
1 2 43 65
13 99
Edges
1 2 3 4 5
1 2 3 4 5
1 2 3 4 5
Dual Nodes
1
2
2
3
3
4 5
54
6
In this case, any information, except the nodes number is redundant.

39
Complex1D
-nodes:int
Ordering bring in simplification
For generality, we still can thing to have a class containing this information

40
1D - graphs (even in n dimensions)
Dual Edges
1
2
16
5
7
6
72
17
23
29
31
37
41
43
6 1 2 5 7 72 16 17 23 29 31 37 41 43
2
1
3
2
4
3 4
76
6
7
1 4
5
3 5 5 6 7 1 2
Actually we already have had an example of graphs
Dual Nodes 1 2 3 4 5 6 7
1
2
34
5
6
7

41
A graph is dual to a surface (in 3D to a volume) !
Dual Edges
1
2
16
5
7
6
72
17
23
29
31
37
41
43
6 1 2 5 7 72 16 17 23 29 31 37 41 43
2
1
3
2
4
3 4
76
6
7
1 4
5
3 5 5 6 7 1 2
Actually we already have had an example of graphs
Dual Nodes 1 2 3 4 5 6 7
1
2
34
5
6
7

42
But in a graph, what you want to di is usually, to navigate from node to node. Let’s
complicate a little the previous topology, also by adding explicitly terminal nodes.
1 2 3 4 5 6 7
72
6
6
1
2
1 2
235
16
7
5
37
7
41 43 17 16 29 31 72
8 9 10 11 12 13 14
41 43 17 23 29 31 37
15
41
47
Nodes
Edges
2
6
1
34
5
7
8
9
10
1112
13
14
15
16
1
2
16
5
7
672
17
23
29
31
37
41
43
47
47
47
47
16
Let’s it to analyse the situation of graphs a little

43
The whole picture is then:
2
6
1
34
5
7
8
9
10
1112
13
14
15
16
1
2
16
5
7
672
17
23
29
31
37
41
43
47
47
1 2 3 4 5 6 7
72
6
6
1
2
1 2
235
16
7
5
37
7
41 43 17 16 29 31 72
8 9 10 11 12 13 14
41 43 17 23 29 31 37
15
41
47
Nodes
Edges
47
47
16
6 1 2 5 7 72 16 17 23 29 31 37 41 43
2
1
3
2
4
3 4
76
6
7
1 4
5
3 5 5 6 7 8 2
47
10 11 12 1413 15 9
2
16

44
However, observe an issue that the numbering rises. If, for some reason, numbering
of edges (nodes, faces, etc) has gaps, the indexing of the container cannot be used to
indicate also the edges and their numbering has to be stored explicitly.
6 1 2 5 7 72 16 17 23 29 31 37 41 43
2
1
3
2
4
3 4
76
6
7
1 4
5
3 5 5 6 7 8 2
47
10 11 12 1413 15 9
2
16
Therefore:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
2
1
3
2
4
3 4
76
6
7
1 4
5
3 5 5 6 7 8 2
15
10 11 12 1413 15 9
2
16
is actually:
6 1 2 5 7 72 16 17 23 29 31 37 41 43 47edges:
index:
links to nodes:
?:
links to nodes:

45
This introduces a new variant in thinking disordered entities. That using
HashMap or HasTable instead of ArrayList
Complex-g
-nodes: HashMap<index,Cell>
-edges: HashMap<index,CellWithDual>
Complex-g
-nodes: ArrayList<Cell>
which variant has to be used (or HashTable<index,link> instead of
HashMap<index,link> ) has to be investigated.
disordered index ordered index

46
It is clear that the case of graphs just illustrated with non ordered nodes, can be
extended back also to the other type of Cells.
Back to the design idea
The idea, so far is that we can define two interfaces, Cells and CellsWithDual.
The overall container class, is generically implements an abstract class (or an
interface) called Complex which can contain, in the concrete ArrayLists or
HashMaps (HashTables) of Cells and/or DualCells.
These concrete classes implements the 1d, 2d, 3d or graph version of the CW-
Complex. In case Nodes are ordered, Nodes’ topology can be represented by
just a number.
Among the options, which solution is better, must be object of some
experimenting. Some methods of topological significance were found, and
could enter in the definition of the interface/abstract classes.
Work on graphs, can be actually expanded, but this will be matter of another
series of slides.

47
However, in order to keep any part of the implementation generic, is better
introduce a new interface
Cells
DisorderedCells
cells: HashMap<index,Cell>
DisorderedCellsPlus
cells: HashMap<index,CellWith Dual>

48
Complex-g
-nodes: DisorderedCells
-edges: DisorderedCellsPlus
In such a way, the complex-g class, for instance, can be rewritten as:

49
Topology is great
Please notice that the topological structure is more generally applicable than
to grids in common sense.
For instance a river network plus hillslopes is homeomorphic to a grid,
where the connections with neighbors are limited to a few or to a (dual)
graph. We have to be a little vague on nodes in that case, because a
hillslope (or a Hydrologic Response Unit, HRU), has nodes in variable
number*. However going to an implementation, we would really love to
be so general to include graphs mad of composition of geographic
objects.
Generalisation
*In geographic tools, these are usually represented trough shapefiles which actually keeps in
various topological structures.

50
Quantities and Parameters
How to add properties
While topology rules the connectivity of the graph (and how iterations
above the elements go), we build grids to contain data. These data, willing to
separate the topology from other properties, should be encapsulated in
other classes or in appropriate structures. We mature the idea that data are
linked to Cells (quite a trivial observation): we have data connected to
volumes, faces, edges, dual point and dual edges, accordingly to the
dimensionality and the type of the problem we are working to. So each
parameter or variable has the same dimensionality of the type of Cell it
pertains to.
In fact, Properties can be seen as a decorator of the grid entity to which it is
attached.

51
Cells
Concrete Cells
Properties (Decorator)
Concrete Property
Cells cells;
Properties as decorators
Cells concreteCells;

52
In this way, we can add as many properties we desire to any type of cells
Let’s consider a volume. It can have, for instance:
• volumesQuantity
• water mass
• water energy
• porosity
• etc
Properties (Decorator)
VolumesQuantity
Cells cells;
Cells volumes;
WaterMass
Cells volumes;

53
With respect to other possibilities, considering properties as classes, has the
advantage that they can be equipped with other useful information as:
•unit (m ? km ? kg ? - ?)
•a standard name (for instance according to the CF or the BMI convention, or
both)
•Ugrid specifications
Please, notice that Ugrid and BMI conventions have to be studied well.
However, our analysis, which has the ambition to be more general and deeper,
is a hope, than those previously made could bring to proposal for addition or
changes in the conventions.

54
Geometries
Geometries are the fundamental companion of topologies. Are you
able to think to a topological space which is without metric
attributes ?
For instance a river network plus hillslopes is homeomorphic to a grid,
where the connections with neighbors are limited to a few or to a (dual)
graph. They are the geometric attributes that, in case, make the
difference, both for their conceptual substance and their storage (which
can be obtained through shape files, for instance)
The fundamental companion

55
nodes coordinates
edges length, shape
faces area
volumes volumes
Geometries
Given for granted that we have denied the set of interfaces and/or abstract
classes. It should also be considered that we have concrete classes that represent
the following topological entities (they can assume various forms, depending
from the various simplification that we actually perform*), and that they are to be
associated with geometrical quantities
Each geometrical quantity is a parameter and can be represented by the
appropriate decorator class
*This let’s imagine that we could have a new class explosion to which we have to put some remedy.

56
edges length, shape
Geometries
We have to go deeper in the analysis. For instance, initially geometric objects
could be empty, and should be filled. For instance (assumed that nodes
coordinates are obtained by some other process), we can at the beginning
calculate length from coordinates type
Each geometrical quantity is a parameter and can be represented by the
appropriate decorator class
*This let’s imagine that we could have a new class explosion to which we have to put some remedy.
So a method estimateLength() should be appropriate for the class Length. In turn,
especially for some of the quantities, like areas and volumes, there could be
various algorithms to estimate them. Therefore, appropriate thinking has to be
made to be able to switch between them (or simply to try alternatives).

57
Exercise yourself
To be continued
1 - A variety of interfaces and classes has been invoked. It is time here to
make some exercise. Please try to summarise which are they and put
them in the appropriate relation. Change their names as appropriate.
Discover contradictions. Then move to try a deployment.
2- There exists grids that is known can be treated in a simple way. The
main important case are Cartesian grids. Please try to see how Cartesian
grids can enter in our framework, and which contribution, in case, they
bring to the definition of the OO design.

58
Dynamic varying grids
“Known issues left for future versions include: adaptive mesh topology (this
could be supported by defining a time_concatenation attribute for a time-
series of mesh topologies) higher order element data; for an idea how such
data could be stored see this other proposal. subgrid data; the NetCDF pages
by the Bundesanstalt für Wasserbau (BAW) contain some proposals on this topic
(see their pages (in German)). 3D fully unstructured meshes (some concepts are
included here, but still somewhat limited in scope). multiply-connected
domains ghost elements”
Some hints for dynamics adaptive grids
From Ugrid conventions page
From this words, it seems that our strategy for decoupling topology from
geometry could represent some advantage.

59
Two types of dynamic varying grids
There exists, at least to types of dynamic varying grids:
•Those that are deformed in time but do not change their topology
•Those that change the topology.
In our system, where topology is decoupled from geometry, the first
type of grids does change only the coordinates of nodes and, as a
consequence, the various geometric properties, that has to be
recalculated.
In the second case also the topology changes (by addition or
subtraction of nodes/edges or other entities)

60
We do not know, at present, what triggers the topology and/or the geometry
change. This will be, obviously, conveyed by some algorithm/logic and
deployed to classes and appropriate methods.
In the case just the geometry is changed, probably
nothing else change for us. All is already set.
In the case topology changes, all the quantities that rely on the topology
must be notified about the change happened. This means that the
structure of classes we already have envisioned (I admit not yet
deployed) has to be equipped with an Observer pattern infrastructure
that, at the same time has to be aware of HPC objectives.

Exercise yourself
To be continued
3 - Add to the infrastructure you envisioned an Observer pattern
strategy to cope with topological changes.
61

Which methods does our interface require (split, join, re-grid*)?
What about quantities defined over the topology (i.e. nodes and dual nodes coordinates, dual
edges length, faces area, volumes’ volume, parameters and physical quantities to be
associated with volumes, fluxes with faces) ?
Questions we have not answered yet
What about 2D and 1D ? Does this bring to further generalisations ?
What about special cases (i.e. grids will all the same volume type, regular grid).
Do they bring in simplification that can be used without loosing generality ?
Left as an exercise ;-)
*If we regard in real time, how do we extend the parameters and physical quantities
containers ?
How can we split the grid for parallel computation ? Hint: to start give a look to Berti’s and
Heinzl’s dissertations. Bibliography here.
How the iterators works on the classes we define ?
How we cope with Ugrid ? Left as an exercise ;-)
62

Further Notes
JTS:
If we move from the problem of representing the grids and its
properties to the one of building it. The Java Topology Suite
is the way to look first (its source code is on Github).
Various tutorial on tis use are available (from l’Aquila
University, Geotools project). JTS mostly addresses 2D
topologies (do far) but, this is certainly a starting point.
63

Moving Grids
From my colleagues:
It follows that there are things we can learn from them (I already knew it).
64

65
Thank you for your attention.
G.Ulrici,2-1-1-1?
It ends here
R. Rigon

Grids implementation

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Grids implementation

Semelhante a Grids implementation (20)

Mais de Riccardo Rigon

Mais de Riccardo Rigon (20)

Último

Último (20)

Grids implementation