CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM Running, Solving & CFD

Non-conformal coupling interfaces in chtMultiRegionFoam

Register Blogs Members List Search Today's Posts Mark Forums Read

Like Tree3Likes
  • 1 Post By tehache
  • 1 Post By tehache
  • 1 Post By tehache

Reply
 
LinkBack Thread Tools Display Modes
Old   March 18, 2011, 07:20
Question Non-conformal coupling interfaces in chtMultiRegionFoam
  #1
Senior Member
 
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 9
vkrastev is on a distinguished road
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.
vkrastev is offline   Reply With Quote

Old   March 18, 2011, 09:09
Default
  #2
Senior Member
 
Matthias Voß
Join Date: Mar 2009
Location: Berlin, Germany
Posts: 413
Rep Power: 10
mvoss is on a distinguished road
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?
mvoss is offline   Reply With Quote

Old   March 18, 2011, 10:33
Default
  #3
Senior Member
 
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 9
vkrastev is on a distinguished road
Quote:
Originally Posted by neewbie View Post
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.
vkrastev is offline   Reply With Quote

Old   March 18, 2011, 10:42
Default
  #4
Senior Member
 
Matthias Voß
Join Date: Mar 2009
Location: Berlin, Germany
Posts: 413
Rep Power: 10
mvoss is on a distinguished road
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...
mvoss is offline   Reply With Quote

Old   March 18, 2011, 10:53
Default
  #5
Senior Member
 
Vesselin Krastev
Join Date: Jan 2010
Location: University of Tor Vergata, Rome
Posts: 361
Rep Power: 9
vkrastev is on a distinguished road
Quote:
Originally Posted by neewbie View Post
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.
vkrastev is offline   Reply With Quote

Old   November 27, 2012, 12:43
Default
  #6
New Member
 
Join Date: Aug 2011
Location: Paris
Posts: 20
Rep Power: 5
M3hdi is on a distinguished road
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
M3hdi is offline   Reply With Quote

Old   August 26, 2013, 10:33
Default
  #7
Senior Member
 
Thomas Jung
Join Date: Mar 2009
Posts: 100
Rep Power: 7
tehache is on a distinguished road
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 likes this.
tehache is offline   Reply With Quote

Old   July 21, 2014, 11:33
Default
  #8
Member
 
ms
Join Date: Mar 2009
Location: West London
Posts: 42
Rep Power: 7
anothr_acc is on a distinguished road
Quote:
Originally Posted by tehache View Post
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.
anothr_acc is offline   Reply With Quote

Old   July 21, 2014, 12:26
Default
  #9
Senior Member
 
Thomas Jung
Join Date: Mar 2009
Posts: 100
Rep Power: 7
tehache is on a distinguished road
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.
anothr_acc likes this.
tehache is offline   Reply With Quote

Old   July 22, 2014, 12:06
Default
  #10
New Member
 
Join Date: Mar 2009
Posts: 26
Rep Power: 7
ayoros is on a distinguished road
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
ayoros is offline   Reply With Quote

Old   September 23, 2014, 10:00
Default
  #11
Member
 
ms
Join Date: Mar 2009
Location: West London
Posts: 42
Rep Power: 7
anothr_acc is on a distinguished road
Quote:
Originally Posted by tehache View Post
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.
anothr_acc is offline   Reply With Quote

Old   September 29, 2014, 06:24
Default
  #12
Senior Member
 
Thomas Jung
Join Date: Mar 2009
Posts: 100
Rep Power: 7
tehache is on a distinguished road
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 likes this.
tehache is offline   Reply With Quote

Old   October 8, 2014, 08:06
Default
  #13
Member
 
ms
Join Date: Mar 2009
Location: West London
Posts: 42
Rep Power: 7
anothr_acc is on a distinguished road
Quote:
Originally Posted by tehache View Post
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:

Code:
can/polyMesh/boundary:
canToPlate { type mappedWall; sampleMode nearestPatchFaceAMI; 
sampleRegion plate; samplePatch plateToCan; }
Code:
plate/polyMesh/boundary:
plateToCan { type mappedWall; sampleMode nearestPatchFaceAMI; 
sampleRegion can; samplePatch canToPlate; }
Code:
 0/can/T:
canToPlate { 
type compressible::turbulentTemperatureCoupledBaffleMixed;
Tnbr T; thicknessLayers (0.1E-3); kappaLayers (235); kappa solidThermo; 
kappaName glue;
}
Code:
 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.
anothr_acc is offline   Reply With Quote

Old   October 8, 2014, 08:27
Default
  #14
Senior Member
 
Thomas Jung
Join Date: Mar 2009
Posts: 100
Rep Power: 7
tehache is on a distinguished road
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?
tehache is offline   Reply With Quote

Old   October 8, 2014, 08:35
Default
  #15
Member
 
Alex
Join Date: Oct 2013
Posts: 84
Rep Power: 3
zfaraday is on a distinguished road
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
__________________
I'm newbie in OpenFOAM's world and not an English-speaking, so if I make any mistake a correction will be welcome!
zfaraday is offline   Reply With Quote

Old   October 8, 2014, 10:21
Default
  #16
Member
 
ms
Join Date: Mar 2009
Location: West London
Posts: 42
Rep Power: 7
anothr_acc is on a distinguished road
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 is offline   Reply With Quote

Old   October 8, 2014, 13:04
Default
  #17
Member
 
ms
Join Date: Mar 2009
Location: West London
Posts: 42
Rep Power: 7
anothr_acc is on a distinguished road
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.
anothr_acc is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
chtmultiregionFoam - Gradient at Coupling boundary FekrKon OpenFOAM 1 April 2, 2012 11:50
Simple Behavioural Models: Fluid Coupling Chromatix Main CFD Forum 0 February 20, 2010 16:17
Subdomain or Interfaces (CHT) sandeep_tu CFX 8 July 14, 2009 11:06
one/two way coupling of DPM Angela FLUENT 3 April 28, 2008 09:29
grid interfaces kiko FLUENT 0 February 13, 2007 10:28


All times are GMT -4. The time now is 14:25.