coolfluid / coolfluid3

COOLFluiD is a collaborative simulation environment focused on complex multi-physics simulations
http://coolfluid.github.com
76 stars 77 forks source link

coordinate matching improvements + doxygen documentation #197

Closed wdeconinck closed 12 years ago

wdeconinck commented 12 years ago

Coordinates are now matched using a Hilbert Spacefilling curve, with prescribed level. This will avoid the boost::hash collisions that were occurring sometimes. Increasing the level of the Hilbert curve, increases the number of unique bins a coordinate can fall in. 16 levels for a 2D curve, leads to uint_max() equally sized bins. This precision may not be enough to match large meshes with clustering, hence issue #196.

Doxygen documentation has been improved on installation, use of components, and features.

tlmquintino commented 12 years ago

Congratulations! Indeed those collisions where a bit of a worry.

wdeconinck commented 12 years ago

Indeed, the hash-collision "possibility" was a bit worrisome. At least, now if a collision occurs, it just means that you have to refine the level of the hilbert curve. Furthermore, 2 coordinates that have to be matched as 1, but are only accurate to e.g. 6 digits, can be matched with less precision, exactly so that they fall in the same bin.

The only drawback, if it is at all, is that a global bounding-box needs to be created to define the hilbert curve. This is actually very nice statistical information about the mesh, and I wonder if such information should not be always available through the mesh::Mesh component. At the moment I am not really in favor, as the bounding-box is an extra component to make the mesh-tree more complex, and is not absolutely necessary. But please give me your opinion.

This Hilbert spacefilling curve has some other nice properties! Hilbert-indices that are close together in value, are "generally" also close together geometrically.

Possible applications:

Zoltan also offers the possibility to repartition according to this curve. To be seen if our API can support this atm.

tlmquintino commented 12 years ago

Yes I think bounding box information should be present on the Mesh component. It is very useful for many algorithms - and most mesh generators use it as part of the generation process. It should be together with the rest of the Mesh statistics.

I think we should have an Action that ComputeMeshStatistics and stores it in Mesh either as properties() or another Statistics subcomponent. Either way, ComputeMeshStatistics should connected to a trigger on_mesh_update.

wdeconinck commented 12 years ago

There is always a duality in the statistics:

There exists a component "mesh::BoundingBox" which stores the minimum, maximum, and some functionality to extend or build it from a coordinates-field, or region. It could later also have algorithms to find intersections with other bounding boxes.