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

How to model a fan fixing the mass flow rate?

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

Like Tree2Likes

Reply
 
LinkBack Thread Tools Display Modes
Old   October 1, 2010, 06:00
Question How to model a fan fixing the mass flow rate?
  #1
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 12
maddalena is on a distinguished road
Hi everyone,

searching here and there, but i still miss something... maybe open a new thread will help me a bit.
I would like to model a fan inside a closed loop circuit, fixing the mass flow and not the pressure jump. The reason is explained here.
As an idea, I thought to use a flowRateInletVelocity coupled with a fluxCorrectedVelocity:
  • fanOutlet = domain inlet
    • U: flowRateInletVelocity
    • p: zeroGradient
  • fanInlet = domain outlet
    • U: fluxCorrectedVelocity
    • p: fixedValue, p = 0
No success: p is higher close to the fanInlet and lower to the fanOutlet, while it should be the other way round. I know I am miss something.

Are there any idea on how to model such kind of fan?

Regards


maddalena
maddalena is offline   Reply With Quote

Old   October 4, 2010, 03:20
Default
  #2
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 12
maddalena is on a distinguished road
Hi,
Just to say I have solved this:
Quote:
Originally Posted by maddalena View Post
p is higher close to the fanInlet and lower to the fanOutlet
and now pressure has the expected distribution. However, the simulation is not stable and residual never get low. My fvScheme and fvSolution should not be the problem: they are tuned for similar cases. I guess the BC are not set correctly to simulate what I want to solve. Is there anyone that can help me to understand what my errors can be?
Regards

maddalena
maddalena is offline   Reply With Quote

Old   October 4, 2010, 06:10
Default
  #3
Senior Member
 
Eugene de Villiers
Join Date: Mar 2009
Posts: 725
Rep Power: 12
eugene is on a distinguished road
Not sure why you are using fluxCorrectedVelocity at the outlet. zeroGradient should work fine. The mass flow specification at the inlet is already enough to guarantee the same at the outlet. However, your approach will not produce very good results, since the flow going out and the flow going in to the domain will not be well correlated as you would expect in the case of a real fan.

To fix it, you have 3 choices:
1. Modify the actuator disk code from windFoam to goal-seek your specified mass-flow rate.
2. Map the outlet velocity to the inlet using the mapping boundary functions like those used in the CHT boundaries.
3. Modify the fan internal boundary to support fixed mass flow (this is the hardest).
eugene is offline   Reply With Quote

Old   October 4, 2010, 07:44
Default
  #4
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 12
maddalena is on a distinguished road
Hi Eugene,
Quote:
Originally Posted by eugene View Post
Not sure why you are using fluxCorrectedVelocity at the outlet. zeroGradient should work fine. The mass flow specification at the inlet is already enough to guarantee the same at the outlet.
Well, the simulation was not so stable using zeroGradient, thus I looked at one of the tutorial where the flowRateInletVelocity is used, and it was coupled with a fluxCorrectedVelocity. Therefore, I chose the same approach, and the simulation was more stable indeed. However, as you pointed out,
Quote:
Originally Posted by eugene View Post
the approach will not produce very good results, since the flow going out and the flow going in to the domain will not be well correlated as you would expect in the case of a real fan.
I am thinking to the approaches you suggested:This one seems the more affordable for me
Quote:
Originally Posted by eugene View Post
Map the outlet velocity to the inlet using the mapping boundary functions like those used in the CHT boundaries
since I have some kind of (bad) experience with chtMultiRegionFoam.
you refers to the coupling condition on temperature, don't you? What I am wandering is: on the temperature coupling there is no external temperature fixed on one of the coupling side, while I should fix the mass flow rate on one of the fan side. How can I do that?
As for the pressure, it should be defined automatically once the velocity is fixed. Am I right?
Thanks for your suggestions and ideas,
regards

mad
maddalena is offline   Reply With Quote

Old   October 4, 2010, 17:40
Default Hi maddelena
  #5
Member
 
Robin Gilbert
Join Date: Jan 2010
Posts: 66
Rep Power: 7
robingilbert is on a distinguished road
I got lost using the actuator disk. so i tried something else. here is what i did:

I added a constant source term to the Ueqn say M.
i use setFieldsDict to initialize the source terms so that gets activated in the fan region.
i run external scripts to automatically check if i have reached my target mass flow rate.
(i use swak4Foam by bernard to calculate mass flow rate through internal face zone)
if i have not reached my mass flow rate, the script changes the value of M using setFieldsDict and rerun until it reaches steady state and then check again if i have reached target mass flow rate.

I know its not an elegant method to do that using external scripts when OpenFoam is such a great tool. but i am not so good at coding and have been losing so much time on this that i tried my method. atleast i am sort of getting wat i want.
robingilbert is offline   Reply With Quote

Old   October 4, 2010, 17:57
Default
  #6
Member
 
Robin Gilbert
Join Date: Jan 2010
Posts: 66
Rep Power: 7
robingilbert is on a distinguished road
Hi Eugene,

I tried ur following suggestion:
Quote:
To fix it, you have 3 choices:
1. Modify the actuator disk code from windFoam to goal-seek your specified mass-flow rate.
i tried it using the channelFoam solver as my base to goal-seek my mass-flow rate
Code:
        volScalarField magUbar = mag(Ubar);
        volScalarField magUbarStar = ((flowDirection & U)())*alpha;
        volScalarField gragPplus = ((magUbar - magUbarStar)/rUA);
        U += (flowDirection*rUA*gragPplus);
        gradP += gragPplus;
where alpha is a scalarField which is equal to 1 where i have my fan and 0 elsewhere.
but i am not getting what i want. i know i am doing some stupid mistake. but if i understand this properly, mayb i can do it elegantly.

pls help!!
robingilbert is offline   Reply With Quote

Old   October 5, 2010, 02:34
Default
  #7
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 12
maddalena is on a distinguished road
Hi Robin,
Quote:
Originally Posted by robingilbert View Post
if i have not reached my mass flow rate, the script changes the value of M using setFieldsDict and rerun until it reaches steady state and then check again if i have reached target mass flow rate.
Thus if I understand right, you used an iterative process to check the mass flow. This has been suggested me elsewhere (here). However, in my case I have small computational resources - large meshes - little time, the three worse friends in CFD . Thus an iterative process is not ok in my case.
It would be great if the solver can check mass flow and adjust it in order to keep the prescribed value, during the same simulation. That is, what Eugene suggested yesterday with a solution similar to the CHT boundaries.
Eugene, are you willing to help us?

mad
maddalena is offline   Reply With Quote

Old   October 5, 2010, 03:21
Default
  #8
Senior Member
 
Stefan Herbert
Join Date: Dec 2009
Location: Darmstadt, Germany
Posts: 129
Rep Power: 8
herbert is on a distinguished road
Hi,

i just came around this post and like to make a suggestion. If I understood you well, you know about the mass flow and your simulation is incompressible.

If so, you can use directMapped-BC for velocity at the inlet and map the velocity profile from the outlet to the inlet. You can use the setAverage option to make sure that your target mass flow is reached.

Regards,
Stefan
herbert is offline   Reply With Quote

Old   October 5, 2010, 03:33
Default
  #9
Senior Member
 
Eugene de Villiers
Join Date: Mar 2009
Posts: 725
Rep Power: 12
eugene is on a distinguished road
Quote:
Originally Posted by herbert View Post
If so, you can use directMapped-BC for velocity at the inlet and map the velocity profile from the outlet to the inlet. You can use the setAverage option to make sure that your target mass flow is reached.
There you go. Now use the same method to map the inlet pressure back onto the outlet while scaling to 0 and you have (in theory) a perfect coupling.
eugene is offline   Reply With Quote

Old   October 5, 2010, 03:43
Default
  #10
Senior Member
 
Stefan Herbert
Join Date: Dec 2009
Location: Darmstadt, Germany
Posts: 129
Rep Power: 8
herbert is on a distinguished road
Quote:
Originally Posted by eugene View Post
Now use the same method to map the inlet pressure back onto the outlet while scaling to 0 and you have (in theory) a perfect coupling.
I've used a similar approach some time ago and I rember some problem with doing the additional pressure coupling. For a first shot I'd try to couple only the velocity.

Regards,
Stefan
herbert is offline   Reply With Quote

Old   October 5, 2010, 03:44
Default
  #11
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 12
maddalena is on a distinguished road
Hi Stefan and thanks for joining this thread.
Quote:
Originally Posted by herbert View Post
you know about the mass flow and your simulation is incompressible.
Yes, that is correct.
Quote:
Originally Posted by herbert View Post
you can use directMapped-BC for velocity at the inlet and map the velocity profile from the outlet to the inlet. You can use the setAverage option to make sure that your target mass flow is reached.
am I right if I say that the setAverage option used to set the average value of the field, thus velocity in this case? Since I know the mass flow rate and the section dimension, I can calculate the average velocity as massFlowRate/Area, then use this value on the setAverage option.
Quote:
Originally Posted by eugene View Post
Now use the same method to map the inlet pressure back onto the outlet while scaling to 0 and you have (in theory) a perfect coupling.
Therefore:
  • fanOutlet = domain inlet
    • U: flowRateInletVelocity
    • p: directMappedFixedValue
  • fanInlet = domain outlet
    • U: directMappedFixedValue, setAverage: massFlowRate/Area
    • p: fixedValue, p = 0
Will this take into account the pressure jump at the fan interface?

mad
maddalena is offline   Reply With Quote

Old   October 5, 2010, 03:49
Default
  #12
Senior Member
 
Stefan Herbert
Join Date: Dec 2009
Location: Darmstadt, Germany
Posts: 129
Rep Power: 8
herbert is on a distinguished road
Quote:
Originally Posted by maddalena View Post
Will this take into account the pressure jump at the fan interface?
Even it is not included explictly it should be predicted correctly. Having non-zero velocities in your domain will always cause a pressure gradient. Therefore you should find a pressure difference between inlet and outlet being exactly that one to be imposed by your fan in reality.
herbert is offline   Reply With Quote

Old   October 5, 2010, 03:58
Default
  #13
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 12
maddalena is on a distinguished road
Quote:
Originally Posted by herbert View Post
Therefore you should find a pressure difference between inlet and outlet being exactly that one to be imposed by your fan in reality.
Or is that the (total) pressure jump that the fan should assure to have the flow moving? Thus the (total) pressure losses due to the system?
Thus you suggest:
  • fanOutlet = domain inlet
    • U: flowRateInletVelocity
    • p: zeroGradient
  • fanInlet = domain outlet
    • U: directMappedFixedValue, setAverage: massFlowRate/Area
    • p: fixedValue, p = 0

Is that right? What about epsilon and k?

mad
pingat likes this.
maddalena is offline   Reply With Quote

Old   October 5, 2010, 04:22
Default
  #14
Senior Member
 
Stefan Herbert
Join Date: Dec 2009
Location: Darmstadt, Germany
Posts: 129
Rep Power: 8
herbert is on a distinguished road
I'd would do it vice versa:
  • fanOutlet = domain inlet
    • U: directMappedFixedValue, setAverage: massFlowRate/Area
    • p: zeroGradient
  • fanInlet = domain outlet
    • U: zeroGradient
    • p: zeroGradient (+ pRefCell close to the outlet)

Quote:
Originally Posted by maddalena View Post
What about epsilon and k?
Good question! Discussion needed! I don't think it will be the constant over the fan, but at the moment I have no better idea. (If it was constant you could use directMapped again).

Regards,
Stefan
herbert is offline   Reply With Quote

Old   October 5, 2010, 04:26
Default
  #15
Member
 
Robin Gilbert
Join Date: Jan 2010
Posts: 66
Rep Power: 7
robingilbert is on a distinguished road
that looks better. like maddelena asked, what abt k and epsilon?? and for my simulation i also have Temperature field. any suggestions on that??
robingilbert is offline   Reply With Quote

Old   October 5, 2010, 04:31
Default
  #16
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 12
maddalena is on a distinguished road
Quote:
Originally Posted by herbert View Post
I'd would do it vice versa
Ok, perfect, I will try this one. What about the boundary file? Is this ok?
Code:
outletFan
    {
type directMappedPatch; nFaces xx; startFace xx; sampleMode nearestPatchFace; samplePatch inletFan; offset ( 0.0025 0 0 );
} inletFan {
type patch; nFaces xx; startFace xx;
}
Quote:
Originally Posted by herbert View Post
Good question! Discussion needed
What about using:
  • fanOutlet = domain inlet
    • U: directMappedFixedValue, setAverage: massFlowRate/Area
    • p: zeroGradient
    • epsilon, k: fixedValue $internalField
  • fanInlet = domain outlet
    • U: zeroGradient
    • p: zeroGradient (+ pRefCell close to the outlet)
    • epsilon, k: inletOutlet
However, k and epsilon will be not coupled...

Thanks for your time!

mad

Last edited by maddalena; October 5, 2010 at 04:33. Reason: Change samplePatch outletFan with samplePatch inletFan
maddalena is offline   Reply With Quote

Old   October 5, 2010, 04:36
Default
  #17
Member
 
Robin Gilbert
Join Date: Jan 2010
Posts: 66
Rep Power: 7
robingilbert is on a distinguished road
guys one more thing.... isnt there a way to modify the channelFoam to get constant flow rate across the required domain? just a thought. i tried but dint work out. maybe if someone with a better understanding can give a hint?
robingilbert is offline   Reply With Quote

Old   October 5, 2010, 04:37
Default
  #18
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 12
maddalena is on a distinguished road
One more question:
This is my 0/U:
Code:
    outletFan
    {
        type            directMappedFixedValue;
        value           uniform (1.42 0 0);
        setAverage      true;
        average         (1.42 0 0);
    }
Will the value field be used or is that only a placeholder?
I do not like to fix my fan velocity, since it will affect the velocity field inside my domain as well, while it should be calculated by the solver!
maddalena is offline   Reply With Quote

Old   October 5, 2010, 05:56
Default
  #19
Senior Member
 
Stefan Herbert
Join Date: Dec 2009
Location: Darmstadt, Germany
Posts: 129
Rep Power: 8
herbert is on a distinguished road
Quote:
Originally Posted by maddalena View Post
[...] is that only a placeholder?
Yes. It is not used as a boundary condition.
herbert is offline   Reply With Quote

Old   October 5, 2010, 06:08
Default
  #20
Senior Member
 
maddalena's Avatar
 
maddalena
Join Date: Mar 2009
Posts: 436
Rep Power: 12
maddalena is on a distinguished road
Stefan, can you comment on this?
Quote:
Originally Posted by maddalena View Post
outletFan
{
type directMappedPatch;
nFaces xx;
startFace xx;
sampleMode nearestPatchFace;
samplePatch inletFan;
offset ( 0.0025 0 0 );
}
inletFan
{
type patch;
nFaces xx;
startFace xx;
}
I am getting the following error:
Code:
--> FOAM FATAL ERROR: 

    gradientInternalCoeffs cannot be called for a genericFvPatchField (actual type directMappedFixedValue)
    on patch outletFan of field U in file "blabla/0/U"
    You are probably trying to solve for a field with a generic boundary condition.
I guess I am missing something...

mad
maddalena is offline   Reply With Quote

Reply

Tags
closed loop, directmappedpatch, fan, flowrateinletvelocity, fluxcorrectedvelocity, mass flow rate

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
mass flow rate not conserved in turbomachine, interface defined wrong? wildli FLUENT 2 July 8, 2015 11:38
UDF to measure Mass Flow Rate a.lynchy Fluent UDF and Scheme Programming 21 February 15, 2014 03:18
Mass flow rate: calculation v/s computation beguxa FLUENT 4 June 8, 2013 16:17
Target mass flow rate Saturn FLUENT 0 December 10, 2004 05:18
Mass flow rate Neser CFX 4 February 14, 2004 01:27


All times are GMT -4. The time now is 15:48.