[vkrastev]

Hi all,
I'm working with the chtMultiRegionFoam solver in order to manage with heat transfer problems and indeed I found it a useful and quite reliable tool! However, I was just wondering (I've not found discussions about this issue) if the coupling interfaces should be exactly conformal one to each other...I mean, let's say that I want to study a flow in a pipe cooled by an external stream, and let's imagine that the outer surface of the pipe is meshed with quad elements: if I want to mesh the outer fluid region with tetras, could I mesh the externalfluid_to_pipe patch with trias and leave the pipe_to_externalfluid one with quads?

Thank you in advance

V. K.

[mvoss]

hi,

when i use ChtMRF with ICEM-meshes, i have to take care of the face ordering when i write the msh-output (the mesh). From that i would deduce that since the faces on both sides of the interface need the correct ordering they also need the same number of points.

What you are looking for is smth. similar to a GGI, isn´t it?

[vkrastev]

Originally Posted by neewbie

hi,

when i use ChtMRF with ICEM-meshes, i have to take care of the face ordering when i write the msh-output (the mesh). From that i would deduce that since the faces on both sides of the interface need the correct ordering they also need the same number of points.

What you are looking for is smth. similar to a GGI, isn´t it?

Hi, and thanks for the reply! I don't know how actually the GGI works, but what I was wondering is if the mapping algorithm of chtMRF takes care of the cell-face consistency between the two interfaces or not. Judging from your experience (I don't use ICEM as meshing software: with ANSA I simply build two meshes separately but with the same surface mesh at the coupling interface and all works perfectly) it seems like consistency is not an optional...This is not a huge problem, but simply reduces a bit solver's flexibility in terms of how the meshes have to be built. Out of curiosity, what kind of meshes do you use for your chtMRF cases?

Regards

V.

[mvoss]

You´re welcome.
GGI-general grid interface (interpolates between unconformal meshes)
Since the geometries for chtMRF "normaly" are simple, i use the block-structured meshes, so ICEM is the weapon of choice.
But since, like you said correctly, consistency isn´t optional, i am forced to use the high meshresolution also within the solid regions . So, actually a tet-approach would be better...

[vkrastev]

Originally Posted by neewbie

You´re welcome.
GGI-general grid interface (interpolates between unconformal meshes)
Since the geometries for chtMRF "normaly" are simple, i use the block-structured meshes, so ICEM is the weapon of choice.
But since, like you said correctly, consistency isn´t optional, i am forced to use the high meshresolution also within the solid regions . So, actually a tet-approach would be better...

Ok, I think that the point is clear now! Many thanks once again!

V.

[M3hdi]

Hi foamers,

I would liketo resurrect the topic "Non-conformal coupling interfaces in chtMultiRegionFoam"

It seems that OF2.1.x can manage the non-conformal coupling interfaces using the AMI interpolation. I think it's supported because one can find the possibility using "nearestPatchFaceAMI" as sampling mode in the definition of boundaries between regions :

fluidExt_to_solidExt
{
type mappedWall;
nFaces 4160;
startFace 564152;
sampleMode nearestPatchFaceAMI;
sampleRegion solidExt;
samplePatch solidExt_to_fluidExt;
offsetMode uniform;
offset ( 0 0 0 );
}

Unfortunately, I did not succeed in running a test-case I get the following error :

Time = 1


Solving for fluid region fluidExt
DILUPBiCG: Solving for Ux, Initial residual = 1, Final residual = 0.0020107641, No Iterations 2
DILUPBiCG: Solving for Uy, Initial residual = 1, Final residual = 0.0075065322, No Iterations 2
DILUPBiCG: Solving for Uz, Initial residual = 0.99998484, Final residual = 0.00050047687, No Iterations 2


--> FOAM FATAL ERROR:
The send and receive data is not the same length. sendProcs:0 recvProcs:4160

From function mapDistribute::mapDistribute(const labelList&, const labelList&)
in file meshes/polyMesh/mapPolyMesh/mapDistribute/mapDistribute.C at line 700.

FOAM aborting

#0 Foam::error:rintStack(Foam::Ostream&) in "/opt/openfoam210/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1 Foam::error::abort() in "/opt/openfoam210/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2 Foam::mapDistribute::mapDistribute(Foam::List<int> const&, Foam::List<int> const&) in "/opt/openfoam210/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#3 Foam::mappedPatchBase::calcMapping() const in "/opt/openfoam210/platforms/linux64GccDPOpt/lib/libmeshTools.so"
#4 Foam::compressible::turbulentTemperatureCoupledBaf fleMixedFvPatchScalarField::updateCoeffs() in "/opt/openfoam210/platforms/linux64GccDPOpt/lib/libcompressibleTurbulenceModel.so"
#5 Foam::mixedFvPatchField<double>::evaluate(Foam::UP stream::commsTypes) in "/opt/openfoam210/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#6 Foam::mixedEnthalpyFvPatchScalarField::updateCoeff s() in "/opt/openfoam210/platforms/linux64GccDPOpt/lib/libbasicThermophysicalModels.so"
#7 Foam::fvMatrix<double>::fvMatrix(Foam::GeometricFi eld<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::dimensionSet const&) in "/opt/openfoam210/platforms/linux64GccDPOpt/bin/chtMultiRegionSimpleFoam"
#8 Foam::tmp<Foam::fvMatrix<double> > Foam::fvm::Sp<double>(Foam:imensionedField<doubl e, Foam::volMesh> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) in "/opt/openfoam210/platforms/linux64GccDPOpt/bin/chtMultiRegionSimpleFoam"
#9 Foam::radiation::radiationModel::Sh(Foam::basicThe rmo&) const in "/opt/openfoam210/platforms/linux64GccDPOpt/lib/libradiationModels.so"
#10
in "/opt/openfoam210/platforms/linux64GccDPOpt/bin/chtMultiRegionSimpleFoam"
#11 __libc_start_main in "/lib/libc.so.6"
#12
in "/opt/openfoam210/platforms/linux64GccDPOpt/bin/chtMultiRegionSimpleFoam"
Abandon


Is someone can help me figure out the problem ?

Thank you in advance
Mahdi

[tehache]

In case someone else is still working on this:

I THINK (but it is not well tested yet) the solution is to modify the updateCoeffs() function of the coupling boundary field derived from temperatureCoupledBase to use the ami interpolator instead of the distMap, something like this:

================================================== ====
// Force recalculation of mapping and schedule

tmp<scalarField> nbrIntFld_unmapped=nbrField.patchInternalField();
scalarField nbrKDelta_unmapped(nbrField.kappa(nbrField)*nbrPat ch.deltaCoeffs());
tmp<scalarField> K2_unmapped=nbrField.kappa(nbrField);

scalarField nbrIntFld, nbrKDelta,K2;

if(mpp.mode() != mappedPatchBase::NEARESTPATCHFACEAMI) {
const mapDistribute& distMap = mpp.map();
nbrIntFld=nbrIntFld_unmapped;
distMap.distribute(nbrIntFld);
nbrKDelta=nbrKDelta_unmapped;
distMap.distribute(nbrKDelta);
K2=K2_unmapped;
distMap.distribute(K2);
}
else {
const AMIPatchToPatchInterpolation& ami=mpp.AMI();
nbrIntFld=ami.interpolateToSource(nbrIntFld_unmapp ed);
nbrKDelta=ami.interpolateToSource(nbrKDelta_unmapp ed);
K2=ami.interpolateToSource(K2_unmapped);
}

================================================== ====

Currently this seems to be working for me - but, as said, no guarantee, and not well tested yet - just an idea.

[anothr_acc]

Originally Posted by tehache

In case someone else is still working on this:

I THINK (but it is not well tested yet) the solution is to modify the updateCoeffs() function of the coupling boundary field derived from temperatureCoupledBase to use the ami interpolator instead of the distMap, something like this:

================================================== ====
// Force recalculation of mapping and schedule

tmp<scalarField> nbrIntFld_unmapped=nbrField.patchInternalField();
scalarField nbrKDelta_unmapped(nbrField.kappa(nbrField)*nbrPat ch.deltaCoeffs());
tmp<scalarField> K2_unmapped=nbrField.kappa(nbrField);

scalarField nbrIntFld, nbrKDelta,K2;

if(mpp.mode() != mappedPatchBase::NEARESTPATCHFACEAMI) {
const mapDistribute& distMap = mpp.map();
nbrIntFld=nbrIntFld_unmapped;
distMap.distribute(nbrIntFld);
nbrKDelta=nbrKDelta_unmapped;
distMap.distribute(nbrKDelta);
K2=K2_unmapped;
distMap.distribute(K2);
}
else {
const AMIPatchToPatchInterpolation& ami=mpp.AMI();
nbrIntFld=ami.interpolateToSource(nbrIntFld_unmapp ed);
nbrKDelta=ami.interpolateToSource(nbrKDelta_unmapp ed);
K2=ami.interpolateToSource(K2_unmapped);
}

================================================== ====

Currently this seems to be working for me - but, as said, no guarantee, and not well tested yet - just an idea.

Hi tehache,

Did this work for you? I am doing the same thing now and find myself investigating AMI, GGI with chtMultiRegion solvers.

Best regards,

Mark.

[tehache]

Hi Mark,

If I remember correctly, the problems were only with 2.1, and in 2.2 everything is working out of the box.
Give it a try, and please let us know if there are still problems.
I am happily using the AMI interpolator currently without trouble.

[ayoros]

Hi Mark and Tehache,

Correct me if I'm wrong, but with nearestPatchFaceAMI, both boundaries must be of the same global shape, even if their meshes are different.

It cannot handle cases where boundary A is partially overlapping boundary B.

If I'me wrong, please let me know !

Thanks,
Fabien

[anothr_acc]

Originally Posted by tehache

Hi Mark,

If I remember correctly, the problems were only with 2.1, and in 2.2 everything is working out of the box.
Give it a try, and please let us know if there are still problems.
I am happily using the AMI interpolator currently without trouble.

Hi Tehache and Ayoros,

I think the global shape does need to be the same. I think that at the moment I can couple between dissimilar meshes with identical global shape as long as they are flat. However, coupling between curved surfaces is giving me trouble. Say, a pair of coincident cylinders: on the curved faces I appear to be getting no coupling for heat but the flat faces do show coupling.

Do you know if this is normal behaviour, ie, does nearestPatchFaceAMI work with curvature?

Best regards,

Mark.

[tehache]

nearestPatchFaceAMI works fine for me with curvature, I have coupled cylinder walls. I have no clue what could be going wrong in your case ...

[anothr_acc]

Originally Posted by tehache

nearestPatchFaceAMI works fine for me with curvature, I have coupled cylinder walls. I have no clue what could be going wrong in your case ...

Nor do I. I created a simple test case: region leftCopper has a coarse mesh with curved end. region rightCopper has a fine mesh with curved end coincident with the curved end of region left copper. This solves nicely with chtMultiRegionSimpleFoam (strangely, adding layers between then accelerated convergence!).

Conversely, the real problem I'm working on consists of two concentric cylinders: the inner cylinder (`plate') is solid; the outer cylinder ('can') mates with the external, curved surface of the inner cylinder. If I use `layers' to simulate a glue layer between them, applying heat to the inner cylinder causes its temperature to rise with iteration number and there is hardly any coupling to the outer cylinder. If I remove the `layers', it's fine!

I'm using, for example:

can/polyMesh/boundary:
canToPlate { type mappedWall; sampleMode nearestPatchFaceAMI; 
sampleRegion plate; samplePatch plateToCan; }

plate/polyMesh/boundary:
plateToCan { type mappedWall; sampleMode nearestPatchFaceAMI; 
sampleRegion can; samplePatch canToPlate; }

 0/can/T:
canToPlate { 
type compressible::turbulentTemperatureCoupledBaffleMixed;
Tnbr T; thicknessLayers (0.1E-3); kappaLayers (235); kappa solidThermo; 
kappaName glue;
}

 0/plate/T:
plateToCan { type compressible::turbulentTemperatureCoupledBaffleMixed;
Tnbr T; kappa solidThermo; neighbourFieldName T; kappaName glue;
thicknessLayers (0.1E-3); kappaLayers (235);
}

Looking at that, I'm missing a `neighbourFieldName T' from the 0/can/T entry. I wonder if that is the problem..... I'll test it.

Is this the way you are running yours?

Thanks,

Mark.

[tehache]

Hi Mark,

As far as I can see (and sometimes I cant see very far inside OpenFoam...) the turbulentTemperatureCoupledBaffleMixed BC does not use or even read the layer parameters you are giving, so this should not have any effect at all?

[zfaraday]

Hello Mark!

Could you please upload the test case you talk about? I'm curious about the question of the layers that you relate.

Thanks,

Alex

[anothr_acc]

Ooooo! I just ran the same job; one as a serial job, one as a parallel job. The two cases are generating different results. Watch this space.....

[anothr_acc]

I can confirm the parallel job produces different results from the serial job. I will try get my example case on here: the problem is it shows a subtle change while my commercial case shows a huge difference. I'll try tweak the simple case to generate obviously different results between serial and parallel solutions. This is on OF2.3.0.