Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Successfully reported this slideshow.

Like this presentation? Why not share!

- AI and Machine Learning Demystified... by Carol Smith 2874570 views
- The AI Rush by Jean-Baptiste Dumont 749297 views
- 10 facts about jobs in the future by Pew Research Cent... 427320 views
- 2017 holiday survey: An annual anal... by Deloitte United S... 703882 views
- Harry Surden - Artificial Intellige... by Harry Surden 383464 views
- Inside Google's Numbers in 2017 by Rand Fishkin 938676 views

76 views

Published on

Published in:
Education

No Downloads

Total views

76

On SlideShare

0

From Embeds

0

Number of Embeds

0

Shares

0

Downloads

1

Comments

0

Likes

1

No embeds

No notes for slide

- 1. Riccardo Rigon, Francesco Serafin, Niccolò Tubini Grids Hints for a Java implementation R.Rigon-IltavolodilavorodiRemowolf
- 2. 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. 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. 4 The 3d case Rigon, Serafin,Tubini
- 5. 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 Rigon, Serafin,Tubini
- 6. 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 Rigon, Serafin,Tubini
- 7. 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 Rigon, Serafin,Tubini
- 8. 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 Rigon, Serafin,Tubini
- 9. 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 Rigon, Serafin,Tubini
- 10. 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 Rigon, Serafin,Tubini
- 11. 11 We can number also the volumes: 1 2 3 Rigon, Serafin,Tubini A simple example 1 2 3 4 5 6 7 8 9
- 12. 12 Nodes and edges can be represented as follows Rigon, Serafin,Tubini 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. 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 Rigon, Serafin,Tubini 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. 14 1 2 3 dual nodes and dual edges Rigon, Serafin,Tubini 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. 15 dual nodes and dual edges Rigon, Serafin,Tubini 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. 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 Rigon, Serafin,Tubini
- 17. 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 Rigon, Serafin,Tubini
- 18. 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 Rigon, Serafin,Tubini Volumes Faces Also Dual Nodes and Volumes are in a one-to one correspondence.
- 19. 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 Rigon, Serafin,Tubini
- 20. 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: ? Rigon, Serafin,Tubini 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. 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> First hints for deployment Complex3D -faces: int[][] -volumes: int[][] -dualEdges: int[2][] Rigon, Serafin,Tubini
- 22. 22 First hints for deployment 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). Rigon, Serafin,Tubini
- 23. 23 Because the number of rows is irregular these matrixes must contain a No DATA indicator which in the figure below is “-1” First hints for deployment 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 Rigon, Serafin,Tubini
- 24. 24 Another option would be to use the Java ArrayList collection to store the data First hints for deployment 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. Rigon, Serafin,Tubini
- 25. 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. Rigon, Serafin,Tubini First hints for deployment -nodes: ArrayList<Integer[]>
- 26. 26 Rigon, Serafin,Tubini First hints for deployment 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. 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 Rigon, Serafin,Tubini First hints for deployment -nodes: ArrayList<Integer[]> cell: int[] cellDual: int[] cell: int[]
- 28. 28 Rigon, Serafin,Tubini First hints for deployment 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. 29 Rigon, Serafin,Tubini 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. 30 2D Rigon, Serafin,Tubini 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. 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 Rigon, Serafin,Tubini
- 32. 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 Rigon, Serafin,Tubini
- 33. 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 Rigon, Serafin,Tubini
- 34. 34 In this case, therefore, the class UML could be as follows: Complex2D -edges: ArrayList<CellWithDual> -faces: ArrayList<Cell> Cell2D Cell2DWithDual -nodes: ArrayList<Integer[]> cell: int[] cellDual: int[] cell: int[] 2D Rigon, Serafin,Tubini
- 35. 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 -edges: ArrayList<CellWithDual> -faces: ArrayList<Cell> -nodes: ArrayList<Integer[]> 2D Rigon, Serafin,Tubini
- 36. 36 1D Rigon, Serafin,Tubini 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. 37 Complex1D -edges: ArrayList<Cell(2)> -nodes: ArrayList<Integer[]> 1D Rigon, Serafin,Tubini rename(): rename the nodes in order they are indicated by a continuous sequence of numbers
- 38. 38 Ordering bring in simplification Rigon, Serafin,Tubini 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. 39 Complex1D -nodes:int Ordering bring in simplification Rigon, Serafin,Tubini For generality, we still can thing to have a class containing this information
- 40. 40 1D - graphs (even in n dimensions) Rigon, Serafin,Tubini 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. 41 A graph is dual to a surface (in 3D to a volume) ! Rigon, Serafin,Tubini 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. 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 Rigon, Serafin,Tubini Let’s it to analyse the situation of graphs a little
- 43. 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 Rigon, Serafin,Tubini Let’s it to analyse the situation of graphs a little
- 44. 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: Rigon, Serafin,Tubini Let’s it to analyse the situation of graphs a little
- 45. 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> -edges: ArrayList<CellWithDual> which variant has to be used (or HashTable<index,link> instead of HashMap<index,link> ) has to be investigated. Rigon, Serafin,Tubini Let’s it to analyse the situation of graphs a little disordered index ordered index
- 46. 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. Rigon, Serafin,Tubini 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. 47 Back to the design idea Rigon, Serafin,Tubini 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. 48 Complex-g -nodes: DisorderedCells -edges: DisorderedCellsPlus In such a way, the complex-g class, for instance, can be rewritten as: Back to the design idea Rigon, Serafin,Tubini
- 49. 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 Rigon, Serafin,Tubini *In geographic tools, these are usually represented trough shapefiles which actually keeps in various topological structures.
- 50. 50 Quantities and Parameters Rigon, Serafin,Tubini 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. 51 Cells Concrete Cells Properties (Decorator) Concrete Property Cells cells; Properties as decorators Cells concreteCells; Rigon, Serafin,Tubini
- 52. 52 Properties as decorators Rigon, Serafin,Tubini 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. 53 Properties as decorators Rigon, Serafin,Tubini 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. 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 Rigon, Serafin,Tubini
- 55. 55 nodes coordinates edges length, shape faces area volumes volumes Geometries Rigon, Serafin,Tubini 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. 56 edges length, shape Geometries Rigon, Serafin,Tubini 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. 57 Exercise yourself To be continued Rigon, Serafin,Tubini 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. 58 Dynamic varying grids Rigon, Serafin,Tubini “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. 59 Dynamic varying grids Rigon, Serafin,Tubini 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. 60 Dynamic varying grids Rigon, Serafin,Tubini 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.
- 61. Exercise yourself To be continued Rigon, Serafin,Tubini 3 - Add to the infrastructure you envisioned an Observer pattern strategy to cope with topological changes. 61
- 62. 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 ;-) Rigon, Serafin,Tubini 62
- 63. Further Notes Rigon, Serafin,Tubini 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
- 64. Moving Grids Rigon, Serafin,Tubini From my colleagues: It follows that there are things we can learn from them (I already knew it). 64
- 65. 65 Thank you for your attention. G.Ulrici,2-1-1-1? It ends here R. Rigon

No public clipboards found for this slide

Be the first to comment