How to model a fan fixing the mass flow rate?

 User Name Remember Me Password
 Register Blogs Members List Search Today's Posts Mark Forums Read

 October 1, 2010, 06:00 How to model a fan fixing the mass flow rate? #1 Senior Member     maddalena Join Date: Mar 2009 Posts: 436 Rep Power: 23 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

October 4, 2010, 03:20
#2
Senior Member

Join Date: Mar 2009
Posts: 436
Rep Power: 23
Hi,
Just to say I have solved this:
Quote:
 Originally Posted by maddalena 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

 October 4, 2010, 06:10 #3 Senior Member   Eugene de Villiers Join Date: Mar 2009 Posts: 725 Rep Power: 21 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).

October 4, 2010, 07:44
#4
Senior Member

Join Date: Mar 2009
Posts: 436
Rep Power: 23
Hi Eugene,
Quote:
 Originally Posted by eugene 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 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 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

 October 4, 2010, 17:40 Hi maddelena #5 Member   Robin Gilbert Join Date: Jan 2010 Posts: 66 Rep Power: 16 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.

October 4, 2010, 17:57
#6
Member

Robin Gilbert
Join Date: Jan 2010
Posts: 66
Rep Power: 16
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);
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!!

October 5, 2010, 02:34
#7
Senior Member

Join Date: Mar 2009
Posts: 436
Rep Power: 23
Hi Robin,
Quote:
 Originally Posted by robingilbert 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?

 October 5, 2010, 03:21 #8 Senior Member   Stefan Herbert Join Date: Dec 2009 Location: Darmstadt, Germany Posts: 129 Rep Power: 17 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

October 5, 2010, 03:33
#9
Senior Member

Eugene de Villiers
Join Date: Mar 2009
Posts: 725
Rep Power: 21
Quote:
 Originally Posted by herbert 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.

October 5, 2010, 03:43
#10
Senior Member

Stefan Herbert
Join Date: Dec 2009
Posts: 129
Rep Power: 17
Quote:
 Originally Posted by eugene 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

October 5, 2010, 03:44
#11
Senior Member

Join Date: Mar 2009
Posts: 436
Rep Power: 23
Hi Stefan and thanks for joining this thread.
Quote:
 Originally Posted by herbert you know about the mass flow and your simulation is incompressible.
Yes, that is correct.
Quote:
 Originally Posted by herbert 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 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?

October 5, 2010, 03:49
#12
Senior Member

Stefan Herbert
Join Date: Dec 2009
Posts: 129
Rep Power: 17
Quote:
 Originally Posted by maddalena 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.

October 5, 2010, 03:58
#13
Senior Member

Join Date: Mar 2009
Posts: 436
Rep Power: 23
Quote:
 Originally Posted by herbert 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
• fanInlet = domain outlet
• U: directMappedFixedValue, setAverage: massFlowRate/Area
• p: fixedValue, p = 0

Is that right? What about epsilon and k?

October 5, 2010, 04:22
#14
Senior Member

Stefan Herbert
Join Date: Dec 2009
Posts: 129
Rep Power: 17
I'd would do it vice versa:
• fanOutlet = domain inlet
• U: directMappedFixedValue, setAverage: massFlowRate/Area
• fanInlet = domain outlet
• p: zeroGradient (+ pRefCell close to the outlet)

Quote:
 Originally Posted by maddalena 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

 October 5, 2010, 04:26 #15 Member   Robin Gilbert Join Date: Jan 2010 Posts: 66 Rep Power: 16 that looks better. like maddelena asked, what abt k and epsilon?? and for my simulation i also have Temperature field. any suggestions on that??

October 5, 2010, 04:31
#16
Senior Member

Join Date: Mar 2009
Posts: 436
Rep Power: 23
Quote:
 Originally Posted by herbert 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 Good question! Discussion needed
• fanOutlet = domain inlet
• U: directMappedFixedValue, setAverage: massFlowRate/Area
• epsilon, k: fixedValue \$internalField
• fanInlet = domain outlet
• p: zeroGradient (+ pRefCell close to the outlet)
• epsilon, k: inletOutlet
However, k and epsilon will be not coupled...

Thanks for your time!

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

 October 5, 2010, 04:36 #17 Member   Robin Gilbert Join Date: Jan 2010 Posts: 66 Rep Power: 16 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?

 October 5, 2010, 04:37 #18 Senior Member     maddalena Join Date: Mar 2009 Posts: 436 Rep Power: 23 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!

October 5, 2010, 05:56
#19
Senior Member

Stefan Herbert
Join Date: Dec 2009
Posts: 129
Rep Power: 17
Quote:
 Originally Posted by maddalena [...] is that only a placeholder?
Yes. It is not used as a boundary condition.

October 5, 2010, 06:08
#20
Senior Member

Join Date: Mar 2009
Posts: 436
Rep Power: 23
Stefan, can you comment on this?
Quote:
 Originally Posted by maddalena 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...

 Thread Tools Search this Thread Search this Thread: Advanced Search Display Modes Linear Mode

 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 OffTrackbacks are Off Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post wildli FLUENT 3 September 15, 2022 12:19 beguxa FLUENT 5 December 2, 2018 21:02 a.lynchy Fluent UDF and Scheme Programming 31 October 4, 2018 14:10 Saturn FLUENT 0 December 10, 2004 04:18 Neser CFX 4 February 14, 2004 00:27

All times are GMT -4. The time now is 09:59.

 Contact Us - CFD Online - Privacy Statement - Top