CFD Online Discussion Forums

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Community Contributions (https://www.cfd-online.com/Forums/openfoam-community-contributions/)
-   -   [swak4Foam] Boundary Conditions with GroovyBC, Normal Gradient (https://www.cfd-online.com/Forums/openfoam-community-contributions/102183-boundary-conditions-groovybc-normal-gradient.html)

treima May 24, 2012 09:42

Boundary Conditions with GroovyBC, Normal Gradient
 
Hello,

I´d like to implement some boundary conditions with groovyBC, but it seems, that that doesn`t work like I think it should ;).
Here is my problem:

Without groovyBc it´s possible to implement a fixed normal gradient with

boundary
{
type fixedGradient;
gradient 100;
}

Now i need this expression with a dependency of a variable, computet in a step befor. So i tried

boundary
{
type groovyBC;
gradientExpression "Var-fixed";
variable "Var{boundary2}=Var2; fixed=100";
value uniform 0;
}

For a calculating a single value, for example for a Dirichlet boundary condition, it works.

Did I make a mistake in my definition of the boundary condition? Are there any good documentations for groovyBC, where i can find such things?


Best regards
treima

gschaider May 24, 2012 11:11

Quote:

Originally Posted by treima (Post 362905)
Hello,

I´d like to implement some boundary conditions with groovyBC, but it seems, that that doesn`t work like I think it should ;).
Here is my problem:

Without groovyBc it´s possible to implement a fixed normal gradient with

boundary
{
type fixedGradient;
gradient 100;
}

Now i need this expression with a dependency of a variable, computet in a step befor. So i tried

boundary
{
type groovyBC;
gradientExpression "Var-fixed";
variable "Var{boundary2}=Var2; fixed=100";
value uniform 0;
}

For a calculating a single value, for example for a Dirichlet boundary condition, it works.

What you're missing is
Code:

fractionExpression "0";
to make it a Neumann condition. See http://openfoamwiki.net/index.php/Contrib_groovyBC

Quote:

Originally Posted by treima (Post 362905)
Did I make a mistake in my definition of the boundary condition? Are there any good documentations for groovyBC, where i can find such things?

Good documentation? I'm offended ;) . The above link plus the presentations that are linked from the swak4Foam-page provide an unfoamy amount of information (I'm sure people are laughing behind my back)

No seriously. I've started writing a document that summarizes the most important concepts of swak4Foam. But don't hold your breath. If we're lucky I will have a first version before the end of the Mayan calendar (otherwise the world will end ...)

treima May 30, 2012 08:41

Thanks for your answer, it works perfect.

I have another question on boundary conditions with groovyBC. Is it possible to make this location-dependent? Is here pos().x right?

For example, if I´m having a look at a twodimensional geometry:

boundary
{
type groovyBC;
gradientExpression "Var-function";
variable "Var{boundary2}=Var2; function=pos().x^2+2*pos().x+3";
value uniform 0;
fractionExpression "0";
}

And if this is possible, how can I define a interval for x, e.g. x from 0 to 1?

treima May 30, 2012 09:44

I think I found a solution to my problem from above.

boundary
{
type groovyBC;
gradientExpression "Var-function";
variable "Var{boundary2}=Var2; function=pos().x*pos().x+2*pos().x+3";
value uniform 0;
fractionExpression "0";
}

But I´d like to expand my example ;)

Is it possible to define something like this in the boundary conditions?
Var{boundary2} (x) = Var2 (x)

Var2 at boundary2 is a function, which is dependent from the location. OpenFoam takes the average of the Values, but it would be nicer to have the exact values at every location.


Best regards
treima

gschaider May 30, 2012 13:03

Quote:

Originally Posted by treima (Post 363854)
I think I found a solution to my problem from above.

boundary
{
type groovyBC;
gradientExpression "Var-function";
variable "Var{boundary2}=Var2; function=pos().x*pos().x+2*pos().x+3";
value uniform 0;
fractionExpression "0";
}

But I´d like to expand my example ;)

Is it possible to define something like this in the boundary conditions?
Var{boundary2} (x) = Var2 (x)

Var2 at boundary2 is a function, which is dependent from the location. OpenFoam takes the average of the Values, but it would be nicer to have the exact values at every location.


Best regards
treima

What you want is patch to patch mapping, right? Sorry. For the foreseeable future groovyBC will not support this (I've discussed the technical problems elsewhere).

BUT: if you reorganize Var and Var2 as a cyclic patch you might be able to get what you want using a jump-boundary condition doing something like this
Code:

    var
    {
        type            groovyBCJump;
        value          uniform 0;
        patchType      cyclic;
        jumpExpression  "pos().x*pos().x+2*pos().x+3";
    }

Have a look at the example case Examples/test/jumpChannel for additional inspiration.

Of course you'll have to make sure that the other physical quantities can live with the cyclic

despaired student July 27, 2012 09:34

patch to patch mapping
 
Hi,

what do you exactly mean by "patch to patch mapping"? Right now I'm looking for a tool to map the velocity-field of one model onto the inlet of another model.
Is this possible and where do I find an example?

What I want to do is the following:
simulate a rectangular line -> export the outflow-velocity-profile -> map this outflow-profile onto an inlet-surface.The inlet and outflow geometries are the same.

I've already looked into the lid-driven-cavity tutorial but there I mapped an entire Mesh onto a finer one but what if I just want to map one surface...?


Kind regards

gschaider August 1, 2012 17:18

Quote:

Originally Posted by despaired student (Post 373939)
Hi,

what do you exactly mean by "patch to patch mapping"?

To make this clear: I was speaking of swak, not OF in general

Quote:

Originally Posted by despaired student (Post 373939)
Right now I'm looking for a tool to map the velocity-field of one model onto the inlet of another model.
Is this possible and where do I find an example?

What I want to do is the following:
simulate a rectangular line -> export the outflow-velocity-profile -> map this outflow-profile onto an inlet-surface.The inlet and outflow geometries are the same.

I've already looked into the lid-driven-cavity tutorial but there I mapped an entire Mesh onto a finer one but what if I just want to map one surface...?


Kind regards

The technology to do something like this during a simulation is there (have a look at the cht-solver and the boundary conditions used there).

If you want something like the mapFields utility but only for one boundary: could be done with the above stuff, but I'm not aware of such a utility (which doesn't mean that it doesn't exist)

socrates September 19, 2012 12:21

I am trying to apply a constant BC on micro-tubes surfaces inside a substrate. I have tried these:
1.

{
type fixedGradient;
gradient uniform -10000;
}

2.

{
type groovyBC;
gradientExpression "-10000";
fractionExpression "0";
}

3.

{
type groovyBC;
value uniform 300;
gradientExpression "gradT";
variables "htot=15000.00;Tinf=293.00;k=130;gradT=htot/(k)*(Tinf-T);";
}

The results show different gradient values on the walls, gradTx, gradTy and gradTz are so much more that the input values. I should mention that when I apply this BC for top surface which is horizontal I get perfect results. Here it says ( http://www.foamcfd.org/Nabla/guides/...Guidese11.html) that by "fixedgradient" we define
http://www.foamcfd.org/Nabla/guides/...sGuide452x.gif . I need to define only the magnitude of temperature gradient on the tubes.

Could you help me please?

Thank you

aa

gschaider September 19, 2012 17:21

Quote:

Originally Posted by socrates (Post 382592)
I am trying to apply a constant BC on micro-tubes surfaces inside a substrate. I have tried these:
1.

{
type fixedGradient;
gradient uniform -10000;
}

2.

{
type groovyBC;
gradientExpression "-10000";
fractionExpression "0";
}

3.

{
type groovyBC;
value uniform 300;
gradientExpression "gradT";
variables "htot=15000.00;Tinf=293.00;k=130;gradT=htot/(k)*(Tinf-T);";
}

The results show different gradient values on the walls, gradTx, gradTy and gradTz are so much more that the input values. I should mention that when I apply this BC for top surface which is horizontal I get perfect results. Here it says ( http://www.foamcfd.org/Nabla/guides/...Guidese11.html) that by "fixedgradient" we define
http://www.foamcfd.org/Nabla/guides/...sGuide452x.gif . I need to define only the magnitude of temperature gradient on the tubes.

Could you help me please?

Thank you

aa

I don't quite understand what you mean with "different" results. That the three variants above give different results (not much a surprise with 3)? Or that there are different gradients in each direction (the gradient is always defined as perpendicular to the face)

Variant 2 (the groovyBC one) should be equivalent to
Code:

{
 type            mixed;
 refGradient uniform -10000;
 refValue uniform 0;
 valueFraction uniform 0;
}

(it has been reported in the past that there are differences in the result to 1)

socrates September 19, 2012 19:37

Thank you for your help!

I want to define temperature gradient exactly "-10000" on the pipe. I have tried those 3 cases that I wrote in my previous post separately. Non of them gave me the constant gradient on my pipe. I assume the gradient that I define is the magnitude of gradient normal to surface. Then why sqrt(gradTx^2+gradTy^2+gradTz^2) is so much bigger than that.
I tried the Mixed BC that you suggested but still I have that problem. Isn't it because of my mesh? I used blockMesh/snappyHexMesh?

Thank you again

aa

gschaider September 21, 2012 08:33

Quote:

Originally Posted by socrates (Post 382651)
Thank you for your help!

I want to define temperature gradient exactly "-10000" on the pipe. I have tried those 3 cases that I wrote in my previous post separately. Non of them gave me the constant gradient on my pipe. I assume the gradient that I define is the magnitude of gradient normal to surface. Then why sqrt(gradTx^2+gradTy^2+gradTz^2) is so much bigger than that.
I tried the Mixed BC that you suggested but still I have that problem. Isn't it because of my mesh? I used blockMesh/snappyHexMesh?

Thank you again

aa

Don't know the setup of your problem but there are two things that make it possible for the absolute gradient to be bigger:

- you prescribe the gradient on the face. The values you're referring to are calculated in the cell center. May be bigger or smaller (that's discretization)
- you prescribe only the value of the gradient in normal direction. If for instance the normal direction of your patch is y but your model has an implicit gradient in x-direction (for instance because of two fixedValue-BCs with different values) then of course these two give a biggere absolute value

In general be more specific when asking (I don't know how it is with other people, but if I have trouble understanding what your problem actually is I loose interest). To be specific:

- how much is "much bigger than that"? 5%, 100%
- which of the four cases (fixedGradient, mixed and the two groovyBC variants) give the same results (and by how much do they differ)

socrates September 21, 2012 11:57

5 Attachment(s)
Thank you Bernhard for your help!
I am sorry, I am new here!

My case is a microchannel. For the flow inside the pipes I use a FORTRAN code to get friction losses.
To get the temp. on the pipe (walls) I use OpenFOAM.
So, first I use laplacianFOAM to get wall temp., and then with my code I will get the fluid temp.
Then inside my FORTRAN code I calculated dT/dn=h*(Twall-Tfluid)/k (I know the value of k) and import it as an input for laplacianFoam to get the updated temp. field.
Since in my FORTRAN code I know Twall, therefore dT/dn will be constant for each patch.
I put this procedure into a loop until the temp. difference between two iteration is less than 10^04.
It is converging and I get the results but I dont know they are correct or not.

I have four-layer microchannel:

Attachment 15866

Here are the setting for my snappyHexMesh:


// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

// snappyHexMesh switches.

castellatedMesh true;
snap true;
addLayers true;


// Geometry. Definition of all surfaces.

geometry
{
BN.stl
{
type triSurfaceMesh;
name nozzle;

}
};


// Settings for the castellatedMesh generation.

castellatedMeshControls
{

// Refinement parameters

maxLocalCells 100000;
maxGlobalCells 300000;
minRefinementCells 10;
nCellsBetweenLevels 6;
resolveFeatureAngle 20;
features
(
);

// Surface based refinement

refinementSurfaces
{
"nozzle_*"
{
level (3 3);
}
}




refinementRegions
{
}

// Mesh selection

locationInMesh (0.00000001 0.00000001 0.00000001);
//close to a inlet side corner where no channel would coincide
//depends on prob dimensions
}


// Settings for the snapping.

snapControls
{
nSmoothPatch 3;
tolerance 4;
nSolveIter 30;
nRelaxIter 5;
}



// Settings for the layer addition.

addLayersControls
{
layers
{
"nozzle_*"
{
nSurfaceLayers 10;
}
}
relativeSizes true;
expansionRatio 1.05;
finalLayerThickness 0.5;

minThickness 0.1;
nGrow 1;


// Advanced settings
featureAngle 60;
nRelaxIter 3;
nSmoothSurfaceNormals 1;
nSmoothNormals 3;
nSmoothThickness 10;
maxFaceThicknessRatio 0.5;
maxThicknessToMedialRatio 0.3;
minMedianAxisAngle 130;
nBufferCellsNoExtrude 0;
nLayerIter 50;
}



// Generic mesh quality settings.

meshQualityControls
{
maxNonOrtho 65;
maxBoundarySkewness 20;
maxInternalSkewness 4;
maxConcave 80;
minFlatness 0.5;
minVol -1e30;
minArea -1;
minTwist 0.05;
minDeterminant 0.001;
minFaceWeight 0.02;
minVolRatio 0.01;
minTriangleTwist -1;

// Advanced
nSmoothScale 4;
errorReduction 0.75;
}


// Advanced

debug 0;
mergeTolerance 1E-6;


// ************************************************** *********************** //

here is the mesh quality:
Attachment 15867

I just use the value of "-10000" to see if I can get the constant temp. gradient on the walls or not. I used the following setting (as you suggested):

{
type mixed;
refGradient uniform -10000;
refValue uniform 0;
valueFraction uniform 0;
}

here are results:

Attachment 15868
Attachment 15869
Attachment 15870

As you see the values are much more higher that "-10000".
I should mention that these channels are inside the silicon substrate 15*15*2 mm. I know top surface heat flux and bottom surface temp. other sides are isolated. I could not attach its picures. If you want I will attach it in another pot.

Please help me!!

gschaider September 22, 2012 05:18

Quote:

Originally Posted by socrates (Post 382994)
Thank you Bernhard for your help!
I am sorry, I am new here!

My case is a microchannel. For the flow inside the pipes I use a FORTRAN code to get friction losses.
To get the temp. on the pipe (walls) I use OpenFOAM.
So, first I use laplacianFOAM to get wall temp., and then with my code I will get the fluid temp.
Then inside my FORTRAN code I calculated dT/dn=h*(Twall-Tfluid)/k (I know the value of k) and import it as an input for laplacianFoam to get the updated temp. field.
Since in my FORTRAN code I know Twall, therefore dT/dn will be constant for each patch.
I put this procedure into a loop until the temp. difference between two iteration is less than 10^04.
It is converging and I get the results but I dont know they are correct or not.

I have four-layer microchannel:

Attachment 15866

Here are the setting for my snappyHexMesh:


// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

// snappyHexMesh switches.

castellatedMesh true;
snap true;
addLayers true;


// Geometry. Definition of all surfaces.

geometry
{
BN.stl
{
type triSurfaceMesh;
name nozzle;

}
};


// Settings for the castellatedMesh generation.

castellatedMeshControls
{

// Refinement parameters

maxLocalCells 100000;
maxGlobalCells 300000;
minRefinementCells 10;
nCellsBetweenLevels 6;
resolveFeatureAngle 20;
features
(
);

// Surface based refinement

refinementSurfaces
{
"nozzle_*"
{
level (3 3);
}
}




refinementRegions
{
}

// Mesh selection

locationInMesh (0.00000001 0.00000001 0.00000001);
//close to a inlet side corner where no channel would coincide
//depends on prob dimensions
}


// Settings for the snapping.

snapControls
{
nSmoothPatch 3;
tolerance 4;
nSolveIter 30;
nRelaxIter 5;
}



// Settings for the layer addition.

addLayersControls
{
layers
{
"nozzle_*"
{
nSurfaceLayers 10;
}
}
relativeSizes true;
expansionRatio 1.05;
finalLayerThickness 0.5;

minThickness 0.1;
nGrow 1;


// Advanced settings
featureAngle 60;
nRelaxIter 3;
nSmoothSurfaceNormals 1;
nSmoothNormals 3;
nSmoothThickness 10;
maxFaceThicknessRatio 0.5;
maxThicknessToMedialRatio 0.3;
minMedianAxisAngle 130;
nBufferCellsNoExtrude 0;
nLayerIter 50;
}



// Generic mesh quality settings.

meshQualityControls
{
maxNonOrtho 65;
maxBoundarySkewness 20;
maxInternalSkewness 4;
maxConcave 80;
minFlatness 0.5;
minVol -1e30;
minArea -1;
minTwist 0.05;
minDeterminant 0.001;
minFaceWeight 0.02;
minVolRatio 0.01;
minTriangleTwist -1;

// Advanced
nSmoothScale 4;
errorReduction 0.75;
}


// Advanced

debug 0;
mergeTolerance 1E-6;


// ************************************************** *********************** //

here is the mesh quality:
Attachment 15867

I just use the value of "-10000" to see if I can get the constant temp. gradient on the walls or not. I used the following setting (as you suggested):

{
type mixed;
refGradient uniform -10000;
refValue uniform 0;
valueFraction uniform 0;
}

here are results:

Attachment 15868
Attachment 15869
Attachment 15870

As you see the values are much more higher that "-10000".
I should mention that these channels are inside the silicon substrate 15*15*2 mm. I know top surface heat flux and bottom surface temp. other sides are isolated. I could not attach its picures. If you want I will attach it in another pot.

Please help me!!

Pictures are nice. Numbers are better. But before I even bother to look at the pictures tell me: are you looking at the cell values or at the point values in paraview? If you want to check the results always use the cell values. Because these are the values that OpenFOAM worked with and wrote. The point values are an interpretation by Paraview and may be misleading (especially on the boundary where depending on the reader and the boundary condition the BC-values may or may not be used for interpolation).
So if you're working only use cell values. The point values are only for the presentations afterwards so that the aesthets are not bother with the "steppiness" of the cells

socrates September 22, 2012 20:08

Hi Bernhard,

I dont know exactly, but I think you are right. here is my fvSchemes:
-------------------------------------------
ddtSchemes
{
default steadyState;
}

gradSchemes
{
default Gauss linear;
grad(T) Gauss linear;
}

divSchemes
{
default none;
}

laplacianSchemes
{
default non;
laplacian(DT,T) Gauss linear corrected;
}

interpolationSchemes
{
default linear;
interpolate(T) linear;
}

snGradSchemes
{
default corrected;
}

fluxRequired
{
default no;
T;
}

// ************************************************** *********************** //

I use sample to get the temp. and its gradient on surfaces and patches. My sampleDic is:

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

interpolationScheme cellPointFace;

setFormat vtk;
surfaceFormat vtk;

sets
();

surfaces
(
maxY
{
type patch;
patchName maxY;
}
minY
{
type patch;
patchName minY;
}
);

fields
(
T
gradTy
);

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //

sample results are same as paraFoam. How can I make sure my results are correct? gradSchemes is based on cell enter value.

Thank you
aa

Peter Benovsky December 11, 2012 14:54

Similar thing
 
Hi,
I would like to have something like timeVaryingFixedGradient. The first thought was to use the groovyBC. The problem is when I do this in the T dictionary boundary(running buoyantPimpleFoam):

Code:

heater
{
        type    groovyBC;
        value    uniform 300;
        valueExpression    "300";       
        gradientExpression    "gradT*time()";
        fractionExpression    "0";
        variables "heatFlux=6700;alpha=0.02;gradT=heatFlux/(alpha+alphat)";
}

then I get floating point exception. If I change fractionExpression "1"; I still get the floating point exception. Now, the interesting bit is that if I use fixedValue or fixed gradient everything runs OK. I wonder where do I try to divide by 0? To check whether swak installed properly I ran some of the examples and there everything works. In my controlDict I have included "libOpenFOAM.so" "libgroovyBC.so" "libgroovyStandardBCs.so".
Any ideas where could I have messed up?

Cheers
Peter

gschaider December 11, 2012 15:10

Quote:

Originally Posted by Peter Benovsky (Post 397006)
Hi,
I would like to have something like timeVaryingFixedGradient. The first thought was to use the groovyBC. The problem is when I do this in the T dictionary boundary(running buoyantPimpleFoam):

Code:

heater
{
        type    groovyBC;
        value    uniform 300;
        valueExpression    "300";       
        gradientExpression    "gradT*time()";
        fractionExpression    "0";
        variables "heatFlux=6700;alpha=0.02;gradT=heatFlux/(alpha+alphat)";
}

then I get floating point exception. If I change fractionExpression "1"; I still get the floating point exception. Now, the interesting bit is that if I use fixedValue or fixed gradient everything runs OK. I wonder where do I try to divide by 0? To check whether swak installed properly I ran some of the examples and there everything works. In my controlDict I have included "libOpenFOAM.so" "libgroovyBC.so" "libgroovyStandardBCs.so".
Any ideas where could I have messed up?

Cheers
Peter

I'm afraid that is a bug that showed up a number of times in the last weeks and already is fixed in the development-branch: as a workaround set

refValue uniform 300;

This will only be used during startup (you didn't try to divide by 0. The thermoPhysics-library did with a value that was accidentally set to 0 because the expressions can't be evaluated before all the fields are loaded)

Peter Benovsky December 11, 2012 17:53

Quote:

Originally Posted by gschaider (Post 397011)
I'm afraid that is a bug that showed up a number of times in the last weeks and already is fixed in the development-branch: as a workaround set

refValue uniform 300;

This will only be used during startup (you didn't try to divide by 0. The thermoPhysics-library did with a value that was accidentally set to 0 because the expressions can't be evaluated before all the fields are loaded)

Thank you very much, Bernhard!
That works, and sorry for the duplicity if it is already mentioned elsewhere.

Bye
Peter

gschaider December 12, 2012 12:24

Quote:

Originally Posted by Peter Benovsky (Post 397038)
Thank you very much, Bernhard!
That works, and sorry for the duplicity if it is already mentioned elsewhere.

In this case: no problem about the duplicity. It's hard to spot that it is the same bug if you don't know what is going on (you can't say that about all the bug reports I get here)

Peter Benovsky December 14, 2012 03:04

Quote:

Originally Posted by gschaider (Post 397194)
In this case: no problem about the duplicity. It's hard to spot that it is the same bug if you don't know what is going on (you can't say that about all the bug reports I get here)

Btw. I have noticed, that when using alphatWallFunction and groovyBC, alphat is not evaluated at the patch where groovy is applied. Value uniform=0; is there instead.
Is it the same bug, perhaps?



Peter

gschaider December 14, 2012 04:28

Quote:

Originally Posted by Peter Benovsky (Post 397478)
Btw. I have noticed, that when using alphatWallFunction and groovyBC, alphat is not evaluated at the patch where groovy is applied. Value uniform=0; is there instead.
Is it the same bug, perhaps?



Peter

You can only have one BC on a patch at a time. Have you made sure that groovyBC is actually evaluated on that patch (for instance by introducing a syntactic error into an expression - if it fails it's evaluated)

BTW: which version of OF?

Peter Benovsky December 14, 2012 04:55

Quote:

Originally Posted by gschaider (Post 397495)
You can only have one BC on a patch at a time. Have you made sure that groovyBC is actually evaluated on that patch (for instance by introducing a syntactic error into an expression - if it fails it's evaluated)

BTW: which version of OF?

2.1.1
What I meant is that I use groovyBC for the temperature. alphat uses standard alpatWallFunction, hence should not be groovyfied.

gschaider December 14, 2012 06:26

Quote:

Originally Posted by Peter Benovsky (Post 397507)
2.1.1
What I meant is that I use groovyBC for the temperature. alphat uses standard alpatWallFunction, hence should not be groovyfied.

OK. Please provide some context (like which fields you used which BC on). It is not as absurd as you might think: I have seen people specifying 'type' twice hoping both would work.

Anyway: if the value 0 is only there during the first timestep then it is the same bug

Peter Benovsky December 17, 2012 09:44

Quote:

Originally Posted by gschaider (Post 397528)
OK. Please provide some context (like which fields you used which BC on). It is not as absurd as you might think: I have seen people specifying 'type' twice hoping both would work.

Anyway: if the value 0 is only there during the first timestep then it is the same bug

It took longer than I thought but here it is (the context):
Code:

location "0";
object alphat;
 
heater
{
type alphatWallFunction;
value uniform 0.01;
}
 
object T;
 
heater
{
type groovyBC;
refValue uniform 300;
valueExpression "300";
gradientExpression "gradT*time()";
fractionExpression "0";
variables "heatFlux=100;gradT=heatFlux/(alphaEff);";
}

Without groovybc in the next time step I get for alphat:
Code:

location "0";
object alphat;
 
heater
{
type alphatWallFunction;
Prt                            0.85;
value nonuniform List<scalar>
.
.
.
}

With groovy bc it is just fixedValue with value=0
Cheers
Peter

gschaider December 17, 2012 12:30

Quote:

Originally Posted by Peter Benovsky (Post 397925)
It took longer than I thought but here it is (the context):
Code:

location "0";
object alphat;
 
heater
{
type alphatWallFunction;
value uniform 0.01;
}
 
object T;
 
heater
{
type groovyBC;
refValue uniform 300;
valueExpression "300";
gradientExpression "gradT*time()";
fractionExpression "0";
variables "heatFlux=100;gradT=heatFlux/(alphaEff);";
}

Without groovybc in the next time step I get for alphat:
Code:

location "0";
object alphat;
 
heater
{
type alphatWallFunction;
Prt                            0.85;
value nonuniform List<scalar>
.
.
.
}

With groovy bc it is just fixedValue with value=0
Cheers
Peter

Hmm. That is strange. It should work. Could you try some things:

- instead of alphaEff add a constant (although I don't think that is the problem)
- set valueFraction to "uniform 0" (just to be sure)
- reset the 300 in the refValue to x. This should fail (this is just to make sure that it is really read)

Which version of swak do you use (check the start of the output of funkySetFields)

xuan8908 February 21, 2014 16:25

Hi, Bernhard,

I am trying to look at your codes of the groovyBC implementation. I am
curious where you pass those strings, like "valueExpression_" and
"gradientExpression_"? In the source code, groovyBCCommon.C, you just
look up those keywords from the dictionary file and read them. How do
those strings come into play to update the boundary condition? I guess
one of those source codes may contain the implementation of this. Could
you please tell me which source code is the right one that I can read
and learn from? Thanks a lot in advance. I will appreciate your reply.

gschaider February 22, 2014 11:23

Quote:

Originally Posted by xuan8908 (Post 476101)
Hi, Bernhard,

I am trying to look at your codes of the groovyBC implementation. I am
curious where you pass those strings, like "valueExpression_" and
"gradientExpression_"? In the source code, groovyBCCommon.C, you just
look up those keywords from the dictionary file and read them. How do
those strings come into play to update the boundary condition? I guess
one of those source codes may contain the implementation of this. Could
you please tell me which source code is the right one that I can read
and learn from? Thanks a lot in advance. I will appreciate your reply.

grep is your friend if you want to find the location of variables in the source code (of course there are more sophisticated tool, but this is installed on every system)

That'd be updateCoeffs in groovyBCFvPatchField.C. But the real magic happens in Libraries/swak4FoamParsers (especially everything with PatchValue in the beginning)

xuan8908 February 22, 2014 11:54

Thank you, Bernhard. I will take a look at it.

Sliwa September 17, 2014 04:40

Hello,

I am not sure this is the right thread for my question, but I was wondering if it was possible to set a fixed gradient in the direction normal to the patch and a fixed value in the tangential direction with groovyBC?

gschaider September 17, 2014 17:29

Quote:

Originally Posted by Sliwa (Post 510625)
Hello,

I am not sure this is the right thread for my question, but I was wondering if it was possible to set a fixed gradient in the direction normal to the patch and a fixed value in the tangential direction with groovyBC?

There is a groovyBCDirection that wraps directionMixed (http://www.cfd-online.com/Forums/ope...-mixed-bc.html) but maybe this is not exactly what you need (no Dirichlet in tangential direction)

Sliwa September 18, 2014 10:56

Yes, I needed the Dirichlet in the tangential direction. Thanks anyway.

behzad-cfd November 15, 2017 14:57

Quote:

Originally Posted by gschaider (Post 510716)
There is a groovyBCDirection that wraps directionMixed (http://www.cfd-online.com/Forums/ope...-mixed-bc.html) but maybe this is not exactly what you need (no Dirichlet in tangential direction)

Hi Bernhard,

I want to solve \nabla^{2}\xi+\vec{n}\cdot\nabla\xi=0 equation and obtain B that is defined like \overrightarrow{B}=(\frac{\partial\xi}{\partial  y})\vec{e_{x}}-(\frac{\partial\xi}{\partial x})\vec{e_{y}}.
I've implemented the equation in my base solver. Now i want to test functionality of the new solver but i have some boundary condition problem before testing.
For example if i want to get \overrightarrow{B}=(0,1) in boundaries i need to set (\frac{\partial\xi}{\partial  y})=0 and -(\frac{\partial\xi}{\partial x})=1.

Can i use groovyBC for this?
How can i implement this BCs?

Thanks in advance,

gschaider November 16, 2017 20:16

Quote:

Originally Posted by behzad-cfd (Post 671698)
Hi Bernhard,

I want to solve \nabla^{2}\xi+\vec{n}\cdot\nabla\xi=0 equation and obtain B that is defined like \overrightarrow{B}=(\frac{\partial\xi}{\partial  y})\vec{e_{x}}-(\frac{\partial\xi}{\partial x})\vec{e_{y}}.
I've implemented the equation in my base solver. Now i want to test functionality of the new solver but i have some boundary condition problem before testing.
For example if i want to get \overrightarrow{B}=(0,1) in boundaries i need to set (\frac{\partial\xi}{\partial  y})=0 and -(\frac{\partial\xi}{\partial x})=1.

Can i use groovyBC for this?
How can i implement this BCs?

Thanks in advance,

I'm afraid not. Because if you have a boundary with constant x then (\frac{\partial\xi}{\partial  y})=0 is not a boundary condition but a differential equation for the value on the boundary

behzad-cfd November 17, 2017 03:44

Quote:

Originally Posted by gschaider (Post 671844)
I'm afraid not. Because if you have a boundary with constant x then (\frac{\partial\xi}{\partial  y})=0 is not a boundary condition but a differential equation for the value on the boundary

Thanks for reply,
I should tell you that actually we have \vec{A}=(0,0,\xi) and \vec{B}=\nabla \times A = (\frac{\partial \xi}{\partial y}, -\frac{\partial \xi}{\partial x})
So how can i set such a condition?!:confused:


All times are GMT -4. The time now is 13:19.