Architectural Meeting 26Jan2006 @ KULeuven
Moving to GCC 3.4
Next Monday we'll be moving from GCC 3.3 to GCC 3.4.
- Must remember to re-compile all dependencies that use c++ like log4cpp and cppunit
- Must clear the ccache
A ticket has been added for this #87
Move Meshes into a server
To the final 2.0 release we'll move all the meshes into a webserver. A ticket has been added for this #88
- Meshes will be removes from the subversion repository.
- COOLFluiD might be able to download automatically the meshes
Meshes have a naming standard:
[topology]-[fvm/fsm]-[nodes].[extension]
Example: cube-fsm-500n.CFmesh or falcon-fvm-24kn.hdf5
- Implement automatic de/compression of files on the file, so we can store meshes compressed. Using zlib.
A ticket has been added for this #89
Synchronize extra data in parallel
1. Nodes and State view
The partitioning phase needs to be adjusted to treat nodes equally as the states already are. The border nodes need to be partitioned so not to be owned by both CPUs. There will be a datahandle "nodesdata" that contains the pre-allocated memory for the node-RealVector object.
2. Allow syncing of extra node and state associated data
The parallel vector will be extended to allow syncing of another storage re-using the distribution pattern (the base type stays the same, e.g. CFreal).
The datahandle needs be adjusted to have an additional constructor taking another datahandle from which the sync pattern is re-used. Internally both datahandles point to the same parallel vector.
A syncAll method will be added allowing synchronization of all coupled datahandles, thus for instance synchronizing all the state related data.
3. Possibly simplify GLOBAL and LOCAL datahandles
The difference between LOCAL and GLOBAL datahandles could be removed as we agreed that the parallel communication pattern is directly associated with either states or nodes.
We will wait on this issue to see if this extra functionality will ever be needed.
Better interaction between Mesh reading /partition with the other numerics
We need a better description of which data is needed in the future so that different components can store it for latter.
An example is the connectivity which is built by the mesh reading and then discarded. Another example is the knowledge of the overlap size.
