|
[Sponsors] |
July 6, 2011, 10:26 |
function of volMesh class
|
#1 |
Senior Member
Kathrin Kissling
Join Date: Mar 2009
Location: Besigheim, Germany
Posts: 134
Rep Power: 17 |
Hi!
In the finiteVolume method the volMesh class can be found, which is derived from GeoMesh. Code:
class volMesh : public GeoMesh<fvMesh> { public: // Constructors //- Construct from fvMesh explicit volMesh(const fvMesh& mesh) : GeoMesh<fvMesh>(mesh) {} // Member Functions //- Return size label size() const { return size(mesh_); } //- Return size static label size(const Mesh& mesh) { return mesh.nCells(); } //- Return cell centres const volVectorField& C() { return mesh_.C(); } }; Code:
label size() const { return mesh_.nCells(); } I hope someone can help! Best Kathrin |
|
July 6, 2011, 11:40 |
|
#2 |
Senior Member
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 403
Rep Power: 25 |
Convenience, perhaps.
The size(const Mesh&) member is a static function that doesn't require an actual object of the class to be instantiated, so it's good from the stand-point of efficiency. When the size() function is called, there is an implicit assumption that an object _does_ actually exist, and that the reference to mesh_ is valid. So therefore, re-use the other function! |
|
July 7, 2011, 05:56 |
|
#3 | |
Senior Member
Tomislav Maric
Join Date: Mar 2009
Location: Darmstadt, Germany
Posts: 284
Blog Entries: 5
Rep Power: 21 |
Quote:
Thanks a LOT for the answer, but I'm not sure that it works like that... Code:
static label size(const Mesh& mesh) { return mesh.nCells(); } Code:
template <class MESH> class GeoMesh ... typedef MESH Mesh; ... Also, typedef should be used to shorten names which are complicated for better use, like the volScalarField from GeometricField<blah, blah>... why Mesh from MESH? There's a lot of weird stuff down below in the code, I think. |
||
July 7, 2011, 08:49 |
|
#4 | |
Senior Member
Sandeep Menon
Join Date: Mar 2009
Location: Amherst, MA
Posts: 403
Rep Power: 25 |
Quote:
I also meant that an object of the volMesh class does not need to exist for the static label size(const Mesh& mesh) function to work - so my theory still stands. I agree that the Mesh& reference must be either a primitiveMesh or its derivative, because this is a volMesh, whose intent is to ensure that variables are stored at cells. In contrast, take a look at the equivalent function in pointMesh.H, which stores variables at mesh points, or the areaMesh class in the finiteArea library, which stores them at patch-faces. Things like this are particularly important during the mesh-to-mesh mapping stage, where sizes need to match, depending on the location of the mesh where variables are stored, and yet they must be generic enough to work for all types of meshes - take a look at MapGeometricFields.H to see how this mechanism works. Hope this helps. |
||
July 19, 2011, 08:09 |
|
#5 |
Senior Member
Tomislav Maric
Join Date: Mar 2009
Location: Darmstadt, Germany
Posts: 284
Blog Entries: 5
Rep Power: 21 |
Hi Sandeep,
the forum settings were set for my previous e-mail. It's used for mapping and the sizes need to correspond. Thanks! MESH and Mesh are equivalent types, which kind of confused me (don't know why, don't ask): Code:
56 const MESH& mesh_; 57 58 59 public: 60 61 // Public typedefs 62 63 typedef MESH Mesh; |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Compile problem | ivanyao | OpenFOAM Running, Solving & CFD | 1 | October 12, 2012 09:31 |
latest OpenFOAM-1.6.x from git failed to compile | phsieh2005 | OpenFOAM Bugs | 25 | February 9, 2010 04:37 |
Error with Wmake | skabilan | OpenFOAM Installation | 3 | July 28, 2009 00:35 |
Errors running allwmake in OpenFOAM141dev with WM_COMPILE_OPTION%3ddebug | unoder | OpenFOAM Installation | 11 | January 30, 2008 20:30 |
[blockMesh] Axisymmetrical mesh | Rasmus Gjesing (Gjesing) | OpenFOAM Meshing & Mesh Conversion | 10 | April 2, 2007 14:00 |