CFD Online Discussion Forums

CFD Online Discussion Forums (http://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (http://www.cfd-online.com/Forums/openfoam-solving/)
-   -   CyclicAMI, groovyBC issues (http://www.cfd-online.com/Forums/openfoam-solving/112381-cyclicami-groovybc-issues.html)

sherifkadry January 27, 2013 18:15

CyclicAMI, groovyBC issues
 
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::printStack(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::plusEqOp<double> > >(Foam::UList<double> const&, Foam::combineBinaryOp<double, Foam::plusEqOp<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::plusEqOp<double> >(Foam::Field<double> const&, Foam::plusEqOp<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::DimensionedField<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::DimensionedField<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::DimensionedField<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::DimensionedField<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"

gschaider January 27, 2013 18:55

Quote:

Originally Posted by sherifkadry (Post 404382)
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::printStack(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::plusEqOp<double> > >(Foam::UList<double> const&, Foam::combineBinaryOp<double, Foam::plusEqOp<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::plusEqOp<double> >(Foam::Field<double> const&, Foam::plusEqOp<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::DimensionedField<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::DimensionedField<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::DimensionedField<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::DimensionedField<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

sherifkadry January 27, 2013 19:10

Quote:

Originally Posted by gschaider (Post 404394)
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 January 27, 2013 19:18

Quote:

Originally Posted by gschaider (Post 404394)
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.

gschaider January 27, 2013 19:21

Quote:

Originally Posted by sherifkadry (Post 404395)
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

sherifkadry January 27, 2013 20:11

Quote:

Originally Posted by gschaider (Post 404398)
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 January 27, 2013 20:34

Quote:

Originally Posted by gschaider (Post 404398)
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)
}


?

gschaider January 28, 2013 08:28

Quote:

Originally Posted by sherifkadry (Post 404404)
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 (Post 404404)
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 (Post 404404)
Can send you the case if you are interested further.

First try mixed

Quote:

Originally Posted by sherifkadry (Post 404404)
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

sherifkadry January 28, 2013 09:13

Quote:

Originally Posted by gschaider (Post 404492)
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 January 28, 2013 09:29

Quote:

Originally Posted by gschaider (Post 404492)
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

gschaider January 28, 2013 09:50

Quote:

Originally Posted by sherifkadry (Post 404504)
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/

Peter Müller November 11, 2013 04:00

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

gschaider November 18, 2013 19:20

Quote:

Originally Posted by Peter Müller (Post 461494)
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


All times are GMT -4. The time now is 11:23.