[Zeppo]

While scanning the source code of OpenFoam 4.x I see this file files which lists sources to be build into finiteVolume library:

//--- src/finiteVolume/Make/files ---
...
finiteVolume/fvc/fvcFlux.C
...
LIB = $(FOAM_LIBBIN)/libfiniteVolume

Among others it lists fvcFlux.C file:

//--- src/finiteVolume/fvc/fvcFlux.C ---
#include "fvcFlux.H"
#include "surfaceInterpolate.H"
...
Foam::tmp<Foam::surfaceScalarField> Foam::fvc::flux
(
    const volVectorField& vvf
)
{
    return scheme<vector>
    (
        vvf.mesh(),
        "flux(" + vvf.name() + ')'
    )().dotInterpolate(vvf.mesh().Sf(), vvf);
}
...

As you can see here, to compile this file a compiler has to be given complete definition of volVectorField type. Otherwise it can't check if, for example, the call vvf.mesh() is valid or not. It has to see volVectorField definition including all volVectorField's member functions. Basically it can be done via inclusion of corresponding header file (.h-file). There're two .h-files included into fvcFlux.C: fvcFlux.H and surfaceInterpolate.H

//--- src/finiteVolume/fvc/fvcFlux.H ---
#include "volFieldsFwd.H"
#include "surfaceFieldsFwd.H"
...

//--- src/finiteVolume/interpolation/surfaceInterpolation/surfaceInterpolation/surfaceInterpolate.H
#include "tmp.H"
#include "volFieldsFwd.H"
#include "surfaceFieldsFwd.H"
#include "surfaceInterpolationScheme.H"
#include "one.H"
...

Both fvcFlux.h and surfaceInterpolate.H in turn include volFieldsFwd.H:

//--- src/finiteVolume/fields/volFields/volFieldsFwd.H
#include "fieldTypes.H"

class volMesh;

template<class Type>
class fvPatchField;

template<class Type, template<class> class PatchField, class GeoMesh>
class GeometricField;

typedef GeometricField<scalar, fvPatchField, volMesh> volScalarField;
typedef GeometricField<vector, fvPatchField, volMesh> volVectorField;
typedef GeometricField<sphericalTensor, fvPatchField, volMesh>
    volSphericalTensorField;
typedef GeometricField<symmTensor, fvPatchField, volMesh> volSymmTensorField;
typedef GeometricField<tensor, fvPatchField, volMesh> volTensorField;
...

volFieldsFwd.H contains only forward declaration (incomplete definition) of volScalarField (which is merely typedefed GeometricField<scalar, fvPatchField, volMesh>) and it is not enough for the compiler to compile fvcFlux.C. I looked through the other included files to find that none of them contains the definition of GeometricField<scalar, fvPatchField, volMesh> (which is located in src/OpenFOAM/fields/GeometricFields/GeometricField.GeometricField.H). Have I looked over something?

[Tobi]

Hi Zeppo,

nice post (clear and with all information). Here, you need only the forward declaration nothing more. Why? It is easy, we are building libraries and for that the compiler just need to know the class but not the definition of classes (just needed if you make an instance and hence you need to allocate memory).

[Zeppo]

Tobias, I don't think your answer is correct. Look at fvcFlux.C ance again:

//--- src/finiteVolume/fvc/fvcFlux.C ---
#include "fvcFlux.H"
#include "surfaceInterpolate.H"
...
Foam::tmp<Foam::surfaceScalarField> Foam::fvc::flux
(
    const volVectorField& vvf
)
{
    return scheme<vector>
    (
        vvf.mesh(),
        "flux(" + vvf.name() + ')'
    )().dotInterpolate(vvf.mesh().Sf(), vvf);
}
...

At the point where vvf.mesh() is invoked the compiler must know the complete definition of the vvf's type for many reasons:
1. To ensure that the very method volVectorField::mesh() do exist. If not (or it is private/protected), it searches for mesh() in volVectorField's base classes.
2. If function mesh() is found, the compiler must know it's return type so that it can ensure that the return type matches (possible with additional conversion) the type of the input parameter for function scheme<vector>:

//--- src/finiteVolume/interpolation/surfaceInterpolation/surfaceInterpolation/surfaceInterpolate.H
...
//- Return weighting factors for scheme given from Istream
template<class Type>
static tmp<surfaceInterpolationScheme<Type>> scheme
(
    const fvMesh& mesh,
    Istream& schemeData
);
...

And when a compiler compiles the source file into the object file the compiler doesn't really care much what the object file will be used for later on. It is the linker's job to build library or executable from the object files.
So the question is still open: how the compiler can "see" the definition of GeometricField<scalar, fvPatchField, volMesh>? I can't.

[Tobi]

Maybe your are correct if you say that I am wrong... I have not time to check it in such detail. But here is the way it should be. First of all. The method volVectorField::mesh does not exist because the volVectorField is just a typedef from the GeometricField and even this has no function called mesh(). You have to dig deeper because the ::mesh() function you are referring to is inherit by the DimensionedField class.

The problem you mentioned, that the compiler need to know everything is correct (here I was wrong). But luckily it knows everything. The first stuff that the compiler gets to know is the pre-compiled library called libOpenFOAM.so (Make/options).

The volFields are included in line 231 in the Make/files file (src/finiteVolume) and here the compiler gets all information about the field (how they are build and which function is inherit by the classes).

The compilation of you file fvcFlux.C comes in line 395. So the compiler knows the fields.

[Zeppo]

Believe me or not, Tobias, volVectorField::mesh() is literally the same as GeometricField<scalar, fvPatchField, volMesh>::mesh(). If volVectorField::mesh() does not exist, GeometricField<scalar, fvPatchField, volMesh>::mesh() does not exist either.

While a compiler does its job compiling a source file it doesn't care about any object code (object files (.o), static libraries (.a), shared libraries (.so)). Compiler goes in loop though all files listed in Make/files compiling each file independently. To be more specific, it is not a source file, it is a compilation unit to be compiled which is what the compiler see when the content of all #includes have been inserted into the source file by a preprocessor. fvcFlux.C and volFields.C are in different compilation units and don't see each other. Source files can ever be compiled in parallel independently.

When all files have been compiled into object files, the linker teakes over building either a library or executable.

[Tobi]

Hello Sergei,

I am sorry for the non-helpful answers.

1. You 're right, the things that I wrote above are not correct. The line in which we start the compiling of fvcFlux.C is not really important because each file is compiled as an own library » .o «
2. The compiler has to know the class definition of the volVectorField
3. Of course the volVectorField can call mesh(), based on the derivatives. I just wanted to make clear that the mesh() function is defined in the DimensionedField.H file/class.

But now, I have (hopefully) figured out the answer to your question. If we delete the whole library

src
cd finiteVolume
wclean

and remove all entries in the Make/files file except of fvcFlux.C, we see what happens. After excecuting wmake libso we get:

shorty@finiteVolume: wmake libso 
/home/shorty/OpenFOAM/OpenFOAM-4.x/src/finiteVolume
wmakeLnInclude: linking include files to ./lnInclude
Making dependency list for source file finiteVolume/fvc/fvcFlux.C
g++ -std=c++0x -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -O3  -DNoRepository -ftemplate-depth-100 -I/home/shorty/OpenFOAM/OpenFOAM-4.x/src/triSurface/lnInclude -I/home/shorty/OpenFOAM/OpenFOAM-4.x/src/meshTools/lnInclude  -IlnInclude -I. -I/home/shorty/OpenFOAM/OpenFOAM-4.x/src/OpenFOAM/lnInclude -I/home/shorty/OpenFOAM/OpenFOAM-4.x/src/OSspecific/POSIX/lnInclude   -fPIC -c finiteVolume/fvc/fvcFlux.C -o /home/shorty/OpenFOAM/OpenFOAM-4.x/platforms/linux64GccDPInt32Opt/src/finiteVolume/finiteVolume/fvc/fvcFlux.o
g++ -std=c++0x -m64 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -O3  -DNoRepository -ftemplate-depth-100 -I/home/shorty/OpenFOAM/OpenFOAM-4.x/src/triSurface/lnInclude -I/home/shorty/OpenFOAM/OpenFOAM-4.x/src/meshTools/lnInclude  -IlnInclude -I. -I/home/shorty/OpenFOAM/OpenFOAM-4.x/src/OpenFOAM/lnInclude -I/home/shorty/OpenFOAM/OpenFOAM-4.x/src/OSspecific/POSIX/lnInclude   -fPIC -shared -Xlinker --add-needed -Xlinker --no-as-needed /home/shorty/OpenFOAM/OpenFOAM-4.x/platforms/linux64GccDPInt32Opt/src/finiteVolume/finiteVolume/fvc/fvcFlux.o -L/home/shorty/OpenFOAM/OpenFOAM-4.x/platforms/linux64GccDPInt32Opt/lib \
    -lOpenFOAM -ltriSurface -lmeshTools  -o /home/shorty/OpenFOAM/OpenFOAM-4.x/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so
'/home/shorty/OpenFOAM/OpenFOAM-4.x/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so' is up to date.

I highlighted the important part. Here, wmake links all needed header files into the lnInclude folder that is also included during the compilation (UserGuide):

3.2.2.1    Including headers

   
The compiler searches for the included header files in the following order, specified with the -I option in wmake: 
the $WM_PROJECT_DIR/src/OpenFOAM/lnInclude directory;
a local lnInclude directory, i.e. newApp/lnInclude;
the local directory, i.e. newApp;
platform             dependent             paths             set             in files in the $WM_PROJECT_DIR/wmake/rules/$WM_ARCH/ directory, e.g. /usr/X11/include and $(MPICH_ARCH_PATH)/include;
other directories specified explicitly in the Make/options file with the -I option.

• The typedef of volVectorField is in the lnInclude/volFieldsFwd.H (but we have again a forwarded class definition).
• After I read your thread again, I think you are at the same point at the moment
• The fact that we also include the folder src/OpenFOAM/lnInclude should be the anwer. Here we find the GeometricField, DimensionedField header and source files and hence the definition of volVectorField is available.

Two things that I learned

• In the topics where I am not so convinced, I should first check it in more detail before I post an answer
• I also forgot that wmake include the OpenFoam/lnInclude folder

I hope that this is now the answer to your question and I am sorry for the first two useless answers.


To sum up:

You were right in all points and the missing definition comes from the header files that are included automatically by wmake (src/OpenFoam/lnInclude)

[Zeppo]

Originally Posted by Tobi

I highlighted the important part. Here, wmake links all needed header files into the lnInclude folder that is also included during the compilation (UserGuide):

3.2.2.1    Including headers
The compiler searches for the included header files in the following order, specified with the -I option in wmake: 
the $WM_PROJECT_DIR/src/OpenFOAM/lnInclude directory;
a local lnInclude directory, i.e. newApp/lnInclude;
the local directory, i.e. newApp;
platform             dependent             paths             set             in files in the $WM_PROJECT_DIR/wmake/rules/$WM_ARCH/ directory, e.g. /usr/X11/include and $(MPICH_ARCH_PATH)/include;
other directories specified explicitly in the Make/options file with the -I option.

These are the paths (folders in a file system) where a preprocessor (which is run by a compiler in the beginnig of compilation) searches for the files which were declared with #include directive in a source file (fvcFlux.C in my case):

//--- src/finiteVolume/fvc/fvcFlux.C ---
#include "fvcFlux.H"
#include "surfaceInterpolate.H"
...
Foam::tmp<Foam::surfaceScalarField> Foam::fvc::flux
(
    const volVectorField& vvf
)
{
    return scheme<vector>
    (
        vvf.mesh(),
        "flux(" + vvf.name() + ')'
    )().dotInterpolate(vvf.mesh().Sf(), vvf);
}
...

The preprocessor sees these directives

#include "fvcFlux.H"
#include "surfaceInterpolate.H"

and tries to find files fvcFlux.H and surfaceInterpolate.H in the directories mentioned above in your list. If the files are found their content is put into the source file (actually into the compilation unit formed in RAM) and compiled into the object file.

Originally Posted by Tobi

Two things that I learned

• In the topics where I am not so convinced, I should first check it in more detail before I post an answer

I hope that this is now the answer to your question and I am sorry for the first two useless answers

Anyway, thank you for making attempts to help.
I don't have my OpenFoam environment at hand. Please, can you show what you have in fvcFlux.dep file when you have compiled fvcFlux.C. According to the UserGuide this file (fvcFlux.dep) contains a list of files which fvcFlux.C depends on. Here the cite from UserGuide:

On execution, wmake builds a dependency list file with a .dep file extension, e.g. newApp.C.dep in our example, in a $WM_OPTIONS sub-directory of the Make directory, e.g. Make/linuxGccDPInt64Opt.

[Tobi]

I was lying on my couch when I got the point. Based on the include files of the fvcFlux.H, there is no file that includes the header of the GeometricField.H file. Finally I got your question. Hmmm... there is also no fvcFlux.dep file.

• I am not sure but at the end of the fvcFlux.H we include the fvcFluxTemplates.C that includes the fvMesh.H which includes the DimensionedField.H. Finally there are a lot of more headers that are included then. http://cpp.openfoam.org/v4/a05839.html

• I found it after I compared it with 2.3.1 (here it was different)

I think this was the missing part. Based on the implementation, doxygen does not show the included fvcFluxTemplates.C file for the fvcFlux.H (file » fvc/fvcFlux.H «)

#ifdef NoRepository
    #include "fvcFluxTemplates.C"
#endif

[Zeppo]

As UserGuide says, fvcFlux.dep should be in your Make/linux64GccDPInt32Opt/

Even if DimensionedField.H was included into fvcFlux.C (through fvcFluxTemplates.C) it wouldn't help much as the compiler still doesn't know that GeometricField is inherited from DimensionedField so the compiler can't allow invocation of any DimensionedField's methods from an object of GeometricField type. Agree?

I am still at the position where I started from: there seems to be no trace of GeometricField.h in fvcFlux.C file.

[Tobi]

Originally Posted by Zeppo

Even if DimensionedField.H was included into fvcFlux.C (through fvcFluxTemplates.C) it wouldn't help much as the compiler still doesn't know that GeometricField is inherited from DimensionedField so the compiler can't allow invocation of any DimensionedField's methods from an object of GeometricField type. Agree?

Yes I agree.

[Tobi]

Dear Zappo,

I checked the *dep file now and indeed there is the GeometricField.H included:

$(OBJECTS_DIR)/finiteVolume/fvc/fvcFlux.C.dep: \
finiteVolume/fvc/fvcFlux.C \
finiteVolume/fvc/fvcFlux.H \
lnInclude/volFieldsFwd.H \
$(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/fieldTypes.H \
$(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/label.H \
$(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/int.H \
$(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/int32.H \
...
$(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/GeometricField.H \
$(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/dimensionedTypes.H \
$(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/dimensionedVector.H \
$(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/dimensionedSphericalTensor.H \
$(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/dimensionedSymmTensor.H \
...
$(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/GeometricField.C \
$(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/GeometricBoundaryField.C \
$(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/emptyPolyPatch.H \
...

In some file it has to be included.

[Zeppo]

Now, it would be a good thing to have someone explain how that $(WM_PROJECT_DIR)/src/OpenFOAM/lnInclude/GeometricField.H got into fvcFlux.C's dependency list. Tobias, any ideas?

[Tobi]

Hello Zappo,

I was searching one hour yesterday to figure out where the place is, that includes the header of GemoetricField.H. Unfortunately I could not find the file. Now I am also very interested how this works. If you figure it out, I would be glad to hear the answer. Maybe wyldckat could know it?