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

CyclicAMI, groovyBC issues

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

Reply
 
LinkBack Thread Tools Display Modes
Old   January 27, 2013, 18:15
Default CyclicAMI, groovyBC issues
  #1
Member
 
Sherif Kadry
Join Date: May 2009
Posts: 38
Rep Power: 8
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: 3,912
Rep Power: 40
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: 8
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: 8
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: 3,912
Rep Power: 40
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: 8
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: 8
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: 3,912
Rep Power: 40
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: 8
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: 8
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: 3,912
Rep Power: 40
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: 36
Rep Power: 5
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: 3,912
Rep Power: 40
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

Reply

Tags
cyclicami, groovybc, openfoam

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
groovyBC and funkySetFields married and got a kid named swak4Foam gschaider OpenFOAM 164 January 13, 2015 03:52
Boundary Conditions with GroovyBC, Normal Gradient treima OpenFOAM Running, Solving & CFD 29 September 18, 2014 10:56
problem with cyclicAMI and wall distance Maff OpenFOAM Bugs 5 August 14, 2014 14:41
Boundary Conditions with GroovyBC, Normal Gradient treima OpenFOAM Programming & Development 2 January 26, 2013 03:37
groovyBC and Eqn.setReference() benk OpenFOAM 3 June 2, 2011 08:49


All times are GMT -4. The time now is 21:16.