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

[swak4Foam] groovyBC boundary using values from another boundary

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

Like Tree4Likes
  • 2 Post By gschaider
  • 1 Post By gschaider
  • 1 Post By Yeru

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
Old   June 18, 2012, 22:07
Default groovyBC boundary using values from another boundary
  #1
Member
 
jack
Join Date: Jul 2011
Posts: 52
Rep Power: 14
lg88 is on a distinguished road
Dear all
I have been studying the groovyBC boundary condition these days.But I am confused in understanding something.
The following is my inputing file for pressure p.
-------------------------------------------------------------------------------------------------------

dimensions [0 2 -2 0 0 0 0];

internalField uniform 0;

boundaryField
{

SIDE
{
type groovyBC;
value uniform 0.1;
valueExpression "Pside";
variables "Pside@SIDE=p;";
}
OUT
{
type zeroGradient;
}
IN
{
type zeroGradient;
}
}
----------------------------------------------------------------------------------------------------------
Does it mean that I am using the state of the fields P on the same patches(in my case it is SIDE) from the previous time-step or iteration to evaluating the pressure expression in run-time?

According the original description from website http://openfoamwiki.net/index.php/Contrib_groovyBC
"groovyBC provides the ability to access fields from remote patches (other patches present within the current simulation). When evaluating the expression in run-time, the state of the fields on the remote patches from the previous time-step or iteration are utilised."

Have I understood it correctly?
Thank you for your suggestion!


lg88
lg88 is offline   Reply With Quote

Old   June 19, 2012, 16:06
Default
  #2
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by lg88 View Post
Dear all
I have been studying the groovyBC boundary condition these days.But I am confused in understanding something.
The following is my inputing file for pressure p.
-------------------------------------------------------------------------------------------------------

dimensions [0 2 -2 0 0 0 0];

internalField uniform 0;

boundaryField
{

SIDE
{
type groovyBC;
value uniform 0.1;
valueExpression "Pside";
variables "Pside@SIDE=p;";
}
OUT
{
type zeroGradient;
}
IN
{
type zeroGradient;
}
}
----------------------------------------------------------------------------------------------------------
Does it mean that I am using the state of the fields P on the same patches(in my case it is SIDE) from the previous time-step or iteration to evaluating the pressure expression in run-time?

According the original description from website http://openfoamwiki.net/index.php/Contrib_groovyBC
"groovyBC provides the ability to access fields from remote patches (other patches present within the current simulation). When evaluating the expression in run-time, the state of the fields on the remote patches from the previous time-step or iteration are utilised."

Have I understood it correctly?
Thank you for your suggestion!


lg88
It's a bit more complicated than that: if the solver does multiple iterations per timestep then for later iterations p will be the updated value. Your expression basically sets p uniformly to the average of what p currently is (which is technically the value of the last time).

Newer versions of groovyBC have the possiblity to access the p from the last time with "oldTime(p)".

Form the @ in your remote patch-access I deduce that you're using a non-swak4Foam version of groovyBC (the syntax there is different). "oldTime" won't work there anyway
ashish.vinayak and Hamoon like this.
gschaider is offline   Reply With Quote

Old   June 22, 2012, 10:50
Default
  #3
Member
 
jack
Join Date: Jul 2011
Posts: 52
Rep Power: 14
lg88 is on a distinguished road
Hi gschaider
I have installed swak4Foam in my computer for the purpose of using function 'oldTime'.I need the calculated value of the last time not the average value.So I have changed my inputing P file as follow:
----------------------------------------------------------------------------------------------------
dimensions [0 2 -2 0 0 0 0];

internalField uniform 0;

boundaryField
{

SIDE
{
type groovyBC;
value uniform 0.1;
valueExpression "Pside";
variables "Pside{SIDE}=oldTime(p);";
}
OUT
{
type zeroGradient;
}
IN
{
type zeroGradient;
}
}

-----------------------------------------------------------------------------------------------------------------
But when I run my case,it came out some warnings as:
Code:
--> FOAM Warning : 
    From function ExpressionResult::getUniformInternal(const label size,bool noWarn)
    in file ExpressionResultI.H at line 158
    The minimum value -2.83026e-12 and the maximum -8.53848e-14 differ. I will use the average -1.45782e-12
DICPCG:  Solving for P, Initial residual = 0.00118285, Final residual = 9.79314e-07, No Iterations 23
I guessed the solver had token the average value as the boundary condition from the warning.Do you know what is wrong with it?

Regards!

lg88
lg88 is offline   Reply With Quote

Old   June 22, 2012, 16:06
Default
  #4
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by lg88 View Post
Hi gschaider
I have installed swak4Foam in my computer for the purpose of using function 'oldTime'.I need the calculated value of the last time not the average value.So I have changed my inputing P file as follow:
----------------------------------------------------------------------------------------------------
dimensions [0 2 -2 0 0 0 0];

internalField uniform 0;

boundaryField
{

SIDE
{
type groovyBC;
value uniform 0.1;
valueExpression "Pside";
variables "Pside{SIDE}=oldTime(p);";
}
OUT
{
type zeroGradient;
}
IN
{
type zeroGradient;
}
}

-----------------------------------------------------------------------------------------------------------------
But when I run my case,it came out some warnings as:
Code:
--> FOAM Warning : 
    From function ExpressionResult::getUniformInternal(const label size,bool noWarn)
    in file ExpressionResultI.H at line 158
    The minimum value -2.83026e-12 and the maximum -8.53848e-14 differ. I will use the average -1.45782e-12
DICPCG:  Solving for P, Initial residual = 0.00118285, Final residual = 9.79314e-07, No Iterations 23
I guessed the solver had token the average value as the boundary condition from the warning.Do you know what is wrong with it?
Just write
Code:
        variables       "Pside=oldTime(p);";
the values are always averaged if you us the "remote" notation for variables. Even if "remote" is the same patch
yanxiang likes this.
gschaider is offline   Reply With Quote

Old   September 1, 2014, 12:26
Default shredder BC instead of coupling
  #5
New Member
 
Dominik Pöltl
Join Date: Jul 2013
Location: Hamburg
Posts: 21
Rep Power: 12
Yeru is on a distinguished road
Dear Jack, dear Bernhard,

I have the same warning when running scalarTransportFoam on my case.
Code:
--> FOAM Warning : 
    From function ExpressionResult::getUniformInternal(const label size,bool noWarn)
    in file ExpressionResult/ExpressionResultI.H at line 332
    The minimum value 0.470189 and the maximum 0.592711 differ. I will use the average 0.527611
My case is a simple simulation of a rectangular channel after a delta-shaped SuperFocus mixer. Since the nozzles of fluid A and B alternate, my initial condition is a nice alternating pattern A-B-A-B-A

The fluid moves steadily in negative z direction.
The upper inlet patch is coupled to the lower one via groovyBC
Code:
    cycEl_front
    {
        type        groovyBC;
        fractionExpression    1;
        variables    "T_back{cycEl_back}=T;    grad_back{cycEl_back}=snGrad(T);";
        valueExpression    "T_back";
        gradientExpression    "grad_back";
    }
Even changing it to "oldTime(T)" still yields the solver warnings.
The results are like a shredder boundary condition:
Instead of a coupling, that reproduces the values at the outlet, I get this:


Neither my supervisor nor me can think of any simpler yet adequate other BCs.
Any advice?
Yeru is offline   Reply With Quote

Old   September 1, 2014, 13:08
Default
  #6
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by Yeru View Post
Dear Jack, dear Bernhard,

I have the same warning when running scalarTransportFoam on my case.
Code:
--> FOAM Warning : 
    From function ExpressionResult::getUniformInternal(const label size,bool noWarn)
    in file ExpressionResult/ExpressionResultI.H at line 332
    The minimum value 0.470189 and the maximum 0.592711 differ. I will use the average 0.527611
My case is a simple simulation of a rectangular channel after a delta-shaped SuperFocus mixer. Since the nozzles of fluid A and B alternate, my initial condition is a nice alternating pattern A-B-A-B-A

The fluid moves steadily in negative z direction.
The upper inlet patch is coupled to the lower one via groovyBC
Code:
    cycEl_front
    {
        type        groovyBC;
        fractionExpression    1;
        variables    "T_back{cycEl_back}=T;    grad_back{cycEl_back}=snGrad(T);";
        valueExpression    "T_back";
        gradientExpression    "grad_back";
    }
Even changing it to "oldTime(T)" still yields the solver warnings.
The results are like a shredder boundary condition:
Instead of a coupling, that reproduces the values at the outlet, I get this:


Neither my supervisor nor me can think of any simpler yet adequate other BCs.
Any advice?
I have discussed this multiple times here: "remote" variables can only be uniform. But what would be appropriate for your example would be a "mapped"-boundary. See the pitzDailyMapped in the tutorials and n swak in Examples/tests/ the mapping examples (although they do more than what you might need)
__________________
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   April 22, 2016, 05:48
Default The sign "-" in groovyBC
  #7
New Member
 
jamamoto takasi
Join Date: Jul 2015
Posts: 11
Rep Power: 10
Jamamoto takasi is on a distinguished road
I have confused, When I use groovyBC to set the input of the velocity, such as this
Code:
inlet
{
	type 		groovyBC;
        variables "Ustar= 0.005;E=9.8;kappa=0.41;nu=1e-6;para=-(Ustar/kappa)*log(E*Ustar*pos().y/nu)*normal();";        
	valueExpression "para";
        value           uniform (0.02 0 0);
    
}
The problem here is the sign "-" before para. Its physical meaning ?

When I do not use it, the velocity will be in the opposite direction, ie the velocity input from outlet .

Thanks,

best regards,


takasi
Jamamoto takasi is offline   Reply With Quote

Old   April 24, 2016, 16:30
Default
  #8
New Member
 
Dominik Pöltl
Join Date: Jul 2013
Location: Hamburg
Posts: 21
Rep Power: 12
Yeru is on a distinguished road
Quote:
Originally Posted by Jamamoto takasi View Post
[...]
Code:
inlet
{
    type         groovyBC;
        [...] para=-(Ustar/kappa)*log(E*Ustar*pos().y/nu)*normal();";    
}
[...]
Dear Takasi,
short answer: try
Code:
para=(-1)*(Ustar/kappa)*log(E*Ustar*pos().y/nu)*normal();
long answer: openFoam regards the minus sign as a binary operator (e.g. "a - b") so that it cannot stand on its own. The unary minus sign (e.g. "-c") can thereby be used by multiplying a term with -1.

I hope, this solves your problem!
Greetings,
Yeru
Jamamoto takasi likes this.
Yeru is offline   Reply With Quote

Old   May 2, 2016, 15:48
Default
  #9
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 4,225
Rep Power: 51
gschaider will become famous soon enoughgschaider will become famous soon enough
Quote:
Originally Posted by Yeru View Post
Dear Takasi,
short answer: try
Code:
para=(-1)*(Ustar/kappa)*log(E*Ustar*pos().y/nu)*normal();
long answer: openFoam regards the minus sign as a binary operator (e.g. "a - b") so that it cannot stand on its own. The unary minus sign (e.g. "-c") can thereby be used by multiplying a term with -1.

I hope, this solves your problem!
Greetings,
Yeru
Strange. groovyBC should know how to handle a unary minus
__________________
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   July 28, 2017, 11:43
Default
  #10
Senior Member
 
Alejandro
Join Date: Jan 2014
Location: Argentina
Posts: 128
Rep Power: 12
ancolli is on a distinguished road
Quote:
Originally Posted by Yeru View Post
Dear Jack, dear Bernhard,

I have the same warning when running scalarTransportFoam on my case.
Code:
--> FOAM Warning : 
    From function ExpressionResult::getUniformInternal(const label size,bool noWarn)
    in file ExpressionResult/ExpressionResultI.H at line 332
    The minimum value 0.470189 and the maximum 0.592711 differ. I will use the average 0.527611
My case is a simple simulation of a rectangular channel after a delta-shaped SuperFocus mixer. Since the nozzles of fluid A and B alternate, my initial condition is a nice alternating pattern A-B-A-B-A

The fluid moves steadily in negative z direction.
The upper inlet patch is coupled to the lower one via groovyBC
Code:
    cycEl_front
    {
        type        groovyBC;
        fractionExpression    1;
        variables    "T_back{cycEl_back}=T;    grad_back{cycEl_back}=snGrad(T);";
        valueExpression    "T_back";
        gradientExpression    "grad_back";
    }
Even changing it to "oldTime(T)" still yields the solver warnings.
The results are like a shredder boundary condition:
Instead of a coupling, that reproduces the values at the outlet, I get this:


Neither my supervisor nor me can think of any simpler yet adequate other BCs.
Any advice?
did u solve ur problem?
I am having the same warning, in 1D the result is ok, but in 2D i can not have convergence
ancolli is offline   Reply With Quote

Reply

Tags
groovybc

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
sliding mesh problem in CFX Saima CFX 46 September 11, 2021 08:38
Radiation in semi-transparent media with surface-to-surface model? mpeppels CFX 11 August 22, 2019 08:30
Radiation interface hinca CFX 15 January 26, 2014 18:11
An error has occurred in cfx5solve: volo87 CFX 5 June 14, 2013 18:44
domain imbalance for enrgy equation happy CFX 14 September 6, 2012 02:54


All times are GMT -4. The time now is 05:43.