[kathrin_kissling]

Hi!

In the finiteVolume method the volMesh class can be found, which is derived from GeoMesh.

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();
        }
};

Obviously it adds the function size, which is not present in fvMesh class. But instead of just doing

        label size() const
        {
            return mesh_.nCells();
        }

the above mentioned is done. So now my question is why go generic before actually doing the operation? I'm really sure I'm missing something.

I hope someone can help!

Best

Kathrin

[deepsterblue]

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!

[tomislav_maric]

Originally Posted by deepsterblue

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!

Hi Sandeep!

Thanks a LOT for the answer, but I'm not sure that it works like that...

static label size(const Mesh& mesh)
{
            return mesh.nCells();
}

This means that a reference to a Mesh& has to exist (object has to exist!) and it has to be primitiveMesh or its child, because primitiveMesh implements the nCells() method. "Mesh" comes from GeoMesh, where it is typedefed from MESH, which is a template of GeoMesh. This is also weird...

template <class MESH>
class GeoMesh

... 

typedef MESH Mesh;  

...

So basically, although MESH can be faMesh, fvMesh, etc, but for the volMesh, it can only be primitiveMesh or fvMesh, because of the nCells(), so the object exists.

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.

[deepsterblue]

Originally Posted by tomislav_maric

static label size(const Mesh& mesh)
{
    return mesh.nCells();
}

This means that a reference to a Mesh& has to exist (object has to exist!) and it has to be primitiveMesh or its child, because primitiveMesh implements the nCells() method. "Mesh" comes from GeoMesh, where it is typedefed from MESH, which is a template of GeoMesh. This is also weird...

I'm not talking about the reference to Mesh& (which, of course, must be valid for the static function to work properly), but the reference: const MESH& mesh_; which is a protected member of the GeoMesh class - _that_ has to be valid for the label size() function to work.

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.

[tomislav_maric]

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):

 56         const MESH& mesh_;
 57 
 58 
 59 public:
 60 
 61     // Public typedefs
 62 
 63         typedef MESH Mesh;

Of course, since the method is static it can be called without the object of volMesh being defined, but there has to be some Mesh to get the size from. I just had no idea that this is used for mapping, I only figured that the GeoMesh is a kind of a template wrapper for various types of meshes. Thanks a lot again!