[danny123]

Hello Bruno,

Regarding point 1.: yes, I did write a thesis myself a while ago. I do not dare to reread it...

Point 2: I have to correct myself: doing the balance on a reduced by cell volume basis is not possible, since you cannot balance flows reduced by volume, but only flows. You end up getting the same equation system, since if you build the matrix on a "divided by cell volume" basis, you end up to multiply the matrix by that cell volume. I was thinking a little bit too fast....

Point 3:

I mean that there is a an implementation of Laplacian in gaussLaplacianScheme.C and gaussLaplacianSchemes.C, whereas the later is called both for Laplacians of vector fileds (in Ueq) and scalar fields (pEq) and the code is enbedded in a #define statement with these back slash at the end of each line. I have not found such long code lines after #define anywhere else in the OpenFoam code.

Regards,

Daniel

[wyldckat]

Hi Daniel,

Originally Posted by danny123

Point 3:

I mean that there is a an implementation of Laplacian in gaussLaplacianScheme.C and gaussLaplacianSchemes.C, whereas the later is called both for Laplacians of vector fileds (in Ueq) and scalar fields (pEq) and the code is enbedded in a #define statement with these back slash at the end of each line.

As I mentioned before, in "gaussLaplacianScheme.C" is the general implementation and in "gaussLaplacianSchemes.C" is the specialization where the second template term is defined as always being of type "scalar".

But I see your point... let me see if I can find where OpenFOAM uses the general implementation... ah, OK, this is one of those situations where they seem to first implement the generic class, but then only create one specialization. There are a few other times that they did this in OpenFOAM.
In theory, this is a good programming manoeuvre, because this means that you're planning for possible future implementations. Problem might be if you don't test the generic implementation with other situations...

Oh, wait, there is another reason for this: the template class defined in "laplacianScheme.C" is also fully generalized: https://github.com/OpenFOAM/OpenFOAM...lacianScheme.C - which is why the main template class for "gaussLaplacianScheme" is also fully generalized.
Have a look here: https://github.com/OpenFOAM/OpenFOAM...acianSchemes.C - you'll see that the fully generalized Laplacian will take into account creating variants that use "scalar", "symmTensor" and "tensor". But for the Gaussian implementation, the "scalar" has a special implementation, i.e. a specialization.

In review, the generic Laplacian accounts for the following types:

• Primary types: scalar, vector, sphericalTensor, symmTensor, tensor
• Secondary types: scalar, symmTensor and tensor

The Gauss Laplacian also accounts for the same ones:

• Primary types: scalar, vector, sphericalTensor, symmTensor, tensor
• Secondary types: scalar, symmTensor and tensor

But it has a very specialized implementation for the secondary type "scalar", because it can do the calculations a bit differently for this scenario, in a way that is faster to run and/or more numerically efficient. I think I also explained this in a previous post.

Originally Posted by danny123

I have not found such long code lines after #define anywhere else in the OpenFoam code.

It's a fairly common strategy in OpenFOAM: https://github.com/OpenFOAM/OpenFOAM...actionThermo.H

And this one in particular might give a clearer notion of all of the variants that are used for the Laplacian: https://github.com/OpenFOAM/OpenFOAM...nScheme.H#L224

Best regards,
Bruno