mass flow split BC
Fellow FOAMers,
i am currently simulating the flow in a tube with one inlet and two outlets. In Fluent, there is a mass flow split BC (http://hpce.iitm.ac.in/website/Manua...ug/node246.htm): if you set, e.g., 0.5 for both outlets, the inlet flow will be split to 50% for each outlet (no matter what the geometry looks like). Does something like that exist in OF? I couldn't find anything... maybe it could be built from flowRateInletVelocity? Any help or advice is appreciated. kpax |
Quote:
Such a boundary condition (or something more flexible;) ) can be constructed with groovyBC from the swak4Foam-suite which allows boundary conditions to access the values on other patches |
ok...
does someone know then how the mass flow split BC is implemented in FLUENT? I would think that the easiest way would be to adjust the pressure at the outlets in a way that ensure the prescribed mass flow split, but i'm not sure how that could be done. Or maybe modify the outlet velocities? That seems difficult to me because they can have arbitrary profiles.. |
Well there is the mass flow BC for the inlet which calculates the velocity by the mass flow and the density. Maybe you could simply take the formula of this BC to calculate the flux over the inlet and then simply set your outlet BC with the mass flow BC, but half of the inlet mass flow.
Does this help you? |
well, that was my first idea too, but as far as i understand flowRateInletVelocity, it sets a uniform velocity profile at the patch (be it outlet or inlet). at the outlet, however, i certainly have a developed velocity profile, so using this BC would not give a correct solution.
any other ideas? |
If you know your inlet mass flow, you could calculate the outlet mass flow for each pipe and assume the velocity profile to be a fully developed turbulent or laminar profile... Afaik this should be implementable using Swak4Foam or groovyBC, you just have to calculate the radial gradient of the velocity.
But then this would influence the flow behaviour upstream the outlets, too. :/ Or maybe you could specify a pressure at the outlets so that the flow departs itself in two equivalent mass flows? I think knowing the real setup you're trying to simulate would help finding the best solution! |
hey vainilreb, thx for the swift answer!
Quote:
Quote:
i could create a new solver that iteratively calculates these pressure values for every time step by applying PISO repeatedly and adjusting the p values. but i think that would be quite time-consuming, and since a simple mass flow split BC exists in fluent, i thought there must be an easier way? |
I would have made a first try by setting the pressure as fixedValue, but even then it's a tough task finding the right pressure level. I would have tried keeping pi*rē*p equal for both outlets. You could set the pressure at the smaller outlet equal to ambient pressure and calculate the pressure at the larger outlet from this value. But I can't say if it will work.
Can you give more information on flow past the outlets? If you get two equal mass flows in reality, this must result from something? Physically you must realize an equal pressure loss from inlet to outlet1 and from inlet to outlet2... Or setup a pressure acting against the flow direction, which equals the difference in pressure loss. |
Quote:
|
But it's be possible to fix all three pressure levels to get the desired mass flow without bursting into tears, does it?
|
Quote:
|
Sounds reasonable... But I'm afraid it won't help kpax to list all the things that will NOT work? :rolleyes:
|
Quote:
- inlet: fixed velocity, p zeroGradient - outlet1: fixed p. U inletOutlet - outlet2: p zeroGradient. U mass flow set to x% of inlet outlet2 for a first test could be a simple fixedValue with a calculated value. Later a groovyBC that gets the MF from the inlet. If you want a developed profile at the outlet you might use groovyBC to rescale the velocity on the outlet, but that might be a bit tricky: a) during startup b) if you have backflow. Underrelaxation might be your friend |
thx guys, I'll think I will try to implement both your idea and a pressure-adjusting solver - we'll see what works best! :>
|
I've got a slightly different, which has worked very well.
Since I knew the inlet flow rate (Q_in=40e-6 m^3 s^-1), I imposed outlet flow rates (70% / 30%), and left the velocity field as zeroGradient at the inlet. Pressure field uniform 0 at the inlet, and zeroGradient at the outlets. The BC dictionaries follow below: Code:
/*--------------------------------*- C++ -*----------------------------------*\ Code:
/*--------------------------------*- C++ -*----------------------------------*\ Rudolf |
1 Attachment(s)
If you really want to impose the inlet velocity BC, you can try this coded BC for all outlets but one.
U: Code:
/*--------------------------------*- C++ -*----------------------------------*\ Code:
/*--------------------------------*- C++ -*----------------------------------*\ It is a plug flow on outlet1, but it is developed flow on outlet2. I am not sure this is how Star-CCM+ does it, because I've heard it has plug flow in both splitted BCs, which I find funny because of the reasons Bernhard Gschaider has pointed out. Probably there is some black magic behind Star-CCM+ to keep the continuity equation right. Cheers, Rudolf |
I wasn't happy with the fixed constant pressure field at outlet1, because it looked very artificial to have both the pressure at the inlet and outlet2 changing depending on the split ratio. Therefore, against gschaider advices, I set all pressure BCs as zeroGradient, and I imposed the flow rates on both outlets. Of course, I had to set pRefCell=0 and pRefValue=0 in the fvSolution dictionary.
Surprisingly for me, the continuity residuals didn't explode, even when I oscillated the flow split ratio. I verified the flow rates in Paraview, which resulted in Phi.inlet = Phi.outlet1 + Phi.outlet2 for all times. Pressure at the inlet is constant, and it oscillates freely between outlets. It seems that this is the way StarCCM+ does that, according to what I've seen from simulations using the flow split BC in StarCCM+. In Star, the split BCs have constant velocity at the outlet, and pressure is not constraint. The OpenFOAM BC dictionaries follow: p: Code:
/*--------------------------------*- C++ -*----------------------------------*\ Code:
/*--------------------------------*- C++ -*----------------------------------*\ blockMeshDict: Code:
/*--------------------------------*- C++ -*----------------------------------*\ Best regards, Rudolf |
I transcribed the codedFixedValue that I used above to prototype my BC to an actual C++ BC class. I used the template given by the foamNewBC -f -v script. The new BC name is flowSplit, and its class is called flowSplitFvPatchVectorField.
flowSplitFvPatchVectorField working, but not exactly as the codedFixedValue. It is not converging with all pressure BCs as zeroGradient and a pRefCell. I have now to set a pressure BC as fixedValue. I don't know why is that happening. Otherwise, the solution is correct. flowSplitFvPatchVectorField.H Code:
/*---------------------------------------------------------------------------*\ Code:
/*---------------------------------------------------------------------------*\ |
Ok, I've figured it out. The BC class generated by codedFixedValue has a the constructor:
Code:
flowSplit1FixedValueFvPatchVectorField:: I've solved this issue by including a patch initialisation within the constructor, as suggested by the foamNewBC script: Code:
Foam::flowSplitFvPatchVectorField:: All the best, Rudolf |
Sorry, I wanted to delete this post.
|
All times are GMT -4. The time now is 05:12. |