[boffin5]

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!

[Yann]

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:

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

If the average drag coefficient remains within a 0.001 range over a window of 20 steps, it sets a trigger for the function runTimeControl2. This one will let the case run for 100 iterations before ending the run.

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:

• In OpenFOAM-8, you can put the fvOptions file in constant or system directorie, both locations will work.
• Here is some details about how you can calculate the Darcy-Forchheimer coefficients: https://openfoamwiki.net/index.php/DarcyForchheimer

Cheers,
Yann

[boffin5]

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!

[Yann]

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:

d   d [0 -2 0 0 0 0 0] (1e7 -100 -100);
f   f [0 -1 0 0 0 0 0] (1e7 -100 -100);

You can see the result on the attached picture. It seems to behave as you would expect.
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:

d   d [0 -2 0 0 0 0 0] (1e7 1e14 1e14);
f   f [0 -1 0 0 0 0 0] (1e7 1e14 1e14);

I changed the coefficients because I was getting a recirculation through the underside with the one you used.

Originally Posted by boffin5

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 usually use the effectivenessHeatExchangerSource as a fvOptions for this, with a solver such as buoyantSimpleFoam.
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)

[boffin5]

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

[boffin5]

Oops, regarding 3.) 'noSip' would imply a wall. I think I meant 'patch', or maybe 'symmetry.'

[Yann]

Hi Alan,

Originally Posted by boffin5

Thanks Yann,
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?'

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:

// 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));
 }

These 3 conditions do pretty much the same thing: ramping a velocity from 0 to 1.2m/s during the 10 first iterations of the run. The last value (1.2m/s) will remain constant for the rest of the run.

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:

boundaryField
{
    [...]

    airIntake
    {
        $intakeType1;
    }
    [...]
  }

This code basically calls the intakeType1 definition for airIntake. This trick is used to allow the user to switch between several predefined boundary conditions. You can just change $intakeType1 to $intakeType2 in order to run your case with the uniformNormalFixedValue BC instead of the surfaceNormalFixedValue BC.

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.

Originally Posted by boffin5

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.

Oops, regarding 3.) 'noSip' would imply a wall. I think I meant 'patch', or maybe 'symmetry.'

It depends on what you are trying to simulate. If this is a car in a wind tunnel, you definitely want a wall there. If this is a car in an open field, then a patch would be better, with the appropriate BC. (and you would also probably like to add a velocity on the lowerWall, since it should be moving too, relatively to the car...)

Originally Posted by boffin5

4.) In controlDict, what does 'fieldAverage' do?

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.

Originally Posted by boffin5

5.) You said negative DarcyForchHeimer values are not allowed, but you have values of -100 in fvOption. Would this be equivalent to showing 10000?

No, since I used this set of coefficient : (1e7 -100 -100), it would be equivalent to this : (1e7 1e9 1e9). The negative sign is just used as a trick to identify which component are "real values" and which ones are multipliers.


I hope it helps!
Yann

[boffin5]

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