|
[Sponsors] |
simpleCar case does not respond to changes in DarcyForchHeimer coefficients |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
|
August 16, 2021, 14:04 |
simpleCar case does not respond to changes in DarcyForchHeimer coefficients
|
#1 |
Senior Member
Alan w
Join Date: Feb 2021
Posts: 268
Rep Power: 6 |
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! |
|
August 17, 2021, 11:46 |
|
#2 |
Senior Member
Yann
Join Date: Apr 2012
Location: France
Posts: 1,085
Rep Power: 26 |
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 { type runTimeControl; libs (utilityFunctionObjects); conditions { condition1 { type average; functionObject forceCoeffs1; fields (Cd); tolerance 1e-3; window 20; windowType exact; } } satisfiedAction setTrigger; trigger 1; } runTimeControl2 { type runTimeControl; libs (utilityFunctionObjects); controlMode trigger; triggerStart 1; conditions { condition1 { type maxDuration; duration 100; } } satisfiedAction end; } 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 |
|
August 17, 2021, 13:24 |
Thanks again, Yann!
|
#3 |
Senior Member
Alan w
Join Date: Feb 2021
Posts: 268
Rep Power: 6 |
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! |
|
August 18, 2021, 05:59 |
|
#4 | |
Senior Member
Yann
Join Date: Apr 2012
Location: France
Posts: 1,085
Rep Power: 26 |
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); f f [0 -1 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); f f [0 -1 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) Last edited by Yann; August 18, 2021 at 06:03. Reason: clarification |
||
August 18, 2021, 13:30 |
List of questions
|
#5 |
Senior Member
Alan w
Join Date: Feb 2021
Posts: 268
Rep Power: 6 |
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 |
|
August 18, 2021, 14:23 |
|
#6 |
Senior Member
Alan w
Join Date: Feb 2021
Posts: 268
Rep Power: 6 |
Oops, regarding 3.) 'noSip' would imply a wall. I think I meant 'patch', or maybe 'symmetry.'
|
|
August 19, 2021, 04:01 |
|
#7 | |||
Senior Member
Yann
Join Date: Apr 2012
Location: France
Posts: 1,085
Rep Power: 26 |
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 intakeType1 { type surfaceNormalFixedValue; refValue uniform 1.2; ramp table ((0 0) (10 1)); } // Uniform surface normal with Function1 for ramping intakeType2 { type uniformNormalFixedValue; uniformValue table ((0 0) (10 1.2)); } // Uniform surface normal with time ramping intakeType3 { // Or directly with uniform value (ramping also possible) type uniformNormalFixedValue; uniformValue constant 1.2; ramp table ((0 0) (10 1)); } 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 { [...] airIntake { $intakeType1; } [...] } 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:
It computes the "time" average of the velocity. This is the function creating the Umean variable in your results. Look at the system/fieldAverage file. Quote:
I hope it helps! Yann |
||||
August 22, 2021, 12:35 |
|
#8 |
Senior Member
Alan w
Join Date: Feb 2021
Posts: 268
Rep Power: 6 |
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 |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Is Playstation 3 cluster suitable for CFD work | hsieh | OpenFOAM | 9 | August 16, 2015 14:53 |
Changing the grid on the same set-up | Katya | FLUENT | 7 | October 8, 2009 16:31 |
Free surface boudary conditions with SOLA-VOF | Fan | Main CFD Forum | 10 | September 9, 2006 12:24 |
Turbulent Flat Plate Validation Case | Jonas Larsson | Main CFD Forum | 0 | April 2, 2004 10:25 |
Body force - Does it work? | Jan Rusås | CFX | 5 | August 27, 2002 09:50 |