[maddalena]

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]

Hi,
Just to say I have solved this:

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

maddalena

[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. 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]

Hi Eugene,

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,

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

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

mad

[robingilbert]

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]

Hi Eugene,

I tried ur following suggestion:

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

        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]

Hi Robin,

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?

mad

[herbert]

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]

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.

[herbert]

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

[maddalena]

Hi Stefan and thanks for joining this thread.

Originally Posted by herbert

you know about the mass flow and your simulation is incompressible.

Yes, that is correct.

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.

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?

mad

[herbert]

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.

[maddalena]

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
  • p: zeroGradient
• fanInlet = domain outlet
  • U: directMappedFixedValue, setAverage: massFlowRate/Area
  • p: fixedValue, p = 0
  
  

Is that right? What about epsilon and k?

mad

[herbert]

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)

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

[robingilbert]

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]

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?

outletFan
    {
         type directMappedPatch;
        nFaces xx;
        startFace xx;
        sampleMode      nearestPatchFace;
        samplePatch     inletFan;
        offset          ( 0.0025 0 0 );
}
    inletFan
    {
         type patch;
        nFaces xx;
        startFace xx;
}

Originally Posted by herbert

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]

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]

One more question:
This is my 0/U:

    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]

Originally Posted by maddalena

[...] is that only a placeholder?

Yes. It is not used as a boundary condition.

[maddalena]

Stefan, can you comment on this?

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:

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