[psosnows]

Greetings,

I believe that there is a problem in implementation of the function patchInternalField().

The distribution is OpenFoam-1.7.1.

The problem was discovered while working on updateCoeffs() function of derivedFvPatchField (derived from mixedFvPatchField):

void Foam::myFvPatchScalarField::updateCoeffs()
{
        // <some code>

        const scalarField& thisIntField = patchInternalField();
        Info << thisIntField << endl;

        // <some more code>
}

In the log we should obtain values of internal field next to the studied patch (in tested case they were set to 300).

Instead, some cells contain zero value.

value nonuniform List<scalar> 
2160
(
6.92193e-310
6.92193e-310
0
0
300
300
300
<...>
);

The mesh was generated using blockMesh. The geometry is shown in the figure attached. Mesh has only 2 patches- the outside one and the inside one.

New boundary condition is applied only on the inner patch.
Anomalies appear only on the faces that are next to the edges, selective, not all. Usually several first ones (like in the example above).

If the "inner" patch is divided into 6 ones, with applied new derivedBC, anomalies are not observed.

Presented usage of the function is quite basic- this drives to conclusion that there is something wrong deeper in the code. Please this bug into consideration.

I would also be very grateful for any other possible explanation of the described problem.

Best,
Pawel S

[chegdan]

Did this get resolved? Maybe you should report it directly to http://www.openfoam.com/bugs/

and/or

http://sourceforge.net/apps/mantisbt..._view_page.php


Cheers,

Dan

[Arnoldinho]

Pawel,

did you create a bug report for this? I have not been able to find one...

At the moment, I am facing the same problem (using OF 1.6-ext), as patch values calculated by patchInternalField() are different from internal field values in the patch near cells.
Or did you find a solution for this in the meantime?

Arne

Edit: Could someone check if the following is right or wrong:

Unw.boundaryField()[patchi] = U.boundaryField()[patchi].patchInternalField();

I'd like to compute U at the patch nearest cells and store it to a Unw volVectorField.

[Arnoldinho]

Ok, having a deeper look at my results, I can so far state that the "bug" in my case only resulted from the interpolation/display scheme in ParaView:

Values from U.boundaryField()[patchi].patchInternalField() were different from U internalField values at regarded probe locations, because ParaView normally seems to use (mesh) point values instead of cell values for display. Using a CellDatatoPointData filter before setting the probe location in contrast results in identical values.

Arne

[TimG]

Hi,

i am facing exactly the same Problem as Pawel does. I also get four wrong values as the first entries in my Field list.
Is there a Solution to this? Is it even a Bug or did i do something wrong?

Cheers, Tim

[psosnows]

Hello Tim,

this issue disappeared when I moved to OF-2.0.0. In the end I did not find out what caused it, but used a "walk around".

You can create a function and use it instead of patchInternalField
In the .H file:

virtual tmp<scalarField> ppatchInternalField() const;

In the .C file:

Foam::tmp<Foam::scalarField> Foam::NAME_OF_YOUR_BOUNDARY_CONDITION::ppatchInternalField() const
{
	tmp<scalarField> tField(new scalarField(size()));
	scalarField& refF=tField();
	forAll(patch().faceCells(),cellI)
	{
		refF[cellI]=(*this).internalField()[patch().faceCells()[cellI]];
	}
	return tField;
}

This one does exactly the same thing as original one, but did not cause the problem mentioned (note that OF function is a template, here you have direct specification of the type). You simply use it instead patchInternalField(). I changed the name just to know that I am using my own code, not the standard OF stuff. If you like, there should be no problem for simply overloading original function.

Hope it helps a bit.
Best,
Pawel