CFD Online Discussion Forums
Page 1 of 3 1 23
Show 40 post(s) from this thread on one page

CFD Online Discussion Forums (https://www.cfd-online.com/Forums/)
-   OpenFOAM Running, Solving & CFD (https://www.cfd-online.com/Forums/openfoam-solving/)
-   -   How to model a fan fixing the mass flow rate? (https://www.cfd-online.com/Forums/openfoam-solving/80628-how-model-fan-fixing-mass-flow-rate.html)

maddalena October 1, 2010 06:00
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

maddalena October 4, 2010 03:20
Hi,
Just to say I have solved this:
Quote:
Originally Posted by maddalena (Post 277399)
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

eugene October 4, 2010 06:10
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).

maddalena October 4, 2010 07:44
Hi Eugene,
Quote:
Originally Posted by eugene (Post 277646)
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 (Post 277646)
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 (Post 277646)
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

robingilbert October 4, 2010 17:40
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.

robingilbert October 4, 2010 17:57
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!!

maddalena October 5, 2010 02:34
Hi Robin,
Quote:
Originally Posted by robingilbert (Post 277766)
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 :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

herbert October 5, 2010 03:21
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

eugene October 5, 2010 03:33
Quote:
Originally Posted by herbert (Post 277807)
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.

herbert October 5, 2010 03:43
Quote:
Originally Posted by eugene (Post 277809)
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

maddalena October 5, 2010 03:44
Hi Stefan and thanks for joining this thread.
Quote:
Originally Posted by herbert (Post 277807)
you know about the mass flow and your simulation is incompressible.
Yes, that is correct.
Quote:
Originally Posted by herbert (Post 277807)
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 (Post 277809)
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 :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

herbert October 5, 2010 03:49
Quote:
Originally Posted by maddalena (Post 277814)
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.

maddalena October 5, 2010 03:58
Quote:
Originally Posted by herbert (Post 277816)
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

herbert October 5, 2010 04:22
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 (Post 277819)
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

robingilbert October 5, 2010 04:26
that looks better. like maddelena asked, what abt k and epsilon?? and for my simulation i also have Temperature field. any suggestions on that??

maddalena October 5, 2010 04:31
Quote:
Originally Posted by herbert (Post 277822)
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 (Post 277822)
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

robingilbert October 5, 2010 04:36
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?

maddalena October 5, 2010 04:37
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!

herbert October 5, 2010 05:56
Quote:
Originally Posted by maddalena (Post 277828)
[...] is that only a placeholder?
Yes. It is not used as a boundary condition.

maddalena October 5, 2010 06:08
Stefan, can you comment on this?
Quote:
Originally Posted by maddalena (Post 277826)
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


All times are GMT -4. The time now is 14:56.
Page 1 of 3 1 23
Show 40 post(s) from this thread on one page