How to model a fan fixing the mass flow rate?
 

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

Hi,
Just to say I have solved this:
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

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).

Hi Eugene,
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,
I am thinking to the approaches you suggested:This one seems the more affordable for me
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

Hi maddelena
 

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.

Hi Eugene,

I tried ur following suggestion:
i tried it using the channelFoam solver as my base to goal-seek my mass-flow rate
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!!

Hi Robin,
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 :cool:. 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?:rolleyes:

mad

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

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.

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

Hi Stefan and thanks for joining this thread.
Yes, that is correct.
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. :)
Therefore:

• fanOutlet = domain inlet
  • U: flowRateInletVelocity
  • p: directMappedFixedValue :confused:
• 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

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.

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

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)

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

that looks better. like maddelena asked, what abt k and epsilon?? and for my simulation i also have Temperature field. any suggestions on that??

Ok, perfect, I will try this one. What about the boundary file? Is this ok?
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

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?

One more question:
This is my 0/U:
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!

Yes. It is not used as a boundary condition.

Stefan, can you comment on this?
I am getting the following error:
I guess I am missing something...

mad

Hi Mad,

sorry it was my fault. The definiton in the boundary file is correct, but in your U file the BC-type must be directMapped (not directMappedFixedValue).

Sorry again,
Stefan

Ah yes! I should have noticed by myself! :o There is an example among the tutorials...
Just as an information: do you know why the BC condition is directMapped and in the /OpenFOAM/OpenFOAM-1.6.x/src/finiteVolume/fields/fvPatchFields/derived folder there are:

• directMappedFixedValue and
• directMappedVelocityFluxFixedValue?

What is the difference between the two?

Cheers

mad

I think directMappedVelocityFluxFixedValue recyles the velocity and the flux whereas directMappedFixedValue (which we are using here) only patches velocity in this case.

The biggest disadvantage of the first one if you try to apply it to your case is that you can't set the average value there. My guess is, that you could need this BC for compressible simulations where phi is not only a function of U.

Regards,
Stefan

Yes, I saw that is not possible to fix the average value when using the directMappedVelocityFluxFixedValue. This means that I cannot fix the mass flux in my case.
I have the first simulation running. I will report as soon as I have some results.
Thanks for your support.

cheers

mad

hello,

I have a heat source (constant heat addition using setFields) very next to the fan. i dont know the temperature at the fan. i just have a heat source befor it. how do i set up the temperature at the fan boundary?? do i use directMapped as well??

so its like:
fanOutlet=domain inlet
fanOutlet
{
type directMapped;
value uniform 0;
setAverage false;
}
what abt fanInlet??

Hi Robin,
are you using cht? If it is so,
I think that you can use the fan as an interface coupling, indeed this is what you do when applying the directMapped. Why do not create the two fan faces in two different regions, and then couple them using a solidWallMixedTemperatureCoupled applied to T, while U and p are as described above.
maybe you can find this thread interesting: http://www.cfd-online.com/Forums/ope...egionfoam.html I believe the discussion can be applied to a heat source in general (even defined as a setField), since we traced back the problem to the coupling condition. But perhaps you will be luckier than me... :rolleyes:

mad

i am using simpleFoam.

Hello,
bad news: the following caused velocity instabilities (i guess due to the numerics) close to the fanOutlet,

• fanOutlet = domain inlet
  • U: directMapped, setAverage: massFlowRate/Area
  • p: zeroGradient
• fanInlet = domain outlet
  • U: zeroGradient
  • p: fixedValue p = 0

You can see the velocity field in the attached picture, while there is a brief explanation of my geometry in this post. the flow goes from left to right.
Note that at the moment turbulence is switched off to not include k and epsilon.
I used the fixedValue p = 0 BC since I usually fix velocity in one of the boundary and pressure in one of the other. However, Stefan suggested here a zeroGradient + pRefCell close to the outlet. How can I get its number? where should I check it? EDIT: answer here: http://www.cfd-online.com/Forums/ope...-pressure.html

Is it correct to not fix pressure anywhere and use zeroGradient only? May the pressure fixedValue be the reason of these instabilities?

cheers

mad

No way. Simulation crashed after few time steps using the zeroGradient condition at the inlet and at the outlet. Ideas?

mad

If you have switched off turbulence, what is your Re and viscosity? If you do not have a reasonably high nu and Re is high as well, the solution will of course blow up (especially if you are using 2nd order numerics).

The flow is behaving very strangely downstream of the fan. Do you have any idea why this is? I suggest you look at the velocity values at the inlet in a bit more detail.

Hi Eugene,
I used a laminar model only on the first 100 time steps, just to help the solver. Then I switched on the turbulence.
My schemes are the following:

• gradSchemes faceMDLimited Gauss linear 0.5;
• divSchemes Gauss linearUpwindV cellLimited Gauss linear 1;
• laplacianSchemes Gauss linear limited 0.5;

and the strange behaviour of the outlet is due to the BC suggested above (k and epsilon fixedValue at the fanOutlet patch, I guess). Now I changed them in the following way:

• fanOutlet = domain inlet:
  • U: directMapped, average massflow/Area
  • p: zeroGradient;
  • k, epsilon: inletOutlet
• fanInlet = domain outlet:
  • U: zeroGradient;
  • p: fixedValue 0; pRefCell close to the outlet;
  • k, epsilon: inletOutlet

As you can see, the velocity field looks better now, even close to the fan.
In order to make the simulation more stable, I also lowered relaxation factor:

• p 0.15;
• U 0.5;
• k 0.3;
• epsilon 0.3;

This worked. After 550 time steps the velocity field does not shows any particular problems. However, pressure residual convergence is not nice, see the attached file.
What parameters should I change to tune my simulation?

mad

Hi Maddalena,

I'm not sure how to proceed next. You numerics looks stable. You could try mapping your turbulence properties as well and use pure upwind convection for turbulence. I guess you are having stability problems because there is a discontinuity in your pressure field over the fan while your velocity field is continuous. You could try reverse mapping your pressure field with a prescribed mean, but this might just make things worse. You could also try zero gradient p at the outlet, but again this will not necessarily improve stability. There is a "fixedMeanValue" boundary type in OpenFOAM-Extend that might be a better fit for your problem.

Hi Eugene and thank you for your answer.
Yes, that sounds a logical explanation. But this is a fan indeed!
Already tried that (some posts above, but it is "hidden"). You are right, stability does not improve.
Ok, this will be my following step. I will try this solution as soon as my processors will be free. Thanks once again.
Cheers

mad

Tried that, without success... :(

Hi Maddalena,

Sorry for digging out this old post.

I'd like to set the mass flow rate on a fan. But I've a problem with my mesh, and I think you could help me.
I made my mesh with Gambit, setting the fan as "fan". I import it with the "fluent3DMeshToFoam" utility. The fan become a cyclic patch, and when I give the next BC:
type flowRateInletVelocity;
patchType cyclic;
flowRate 8.79;
value uniform (2 0 0);
it's applied on both sides of the fan... with external normal :(
Could you, please, teach me how to use the mesh utilities in order to have a "fan_inlet" and a "fan_outlet"? unless there is an other solution, like giving a vector.
I've successfully tried to give a velocity, but that's not what I need.

Regards,
Nicolas

Hi Nicolas,
of course this will not work:
You cannot define something as cyclic and than apply to it a standard BC! Cyclic wants something that requires cyclic, i.e. cyclic or fan. Not something else.

As for concluding my discussion above, I used a modified simpleFoam version in such a way that some properties may be given to specific cellSets. robingilbert made this solver, so you should ask to him to have a copy of it.

mad

Hi Maddalena,

Thank you very much for your answer.
I gave up this option and dug a bit more the standard "fan" BC. In fact I had a problem since I regrouped 3 fans in the same patch. I fixed it by splitting my patch and setting up the pressure jump with the right sign for each fan.

Now this is working, I'd like to complicate.
I described my case in this thread, in which you wrote a lot :)

Regards,
Nicolas

same problem
 

Hi Maddalena,

I am trying to simulate a fan in a channel, and I am having the same problem. The pressure at the inlet of the fan is higher than the pressure at the outlet. How did you correct it?

Regards,

Dhruv.

Hello,
what is the same problem? unstable simulation or flow going on the opposite direction you want to?
What OF version are you using? starting from 2.0.0 there is a new bc to simulate fan properly: http://www.cfd-online.com/Forums/ope...essure-bc.html

mad

flow in opposite direction
 

Hi Maddalena,

thanks for the reply. The problem was flow going in opposite direction, which I have solved now, by changing the order for the patches in the boundary file.

Regards,
Dhruv