CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > Software User Forums > OpenFOAM > OpenFOAM Community Contributions

[swak4Foam] CyclicAMI, groovyBC issues

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

Like Tree2Likes

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   January 27, 2013, 18:15
Default CyclicAMI, groovyBC issues
  #1
Member
 
Sherif Kadry
Join Date: May 2009
Posts: 38
Rep Power: 15
sherifkadry is on a distinguished road
I'm running a simple blade cascade (internal as in turbomachinery) with cyclic AMI on the 'top' and 'bottom' patches, an inlet that is defined as a groovyBC which in turn is a sinosidual shaped inlet velocity that moves with time, trying to simulate basically a passing wake. Now I keep getting this error after doing a reconstructPar not sure what is the cause, or if this is a bug, any help would be greatly appreciated.

Reconstructing FV fields

Reconstructing volScalarFields

gamma
AMI: Creating addressing and weights between 0 source faces and 119 target faces
--> FOAM Warning :
From function AMIInterpolation<SourcePatch, TargetPatch>::checkPatches(const primitivePatch&, const primitivePatch&)
in file lnInclude/AMIInterpolation.C at line 146
Source and target patch bounding boxes are not similar
source box span : (0 0 0)
target box span : (0.193091 0.0297606 0.00939589)
source box : (0 0 0) (0 0 0)
target box : (-1.70644 -0.677052 -0.00469794) (-1.51335 -0.647292 0.00469794)
inflated target box : (-1.71622 -0.686832 -0.0144778) (-1.50357 -0.637512 0.0144778)


--> FOAM FATAL ERROR:
Supplied field size is not equal to target patch size
source patch = 0
target patch = 0
supplied field = 119

From function AMIInterpolation::interpolateToSource(const Field<Type>) const
in file /home/saa2903/OpenFOAM/OpenFOAM-2.1.1/src/meshTools/lnInclude/AMIInterpolation.C at line 1931.

FOAM aborting

#0 Foam::error:rintStack(Foam::Ostream&) in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1 Foam::error::abort() in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2 void Foam::AMIInterpolation<Foam::PrimitivePatch<Foam:: face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::interpolateToSource<double, Foam::combineBinaryOp<double, Foam:lusEqOp<double> > >(Foam::UList<double> const&, Foam::combineBinaryOp<double, Foam:lusEqOp<double> > const&, Foam::List<double>&) const in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#3 Foam::tmp<Foam::Field<double> > Foam::AMIInterpolation<Foam::PrimitivePatch<Foam:: face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::interpolateToSource<double, Foam:lusEqOp<double> >(Foam::Field<double> const&, Foam:lusEqOp<double> const&) const in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#4 Foam::cyclicAMIFvPatch::makeWeights(Foam::Field<do uble>&) const in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#5 Foam::surfaceInterpolation::makeWeights() const in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#6 Foam::surfaceInterpolation::weights() const in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#7 Foam::surfaceInterpolation::makeDeltaCoeffs() const in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#8 Foam::surfaceInterpolation::deltaCoeffs() const in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#9 Foam::fvPatch::deltaCoeffs() const in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#10 Foam::groovyBCFvPatchField<double>::groovyBCFvPatc hField(Foam::fvPatch const&, Foam:imensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) in "/home/saa2903/OpenFOAM/saa2903-2.1.1/platforms/linux64GccDPOpt/lib/libgroovyBC.so"
#11 Foam::fvPatchField<double>::adddictionaryConstruct orToTable<Foam::groovyBCFvPatchField<double> >::New(Foam::fvPatch const&, Foam:imensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) in "/home/saa2903/OpenFOAM/saa2903-2.1.1/platforms/linux64GccDPOpt/lib/libgroovyBC.so"
#12 Foam::fvPatchField<double>::New(Foam::fvPatch const&, Foam:imensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/bin/reconstructPar"
#13 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::GeometricBoundaryField::GeometricB oundaryField(Foam::fvBoundaryMesh const&, Foam:imensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/bin/reconstructPar"
#14 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::readField(Foam::dictionary const&) in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/bin/reconstructPar"
#15 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::readField(Foam::Istream&) in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/bin/reconstructPar"
#16 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::GeometricField(Foam::IOobject const&, Foam::fvMesh const&) in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/bin/reconstructPar"
sherifkadry is offline   Reply With Quote

Old   January 27, 2013, 18:55
Default
  #2
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,224
Rep Power: 49
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by sherifkadry View Post
I'm running a simple blade cascade (internal as in turbomachinery) with cyclic AMI on the 'top' and 'bottom' patches, an inlet that is defined as a groovyBC which in turn is a sinosidual shaped inlet velocity that moves with time, trying to simulate basically a passing wake. Now I keep getting this error after doing a reconstructPar not sure what is the cause, or if this is a bug, any help would be greatly appreciated.

Reconstructing FV fields

Reconstructing volScalarFields

gamma
AMI: Creating addressing and weights between 0 source faces and 119 target faces
--> FOAM Warning :
From function AMIInterpolation<SourcePatch, TargetPatch>::checkPatches(const primitivePatch&, const primitivePatch&)
in file lnInclude/AMIInterpolation.C at line 146
Source and target patch bounding boxes are not similar
source box span : (0 0 0)
target box span : (0.193091 0.0297606 0.00939589)
source box : (0 0 0) (0 0 0)
target box : (-1.70644 -0.677052 -0.00469794) (-1.51335 -0.647292 0.00469794)
inflated target box : (-1.71622 -0.686832 -0.0144778) (-1.50357 -0.637512 0.0144778)


--> FOAM FATAL ERROR:
Supplied field size is not equal to target patch size
source patch = 0
target patch = 0
supplied field = 119

From function AMIInterpolation::interpolateToSource(const Field<Type>) const
in file /home/saa2903/OpenFOAM/OpenFOAM-2.1.1/src/meshTools/lnInclude/AMIInterpolation.C at line 1931.

FOAM aborting

#0 Foam::error:rintStack(Foam::Ostream&) in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#1 Foam::error::abort() in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libOpenFOAM.so"
#2 void Foam::AMIInterpolation<Foam::PrimitivePatch<Foam:: face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::interpolateToSource<double, Foam::combineBinaryOp<double, Foam:lusEqOp<double> > >(Foam::UList<double> const&, Foam::combineBinaryOp<double, Foam:lusEqOp<double> > const&, Foam::List<double>&) const in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#3 Foam::tmp<Foam::Field<double> > Foam::AMIInterpolation<Foam::PrimitivePatch<Foam:: face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::interpolateToSource<double, Foam:lusEqOp<double> >(Foam::Field<double> const&, Foam:lusEqOp<double> const&) const in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#4 Foam::cyclicAMIFvPatch::makeWeights(Foam::Field<do uble>&) const in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#5 Foam::surfaceInterpolation::makeWeights() const in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#6 Foam::surfaceInterpolation::weights() const in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#7 Foam::surfaceInterpolation::makeDeltaCoeffs() const in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#8 Foam::surfaceInterpolation::deltaCoeffs() const in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#9 Foam::fvPatch::deltaCoeffs() const in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/lib/libfiniteVolume.so"
#10 Foam::groovyBCFvPatchField<double>::groovyBCFvPatc hField(Foam::fvPatch const&, Foam:imensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) in "/home/saa2903/OpenFOAM/saa2903-2.1.1/platforms/linux64GccDPOpt/lib/libgroovyBC.so"
#11 Foam::fvPatchField<double>::adddictionaryConstruct orToTable<Foam::groovyBCFvPatchField<double> >::New(Foam::fvPatch const&, Foam:imensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) in "/home/saa2903/OpenFOAM/saa2903-2.1.1/platforms/linux64GccDPOpt/lib/libgroovyBC.so"
#12 Foam::fvPatchField<double>::New(Foam::fvPatch const&, Foam:imensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/bin/reconstructPar"
#13 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::GeometricBoundaryField::GeometricB oundaryField(Foam::fvBoundaryMesh const&, Foam:imensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/bin/reconstructPar"
#14 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::readField(Foam::dictionary const&) in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/bin/reconstructPar"
#15 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::readField(Foam::Istream&) in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/bin/reconstructPar"
#16 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::GeometricField(Foam::IOobject const&, Foam::fvMesh const&) in "/home/saa2903/OpenFOAM/OpenFOAM-2.1.1/platforms/linux64GccDPOpt/bin/reconstructPar"
Haven't worked with AMI yet. Did I understand you correctly: the patch on which you use groovy is NOT an AMI-patch? BUT the groovyBC-patch and the AMI-patch are neighbours (meaning: there are cells of which one face is on the groovy-patch, the other on the AMI-patch).

Could you try replacing the groovyBC-BC with a "mixed" (groovys next relative) and see whether the problem happens also? If yes: I deny all responsibility
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   January 27, 2013, 19:10
Default
  #3
Member
 
Sherif Kadry
Join Date: May 2009
Posts: 38
Rep Power: 15
sherifkadry is on a distinguished road
Quote:
Originally Posted by gschaider View Post
Haven't worked with AMI yet. Did I understand you correctly: the patch on which you use groovy is NOT an AMI-patch? BUT the groovyBC-patch and the AMI-patch are neighbours (meaning: there are cells of which one face is on the groovy-patch, the other on the AMI-patch).

Could you try replacing the groovyBC-BC with a "mixed" (groovys next relative) and see whether the problem happens also? If yes: I deny all responsibility
Thanks for the reply, my apologies for the confusion. The groovyBC is used on the cascade inlet and not the AMI patches on the top and bottom periodic surfaces of the cascade. I have not tried mixed, will try, what I'm attempting to do is apply a inlet velocity that is changing with time and space, basically a passing upstream wake.
I used this case with AMI, and just a regular fixedValue inlet velocity and all was good without any issues with periodicity. The case runs, albeit bombs but the issue is the reconstructPar.
sherifkadry is offline   Reply With Quote

Old   January 27, 2013, 19:18
Default
  #4
Member
 
Sherif Kadry
Join Date: May 2009
Posts: 38
Rep Power: 15
sherifkadry is on a distinguished road
Quote:
Originally Posted by gschaider View Post
Haven't worked with AMI yet. Did I understand you correctly: the patch on which you use groovy is NOT an AMI-patch? BUT the groovyBC-patch and the AMI-patch are neighbours (meaning: there are cells of which one face is on the groovy-patch, the other on the AMI-patch).

Could you try replacing the groovyBC-BC with a "mixed" (groovys next relative) and see whether the problem happens also? If yes: I deny all responsibility
Just for even more clarity here is an image of the domain:

http://i1250.photobucket.com/albums/...ps327a7f7a.png


This case actually works in a serial run. The mesh is 2D.
sherifkadry is offline   Reply With Quote

Old   January 27, 2013, 19:21
Default
  #5
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,224
Rep Power: 49
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by sherifkadry View Post
Thanks for the reply, my apologies for the confusion. The groovyBC is used on the cascade inlet and not the AMI patches on the top and bottom periodic surfaces of the cascade. I have not tried mixed, will try, what I'm attempting to do is apply a inlet velocity that is changing with time and space, basically a passing upstream wake.
I used this case with AMI, and just a regular fixedValue inlet velocity and all was good without any issues with periodicity. The case runs, albeit bombs but the issue is the reconstructPar.
I understand that mixed is not what you want, but to find out whether the problem is groovyBC or the AMI-interpolation you should try it
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   January 27, 2013, 20:11
Default
  #6
Member
 
Sherif Kadry
Join Date: May 2009
Posts: 38
Rep Power: 15
sherifkadry is on a distinguished road
Quote:
Originally Posted by gschaider View Post
I understand that mixed is not what you want, but to find out whether the problem is groovyBC or the AMI-interpolation you should try it
I think I know what it is, it is an AMI issue brought about due to groovyBC, but it is not a bug but an idiotic miss on my part. The sinusoidal profile I specified is not periodic at the inlet patch, and that probably explains it!!!

Thanks for your help.
sherifkadry is offline   Reply With Quote

Old   January 27, 2013, 20:34
Default
  #7
Member
 
Sherif Kadry
Join Date: May 2009
Posts: 38
Rep Power: 15
sherifkadry is on a distinguished road
Quote:
Originally Posted by gschaider View Post
I understand that mixed is not what you want, but to find out whether the problem is groovyBC or the AMI-interpolation you should try it
Ok tried a few things, I thought the issue was the lack of periodicity on my inlet specification via groovyBC. But now it seems to be more than that. So I only applied a groovyBC to my U, and it seems to be the only thing the code has an issue with when I ran reconstructPar with the cyclicAMI.

So reconstructPar will put together p, nut, k and so on, but crash on U. When I switched back to a regular fixedValue with U inlet, reconstructPar worked well. Can send you the case if you are interested further.

I noticed the following message:
--> FOAM Warning :
From function groovyBCFvPatchField<Type>::groovyBCFvPatchField(c onst fvPatch& p,const DimensionedField<Type, volMesh>& iF,const dictionary& dict)
in file groovyBCFvPatchField.C at line 124
No value defined for U on INLET therefore using 180{(0 0 0)}


Guess I might not be using it correctly, say you wanted to specify a vector (Vx,Vy,0) would you do this?
INLET
{
type groovyBC;
variables "Vx=5;Vy=-5;";
valueExpression "vector(Vx,Vy,0)";
value uniform (5 -5 0)
}


?

Last edited by sherifkadry; January 27, 2013 at 20:45. Reason: Discovered further info
sherifkadry is offline   Reply With Quote

Old   January 28, 2013, 08:28
Default
  #8
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,224
Rep Power: 49
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by sherifkadry View Post
Ok tried a few things, I thought the issue was the lack of periodicity on my inlet specification via groovyBC. But now it seems to be more than that.
That is responsible for the blow-up you mentioned in another post I guess

Quote:
Originally Posted by sherifkadry View Post
So I only applied a groovyBC to my U, and it seems to be the only thing the code has an issue with when I ran reconstructPar with the cyclicAMI.

So reconstructPar will put together p, nut, k and so on, but crash on U. When I switched back to a regular fixedValue with U inlet, reconstructPar worked well.
Could you PLEASE try it with "mixed". Use "valueFraction uniform 1" and it should act like a fixedValue. If that doesn't fail then the problem is with groovyBC and I will have a look at it. Otherwise it is a general OpenFOAM-problem

Quote:
Originally Posted by sherifkadry View Post
Can send you the case if you are interested further.
First try mixed

Quote:
Originally Posted by sherifkadry View Post
I noticed the following message:
--> FOAM Warning :
From function groovyBCFvPatchField<Type>::groovyBCFvPatchField(c onst fvPatch& p,const DimensionedField<Type, volMesh>& iF,const dictionary& dict)
in file groovyBCFvPatchField.C at line 124
No value defined for U on INLET therefore using 180{(0 0 0)}


Guess I might not be using it correctly, say you wanted to specify a vector (Vx,Vy,0) would you do this?
INLET
{
type groovyBC;
variables "Vx=5;Vy=-5;";
valueExpression "vector(Vx,Vy,0)";
value uniform (5 -5 0)
}


?
Any value is fine. The problem only occurs during reading. Before solving the equation for the first time the valueExpression will be evaluated
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   January 28, 2013, 09:13
Default
  #9
Member
 
Sherif Kadry
Join Date: May 2009
Posts: 38
Rep Power: 15
sherifkadry is on a distinguished road
Quote:
Originally Posted by gschaider View Post
That is responsible for the blow-up you mentioned in another post I guess



Could you PLEASE try it with "mixed". Use "valueFraction uniform 1" and it should act like a fixedValue. If that doesn't fail then the problem is with groovyBC and I will have a look at it. Otherwise it is a general OpenFOAM-problem



First try mixed



Any value is fine. The problem only occurs during reading. Before solving the equation for the first time the valueExpression will be evaluated
Alright So I tried mixed and same thing happens. Guess this is a FOAM issue, weird thing is that it is still blowing up in parallel and not in serial!! Rather frustrating, any thoughts on how I can abate this issue? Seems it is not a groovyBC issue after all.
sherifkadry is offline   Reply With Quote

Old   January 28, 2013, 09:29
Default
  #10
Member
 
Sherif Kadry
Join Date: May 2009
Posts: 38
Rep Power: 15
sherifkadry is on a distinguished road
Quote:
Originally Posted by gschaider View Post
That is responsible for the blow-up you mentioned in another post I guess



Could you PLEASE try it with "mixed". Use "valueFraction uniform 1" and it should act like a fixedValue. If that doesn't fail then the problem is with groovyBC and I will have a look at it. Otherwise it is a general OpenFOAM-problem



First try mixed



Any value is fine. The problem only occurs during reading. Before solving the equation for the first time the valueExpression will be evaluated
Just in case you're interested in this case further I've shared it here:
https://docs.google.com/file/d/0B6-u...xMb1JkUU0/edit
sherifkadry is offline   Reply With Quote

Old   January 28, 2013, 09:50
Default
  #11
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,224
Rep Power: 49
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by sherifkadry View Post
Alright So I tried mixed and same thing happens. Guess this is a FOAM issue, weird thing is that it is still blowing up in parallel and not in serial!! Rather frustrating, any thoughts on how I can abate this issue? Seems it is not a groovyBC issue after all.
The parallel blowup may or may not be a groovyBC-problem. But it could also be an AMI-problem.

For the reconstruction: try if you can reproduce the behaviour with the simplest blockMesh: top&bottom AMI, left mixed. If that shows the same during reconstruction attach it to a bug-report at http://www.openfoam.org/bugs/
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   November 11, 2013, 04:00
Default
  #12
Member
 
Join Date: Oct 2011
Posts: 37
Rep Power: 13
Peter Müller is on a distinguished road
Hello Guys

I'm just facing the same problem. All the fields I use groovyBC are not possible to reconstruct, since it seams to try to recalculate the AMI-Information but fails in the constructor while searching for source and target faces. My guess is that it tries to construct the AMI-object locally in the processor directories and fails since it's not able to find the complete patch.
Anyway I do not understand why at all it wants to create the whole AMI-object since all I want is that it collects the boundary data and write cyclicAMI on the reconstructed patch.

Any ideas on how to fix this?

Kind regards Peter
Peter Müller is offline   Reply With Quote

Old   November 18, 2013, 19:20
Default
  #13
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,224
Rep Power: 49
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by Peter Müller View Post
Hello Guys

I'm just facing the same problem. All the fields I use groovyBC are not possible to reconstruct, since it seams to try to recalculate the AMI-Information but fails in the constructor while searching for source and target faces. My guess is that it tries to construct the AMI-object locally in the processor directories and fails since it's not able to find the complete patch.
Anyway I do not understand why at all it wants to create the whole AMI-object since all I want is that it collects the boundary data and write cyclicAMI on the reconstructed patch.

Any ideas on how to fix this?

Kind regards Peter
Could you either give an error message or (even better) provide a simple test-case (preferably as a bug-report at the OpenFOAM-extend Mantis). I'm not using AMI so there might be something I'm not aware of
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   January 25, 2018, 12:31
Default
  #14
Senior Member
 
Tom Fahner
Join Date: Mar 2009
Location: Breda, Netherlands
Posts: 606
Rep Power: 30
tomf will become famous soon enoughtomf will become famous soon enough
Send a message via MSN to tomf Send a message via Skype™ to tomf
Hi all,

I seem to have a related error, which I used to analyse this in slightly more depth:

My mesh consists out of a polyhedral outer part and a structured hexahedral inner part. Within the inner part there is another hexahedral part. Between the two inner hexahedral parts there is an AMI interface because of some sloped geometry which would otherwise mess up the structure. The second AMI interface is between the polyhedral part and the outer hexahedral part.

A few attached pictures illustrate the mesh. Unfortunately I cannot show more details of the inner part, but I hope you get the general idea.

The checkMesh result is ok and also the AMI weights are very close to 1:

checkMesh:
Code:
Build  : 5.x-c409ae7d9096
Exec   : checkMesh -noZero -constant
Date   : Jan 24 2018
Time   : 16:08:33
Host   : XXX
PID    : 6230
I/O    : uncollated
Case   : Classified
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations

Create time

Create polyMesh for time = constant

Time = constant

Mesh stats
    points:           11539046
    faces:            23004432
    internal faces:   22441324
    cells:            6184319
    faces per cell:   7.34855
    boundary patches: 13
    point zones:      0
    face zones:       0
    cell zones:       4

Overall number of cells of each type:
    hexahedra:     4447690
    prisms:        0
    wedges:        0
    pyramids:      0
    tet wedges:    0
    tetrahedra:    0
    polyhedra:     1736629
    Breakdown of polyhedra by number of faces:
        faces   number of cells
            7   25248
            8   791560
            9   41682
           10   71630
           11   96625
           12   99844
           13   150242
           14   178539
           15   146425
           16   81391
           17   34452
           18   11879
           19   3387
           20   1015
           21   664
           22   682
           23   484
           24   319
           25   200
           26   176
           27   84
           28   57
           29   26
           30   13
           31   4
           33   1

Checking topology...
    Boundary definition OK.
    Cell to face addressing OK.
    Point usage OK.
    Upper triangular ordering OK.
    Face vertices OK.
   *Number of regions: 3
    The mesh has multiple regions which are not connected by any face.
  <<Writing region information to "constant/cellToRegion"
  <<Writing region 0 with 1021680 cells to cellSet region0
  <<Writing region 1 with 3362256 cells to cellSet region1
  <<Writing region 2 with 1800383 cells to cellSet region2

Checking patch topology for multiply connected surfaces...
                   Patch    Faces   Points                  Surface topology
                     XXX    63812    65016  ok (non-closed singly connected)
             XXXX    54144    56316  ok (non-closed singly connected)
              XXXX     1386     1474  ok (non-closed singly connected)
      XXXX_baffle      594      670  ok (non-closed singly connected)
    XXXX_baffle_shadow      792      871  ok (non-closed singly connected)
                     Top    15336    31062  ok (non-closed singly connected)
                  Domain     6677    14139  ok (non-closed singly connected)
            AMI_Internal   151532   152135  ok (non-closed singly connected)
            AMI_External    74366   145878  ok (non-closed singly connected)
     AMI_XXX_External    34848    35443  ok (non-closed singly connected)
             XXX_Near    34056    34639  ok (non-closed singly connected)
              XXX_far    89529   177986  ok (non-closed singly connected)
     AMI_XXX_Internal    36036    36649  ok (non-closed singly connected)

Checking geometry...
    Overall domain bounding box (-2500 -2500 -5) (2500 2500 300)
    Mesh has 3 geometric (non-empty/wedge) directions (1 1 1)
    Mesh has 3 solution (non-empty) directions (1 1 1)
    Boundary openness (2.66931e-18 1.95825e-17 6.89153e-13) OK.
    Max cell openness = 4.43083e-16 OK.
    Max aspect ratio = 64.3067 OK.
    Minimum face area = 0.000400662. Maximum face area = 3110.68.  Face area magnitudes OK.
    Min volume = 2.00436e-05. Max volume = 108897.  Total volume = 5.89004e+09.  Cell volumes OK.
    Mesh non-orthogonality Max: 58.2852 average: 12.7559
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 2.08391 OK.
    Coupled point location match (average 0) OK.

Mesh OK.

End
Start of simpleFoam run, showing AMI weights (yes different commit, but I tried reconstructing on the cluster and on my own PC):

Code:
Build  : 5.x-da23476f9d01
Exec   : simpleFoam -case fakePath/Classified -parallel
Date   : Jan 24 2018
Time   : 16:33:00
Host   : "XXX"
PID    : 6778
I/O    : uncollated
Case   : Classified
nProcs : 80
Slaves : 
79
(XXX
)

Pstream initialized with:
    floatTransfer      : 0
    nProcsSimpleSum    : 0
    commsType          : nonBlocking
    polling iterations : 0
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create mesh for time = 0


SIMPLE: no convergence criteria found. Calculations will run for 2500 steps.

Reading field p

Reading field U

AMI: Creating addressing and weights between 151532 source faces and 74366 target faces
AMI: Patch source sum(weights) min/max/average = 0.997915, 1.00347, 0.999991
AMI: Patch target sum(weights) min/max/average = 0.992037, 1.00225, 0.999996
AMI: Creating addressing and weights between 34848 source faces and 36036 target faces
AMI: Patch source sum(weights) min/max/average = 1, 1, 1
AMI: Patch target sum(weights) min/max/average = 1, 1, 1
Reading/calculating face flux field phi

Selecting incompressible transport model Newtonian
Selecting turbulence model type RAS
Selecting RAS turbulence model kOmegaSST
Selecting patchDistMethod meshWave

No MRF models present

No finite volume options present


Starting time loop

fieldAverage fieldAverage:
    Starting averaging at time 0



Time = 1

[4] swak4Foam: Allocating new repository for sampledGlobalVariables
.
.
.
[24] swak4Foam: Allocating new repository for sampledGlobalVariables
DILUPBiCGStab:  Solving for Ux, Initial residual = 1, Final residual = 0.094462, No Iterations 1
DILUPBiCGStab:  Solving for Uy, Initial residual = 1, Final residual = 0.0944414, No Iterations 1
DILUPBiCGStab:  Solving for Uz, Initial residual = 1, Final residual = 0.0448152, No Iterations 1
GAMG:  Solving for p, Initial residual = 1, Final residual = 0.00935578, No Iterations 18
time step continuity errors : sum local = 1.96598e-06, global = -3.32197e-08, cumulative = -3.32197e-08
DILUPBiCGStab:  Solving for omega, Initial residual = 0.419291, Final residual = 0.00312506, No Iterations 1
DILUPBiCGStab:  Solving for k, Initial residual = 1, Final residual = 0.0368004, No Iterations 1
ExecutionTime = 21.25 s  ClockTime = 30 s
.
.
.
Time = 2500

DILUPBiCGStab:  Solving for Ux, Initial residual = 6.5722e-10, Final residual = 3.53278e-11, No Iterations 1
DILUPBiCGStab:  Solving for Uy, Initial residual = 8.86293e-10, Final residual = 4.79174e-11, No Iterations 1
DILUPBiCGStab:  Solving for Uz, Initial residual = 3.2987e-08, Final residual = 1.89865e-09, No Iterations 1
GAMG:  Solving for p, Initial residual = 8.55781e-07, Final residual = 7.21423e-09, No Iterations 4
time step continuity errors : sum local = 9.21395e-12, global = 1.57177e-14, cumulative = -1.4161e-07
DILUPBiCGStab:  Solving for omega, Initial residual = 4.19939e-08, Final residual = 3.03235e-09, No Iterations 1
DILUPBiCGStab:  Solving for k, Initial residual = 4.87178e-06, Final residual = 2.10427e-07, No Iterations 1
ExecutionTime = 3661.06 s  ClockTime = 3766 s

scalarTransport write:
DILUPBiCGStab:  Solving for S, Initial residual = 1.02183e-06, Final residual = 4.89759e-08, No Iterations 1

fieldAverage fieldAverage write:
    Calculating averages

    Writing average fields


volFieldValue volFieldValue1 write:
    volAverage(XXX) of S = XXXX.XXXXX

End

Finalising parallel run
As you can see, I can decompose the case, run simpleFoam and I get good converged results in 2500 iterations in approximately one hour.

However upon reconstruction of the case I get an error:

Code:
Build  : 5.x-da23476f9d01
Exec   : reconstructPar -latestTime
Date   : Jan 24 2018
Time   : 15:35:56
Host   : "XXX"
PID    : 19431
I/O    : uncollated
Case   : Classified
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations

Create time

Reconstructing fields for mesh region0

Time = 2500

Reconstructing FV fields

    Reconstructing volScalarFields

        SMean
        nut
        p
        k
AMI: Creating addressing and weights between 1679 source faces and 7671 target faces
--> FOAM Warning : 
    From function void Foam::AMIMethod<SourcePatch, TargetPatch>::checkPatches() const [with SourcePatch = Foam::PrimitivePatch<Foam::face, Foam::SubList, const Foam::Field<Foam::Vector<double> >&>; TargetPatch = Foam::PrimitivePatch<Foam::face, Foam::SubList, const Foam::Field<Foam::Vector<double> >&>]
    in file lnInclude/AMIMethod.C at line 57
    Source and target patch bounding boxes are not similar
    source box span     : (49.7055 47.7335 10)
    target box span     : (105.337 86.4565 0)
    source box          : (-175 11.0973 0) (-125.295 58.8308 10)
    target box          : (-167.786 -43.6612 10) (-62.4488 42.7953 10)
    inflated target box : (-174.6 -50.4749 3.18629) (-55.6351 49.609 16.8137)


--> FOAM FATAL ERROR: 
Unable to set source and target faces

    From function void Foam::faceAreaWeightAMI<SourcePatch, TargetPatch>::setNextFaces(Foam::label&, Foam::label&, Foam::label&, const boolList&, Foam::labelList&, const Foam::DynamicList<int>&, bool) const [with SourcePatch = Foam::PrimitivePatch<Foam::face, Foam::SubList, const Foam::Field<Foam::Vector<double> >&>; TargetPatch = Foam::PrimitivePatch<Foam::face, Foam::SubList, const Foam::Field<Foam::Vector<double> >&>; Foam::label = int; Foam::boolList = Foam::List<bool>; Foam::labelList = Foam::List<int>]
    in file lnInclude/faceAreaWeightAMI.C at line 287.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
#1  Foam::error::abort() at ??:?
#2  Foam::faceAreaWeightAMI<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::calcAddressing(Foam::List<Foam::DynamicList<int, 0u, 2u, 1u> >&, Foam::List<Foam::DynamicList<double, 0u, 2u, 1u> >&, Foam::List<Foam::DynamicList<int, 0u, 2u, 1u> >&, Foam::List<Foam::DynamicList<double, 0u, 2u, 1u> >&, int, int) at ??:?
#3  Foam::faceAreaWeightAMI<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::calculate(Foam::List<Foam::List<int> >&, Foam::List<Foam::List<double> >&, Foam::List<Foam::List<int> >&, Foam::List<Foam::List<double> >&, int, int) at ??:?
#4  Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::update(Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&) at ??:?
#5  Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::constructFromSurface(Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > const&, Foam::autoPtr<Foam::searchableSurface> const&) at ??:?
#6  Foam::cyclicAMIPolyPatch::resetAMI(Foam::AMIInterpolation<Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> >, Foam::PrimitivePatch<Foam::face, Foam::SubList, Foam::Field<Foam::Vector<double> > const&, Foam::Vector<double> > >::interpolationMethod const&) const at ??:?
#7  Foam::cyclicAMIPolyPatch::AMI() const at ??:?
#8  Foam::cyclicAMIPolyPatch::applyLowWeightCorrection() const at ??:?
#9  Foam::cyclicAMIFvPatch::makeWeights(Foam::Field<double>&) const at ??:?
#10  Foam::surfaceInterpolation::makeWeights() const at ??:?
#11  Foam::surfaceInterpolation::weights() const at ??:?
#12  Foam::surfaceInterpolation::makeDeltaCoeffs() const at ??:?
#13  Foam::surfaceInterpolation::deltaCoeffs() const at ??:?
#14  Foam::fvPatch::deltaCoeffs() const at ??:?
#15  Foam::groovyBCFvPatchField<double>::groovyBCFvPatchField(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#16  Foam::fvPatchField<double>::adddictionaryConstructorToTable<Foam::groovyBCFvPatchField<double> >::New(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#17  Foam::fvPatchField<double>::New(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#18  Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::Boundary::readField(Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#19  Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::readFields(Foam::dictionary const&) at ??:?
#20  Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::readFields() at ??:?
#21  Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::GeometricField(Foam::IOobject const&, Foam::fvMesh const&) at ??:?
#22  ? at ??:?
#23  ? at ??:?
#24  ? at ??:?
#25  __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#26  ? at ??:?
The important thing to notice is that I have no problem with SMean, p, nut, but with k the error pops up. Same thing happens with U and omega. There is a groovyBC boundary condition for those 3 variables at the domain boundary to prescribe a particular profile. For the other variables only native OpenFOAM boundary conditions are used.

The weird thing is that with a more complicated inner inner part there is no problem even though there are more groovyBC boundary conditions and a more complicated AMI interface.

I thought it may have been related to the different AMI parts being in different processors, but decomposing the mesh with preservePatches did not solve this issue. I also made a test on my computer using 5 domains with the simple method, which gives a different output:

Code:
Build  : 5.x-c409ae7d9096
Exec   : reconstructPar -latestTime
Date   : Jan 25 2018
Time   : 16:52:28
Host   : "XXX"
PID    : 20084
I/O    : uncollated
Case   : /home/tom/XXXX/CFD/test_5CPUs
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time



Reconstructing fields for mesh region0

Time = 5

Reconstructing FV fields

    Reconstructing volScalarFields

        p
        nut
        k
AMI: Creating addressing and weights between 6048 source faces and 3538 target faces
AMI: Patch source sum(weights) min/max/average = 0.0382361, 1.00033, 0.971785
AMI: Patch target sum(weights) min/max/average = 0.170524, 1.00198, 0.967302
AMI: Creating addressing and weights between 264 source faces and 726 target faces
AMI: Patch source sum(weights) min/max/average = 1, 1, 1
AMI: Patch target sum(weights) min/max/average = 0.873198, 1, 0.988473
AMI: Creating addressing and weights between 10367 source faces and 3503 target faces
AMI: Patch source sum(weights) min/max/average = 0, 1.00309, 0.926829
AMI: Patch target sum(weights) min/max/average = 0.203516, 1.00225, 0.926888
AMI: Creating addressing and weights between 28103 source faces and 32696 target faces
AMI: Patch source sum(weights) min/max/average = 0.647417, 1, 0.999459
AMI: Patch target sum(weights) min/max/average = 0, 1, 0.877182
AMI: Creating addressing and weights between 10906 source faces and 3317 target faces
AMI: Patch source sum(weights) min/max/average = 0, 1.0013, 0.930973
AMI: Patch target sum(weights) min/max/average = 0.280346, 1.00203, 0.931923
AMI: Creating addressing and weights between 6481 source faces and 2614 target faces
--> FOAM Warning : 
    From function void Foam::AMIMethod<SourcePatch, TargetPatch>::checkPatches() const [with SourcePatch = Foam::PrimitivePatch<Foam::face, Foam::SubList, const Foam::Field<Foam::Vector<double> >&>; TargetPatch = Foam::PrimitivePatch<Foam::face, Foam::SubList, const Foam::Field<Foam::Vector<double> >&>]
    in file lnInclude/AMIMethod.C at line 57
    Source and target patch bounding boxes are not similar
    source box span     : (57.4656 25 0.05)
    target box span     : (25.9496 25 0.0291682)
    source box          : (67.5344 -12.5 0.95) (125 12.5 1)
    target box          : (99.0504 -12.5 0.970832) (125 12.5 1)
    inflated target box : (97.2488 -14.3017 -0.830822) (126.802 14.3017 2.80165)


--> FOAM FATAL ERROR: 
Unable to set source and target faces

    From function void Foam::faceAreaWeightAMI<SourcePatch, TargetPatch>::setNextFaces(Foam::label&, Foam::label&, Foam::label&, const boolList&, Foam::labelList&, const Foam::DynamicList<int>&, bool) const [with SourcePatch = Foam::PrimitivePatch<Foam::face, Foam::SubList, const Foam::Field<Foam::Vector<double> >&>; TargetPatch = Foam::PrimitivePatch<Foam::face, Foam::SubList, const Foam::Field<Foam::Vector<double> >&>; Foam::label = int; Foam::boolList = Foam::List<bool>; Foam::labelList = Foam::List<int>]
    in file lnInclude/faceAreaWeightAMI.C at line 287.

FOAM aborting

#0  Foam::error::printStack(Foam::Ostream&) at ??:?
.
.
#26  ? at /home/abuild/rpmbuild/BUILD/glibc-2.22/csu/../sysdeps/x86_64/start.S:121
Running the case with standard OpenFOAM boundary conditions (tried an atmBoundaryLayer) gives no issue with reconstruction).

Running the case with mixed does give the same issue as above. So I think we can conclude it is an issue with OpenFOAM, not with swak4Foam/groovyBC. Unfortunately I do not know if I can make an easy example for the bug report as one case works without a problem and the other case does not.

The case that breaks down should not be completely confidential, but will have to check this with our client.
Attached Images
File Type: jpg Domain.jpg (137.5 KB, 16 views)
File Type: jpg Domain_Zoom2.jpg (194.5 KB, 16 views)
File Type: jpg Domain_Zoom1.jpg (200.4 KB, 12 views)
tomf is offline   Reply With Quote

Old   January 25, 2018, 13:00
Default
  #15
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,224
Rep Power: 49
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by tomf View Post
Running the case with standard OpenFOAM boundary conditions (tried an atmBoundaryLayer) gives no issue with reconstruction).

Running the case with mixed does give the same issue as above. So I think we can conclude it is an issue with OpenFOAM, not with swak4Foam/groovyBC.
Phew. I'm off the hook

Quote:
Originally Posted by tomf View Post
Unfortunately I do not know if I can make an easy example for the bug report as one case works without a problem and the other case does not.

The case that breaks down should not be completely confidential, but will have to check this with our client.
This is a very long shot (somehow the error messages ring a bell but I can't remember where I've already seen them): Did I see this correctly on you pictures that the cells on the two sides of the AMI have rather big differences in size (factor 2 or larger)? I think I had a similar problem that I solved by making the mesh sizes more comparable (seems that the weighting-algorithm can't handle big differences in size on the two sides)

groovyBC is a decendant of the mixed-BC. The weights are needed for the gradient-calculations. If you only implement a Dirichlet-condition with groovy try the groovyBCFixedValue-condition. Maybe it doesn't need these calculations and you're fine. Let me know if this works
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   January 25, 2018, 13:18
Default
  #16
Senior Member
 
Tom Fahner
Join Date: Mar 2009
Location: Breda, Netherlands
Posts: 606
Rep Power: 30
tomf will become famous soon enoughtomf will become famous soon enough
Send a message via MSN to tomf Send a message via Skype™ to tomf
Quote:
Originally Posted by gschaider View Post
Phew. I'm off the hook
Of course!

Quote:
Originally Posted by gschaider View Post
This is a very long shot (somehow the error messages ring a bell but I can't remember where I've already seen them): Did I see this correctly on you pictures that the cells on the two sides of the AMI have rather big differences in size (factor 2 or larger)? I think I had a similar problem that I solved by making the mesh sizes more comparable (seems that the weighting-algorithm can't handle big differences in size on the two sides)
Yes and no, on some areas there are rather large differences, on many others they are more equal. I have even more cases with only the large AMI, which also do not give a problem. The large AMI has the big differences, the small AMI does not.

Quote:
Originally Posted by gschaider View Post
groovyBC is a decendant of the mixed-BC. The weights are needed for the gradient-calculations. If you only implement a Dirichlet-condition with groovy try the groovyBCFixedValue-condition. Maybe it doesn't need these calculations and you're fine. Let me know if this works
I actually mimic an inletOutlet on a round patch so it would not solve the original problem. I did try your suggestion (ran it for 5 iterations) however and the result is that I can reconstruct that without a problem.
tomf is offline   Reply With Quote

Old   January 25, 2018, 14:48
Default
  #17
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,224
Rep Power: 49
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by tomf View Post
Of course!



Yes and no, on some areas there are rather large differences, on many others they are more equal. I have even more cases with only the large AMI, which also do not give a problem. The large AMI has the big differences, the small AMI does not.



I actually mimic an inletOutlet on a round patch so it would not solve the original problem. I did try your suggestion (ran it for 5 iterations) however and the result is that I can reconstruct that without a problem.
Then the problem has something to do with the mixed-boundary conditions. Can't offer a solution but suggest a workaround: generate a separate field kPost for post-processing by using a trivial expression "k" either in funkySetFields or the expressionField-function object. The fieldParser throws away the boundary conditions and replaces them with zeroGradient. That should decompose (you've got to hide the k-fields though)
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   January 26, 2018, 04:36
Default
  #18
Senior Member
 
Tom Fahner
Join Date: Mar 2009
Location: Breda, Netherlands
Posts: 606
Rep Power: 30
tomf will become famous soon enoughtomf will become famous soon enough
Send a message via MSN to tomf Send a message via Skype™ to tomf
Hi,

Thanks for the suggested work-around but actually I can postprocess the decomposed case in paraView. For data saving we would like to keep the reconstructed case, but I will find a way.

Regards,
Tom
tomf is offline   Reply With Quote

Old   August 19, 2019, 04:49
Default
  #19
Senior Member
 
Kmeti Rao
Join Date: May 2019
Posts: 145
Rep Power: 6
Krao is on a distinguished road
Dear Tom Fahner,

Quote:
Originally Posted by tomf View Post
Hi,

Thanks for the suggested work-around but actually I can postprocess the decomposed case in paraView. For data saving we would like to keep the reconstructed case, but I will find a way.

Regards,
Tom

Did you find a way to the above mentioned Problem? Although I am able to post-process the results in parallel, reconstruction is not possible. You can find my case in the following link.

reconstructPar error in MRFsimpleFoam (ami apprach) using GroovyBC velocity inlet

Thank you,
Krao
Krao is offline   Reply With Quote

Old   August 19, 2019, 05:14
Default
  #20
Senior Member
 
Tom Fahner
Join Date: Mar 2009
Location: Breda, Netherlands
Posts: 606
Rep Power: 30
tomf will become famous soon enoughtomf will become famous soon enough
Send a message via MSN to tomf Send a message via Skype™ to tomf
Hi Krao,

I just checked and no I did not find a work-around just stuck with the decomposed case.

Regards,
Tom
Krao likes this.
tomf is offline   Reply With Quote

Reply

Tags
cyclicami, groovybc, openfoam

Thread Tools Search this Thread
Search this Thread:

Advanced Search
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 Off
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Getting started with CyclicAMI Algebraist OpenFOAM 4 February 11, 2019 02:39
time step continuity problem in VAWT simulation lpz_michele OpenFOAM Running, Solving & CFD 5 February 22, 2018 20:50
cyclic / cyclicAMI boundary conditon - ICEM Mesh cyln OpenFOAM Running, Solving & CFD 0 November 7, 2017 16:26
CyclicAMI issues vabishek OpenFOAM Pre-Processing 1 December 6, 2015 17:37
Boundary Layer strange result fernexda OpenFOAM Running, Solving & CFD 14 January 15, 2015 08:21


All times are GMT -4. The time now is 12:59.