simpleCar case does not respond to changes in DarcyForchHeimer coefficients
1 Attachment(s)
Hi,
If anyone was watching my posts, they would have seen that I am struggling with the simpleCar tutorial. But I have finally gotten it out of v2012, and it is now in OF8, where it runs. It shows a simple 2D simple car shape, with a porous media section modelling a car radiator. The problem is, no matter how I change the DarcyForchHeimer coefficients, the postprocessing results, including U and p behind the radiator, are the same; it is not recognizing changes to the DF coeffs. This includes moving the fvOptions file from system to constant, a curious change from v2012. This is a showstopper for me, and I hope that someone can point out my error. I have attached all the case files as a .gz folder. The include an image of the car from paraView Thanks for comments/help! |
Hi Alan,
Your case works just fine. :) In v2012, the tutorial uses function objects named runTimeControl. This function allow the user to define his own convergence criteria. In the tutorial, the function runTimeControl1 define a criteria based on the drag coefficient Cd: Code:
runTimeControl1 On my laptop, runTimeControl1 is satisfied at the iteration 108 and the case end at the iteration 208. But it doesn't mean the case is converged (the case stopped before satisfying the residualControl defined in fvSolution) In OpenFOAM-8, the runTimeControl function does not exist so you had to remove it in order to run the case. And it ran until satisfying the residualControl criteria. This is why you see different results in v2012 and OpenFOAM-8. Get back to the original boundary conditions and porosity coefficients then run your case for 208 iterations with OpenFOAM-8: you will get the same result than v2012. You can also remove the runTimeControl in v2012 and run the case, you will get the results you have in OpenFOAM-8 if you let run your case until it's converged. Few more tips:
Cheers, Yann |
Thanks again, Yann!
2 Attachment(s)
Although the simpleCar simulation runs okay, I think there is a problem with the results. As a check, I changed all the d and f components in fvOption to ten million (1e07). This should result in a radiator with practically zero porosity, and the flow should go around the car as if the radiator was totally plugged. Attached are images of the paraview flow, and the fvOptions settings. As can be seen, the streamlines go right through the radiator, and when I analyzed the points behind it, one of them had a Ux velocity of 8 meters per second, which is faster than those in my more porous cases! I would expect the velocity to be near zero. I simply don't believe these results.
Over the last year, I have followed a list of topics in learning OpenFoam, and the porous flow case is the next to last on my list, the final one being flow through a heated porous media (i. e. a hot radiator). Can you suggest a tutorial that addresses the last one? I'm getting close to the end, but this porous media stuff is a bit vexing! |
2 Attachment(s)
Hi Alan,
Are you running the original case or did you modify other things, e.g. boundary conditions? In OpenFOAM-8, I ran the original setup with these coefficients: Code:
d d [0 -2 0 0 0 0 0] (1e7 -100 -100); I also attached the case I ran so you can run it yourself and compare it to your own. Negative values for D and F are not valid. So when you set a negative value on one of the component, it takes the maximum component and uses the negative value as multiplier. In your last post you use this set of coefficients : (1e7 -1e7 -1e7), which means the solver actually uses this: Code:
d d [0 -2 0 0 0 0 0] (1e7 1e14 1e14); Quote:
There is no tutorial for this but it's pretty straightforward to use since you can apply it directly on your porousZone, in addition to your explicitPorositySource. Cheers, Yann EDIT: keep in mind simpleFoam uses the kinematic pressure (m2/s2). You have to multiply it by the density in order to get the correct static pressure (Pa) |
List of questions
Thanks Yann,
Not to belabor the simpleCar tutorial, but although it's small, it is full of subtleties, and as a template, it's important. All progress comes from templates! I am so appreciate that you have given of your time to help me!! Here are my questions: 1.) I'm confused about airIntake. TopoSetDict finds a small piece of the car in the region downstream of the radiator. It puts that piece into a faceSet called airIntake. That piece comes from a seemingly random spot. 2.) AirIntake feeds into 0/U, which under "surface normal with time ramping", has a list of 'intakeTypes.' Is 'intakeType' an assigned name, or is it hard coded OF terminology? What is time ramping about? This all seems quite complex. What is the purpose of 'airIntake?' 3.) The upperWall of the domain space is coded as 'wall.' Would it matter if it was 'noSlip?' That would seem more sensible to me. 4.) In controlDict, what does 'fieldAverage' do? 5.) You said negative DarcyForchHeimer values are not allowed, but you have values of -100 in fvOption. Would this be equivalent to showing 10000? Again, this seems repetitive, but I appreciate your help; without it I would be dead in the water. Alan w |
Oops, regarding 3.) 'noSip' would imply a wall. I think I meant 'patch', or maybe 'symmetry.'
|
Hi Alan,
Quote:
I think this patch is created to model the air intake for the HVAC system of the car. Toposet is used to create a faceSet then createPatch creates a new patch named airIntake, which is now listed as a domain boundary. In the 0/U file, there are 3 different boundary conditions definitions named intakeTypeN: Code:
// Surface normal with time ramping This is basically meant to demonstrate different ways to define a velocity ramp using the uniformNormalFixedValue and surfaceNormalFixedValue boundary conditions. It might come in handy if you are digging through the tutorials looking for velocity ramps examples. Then in the "boundaryField" section of the same file, one of these 3 conditions is applied on the airIntake patch: Code:
boundaryField Nothing is hard coded, the intakeTypes are just boundary conditions defined at the beginning of the file, and you can assign it to any patch in the boundaryField section. Quote:
Quote:
Quote:
I hope it helps! Yann |
Thanks Yann!
This simpleCar tutorial has other things, like intakeType, velocity time ramping, etc. which are really not germaine to the tutorial topic. As a check, I took your files and commented those things out, and it still gave the same answer. Also, negative DarcyForchHeimer coefficients d and f are taken as a multiplier, so I replaced (1e7 -100 -100) with (1e7 1e9 1e9), and still got the same results. It makes more sense to me to use the positive coefficients. So I have another template! Thanks again, you have averted showstoppers and been truly helpful. Alan w |
All times are GMT -4. The time now is 10:15. |