[Peter Müller]

Is there any way how I can create a new fvsPatchField so that the new boundary types are all calculated. Same story with fvPatchField works. Just fvsPatchField which does strange things..


surfaceVectorField density2
(
IOobject
(
"density2",
runTime.timeName(),
mesh,
IOobject::READ_IF_PRESENT,
IOobject::AUTO_WRITE
),
mesh,
dimensionedVector( "zero", dimensionSet( 1, -3, 0, 0, 0, 0, 0 ), pTraits<vector>::zero ),
calculatedFvPatchField<vector>::typeName
);

It seams not to be possible to overwrite the boundary types. Independent of what I did.
Defining
surfaceVectorField lala = linearInterpolate(rho*U);
where rho is a volVectorField with only calculated and U has cyclicAMI in it the resulting field "lala" contains the cyclicAMI boundaries. How is this possible?

[andyru]

Do you want to change the boundary type or just overwriting values at this fvsPatch? If latter is the case, you could do something like

            lala().boundaryField()[PatchID()].type()
         == calculatedFvsPatchField<vector>::typeName
        )
        {
            calculatedFvsPatchField<vector>& mylala =
                refCast<calculatedFvsPatchField<vector> >
                (
                    lala().boundaryField()[PatchID()]
                );
            Info << "Now I manipulate my data " << endl;

            mylala.gradient() = ...;

But I am not sure, if this works, since I did that only for fvPatchFields so far.

[hjasak]

This is called a constrained type: types like eg. processor or GGI will be enforced for you because this is required for the code to work properly.


Why would you want to enforce a different type on the constrained boundary anyway?

Hrv

[Peter Müller]

Problem was that I have a boundary for heat transfer using ami-interpolation object. The ami-interpolation should only be used for temperature boundary condition while ie velocity and pressure should be usual wall boundary conditions. Therefore on this boundary I would like to have phi calculated and not of type in the boundary file. This was no problem with 1.5 but is no more easily accesible with 2.2.