[Nkl]

Hi everyone!

I am running the planeWall2D tutorial case and studying all the files. In the User Guide I've found that when in the turbulenceProperties file simulationType is set to laminar, it means that no turbulence model is employed. How is it possible than, that in the planeWall2D case a RASProperties file is included in the constant directory?

Thanks in advance!!

Regards

Nikola

[alexeym]

Hi,

Can you be more specific?

$ tut
$ pwd
$HOME/OpenFOAM/OpenFOAM-2.3.1/tutorials
$ find . -iname '*planeWall2D*'

I.e. there are no planeWall2D tutorial in official distribution.

So one can only guess why authors decided to keep RASProperties (or turbulenceProperties file, depending on solver).

[wyldckat]

Greetings to all!

@Alexey: If I have to guess, it should be this (unofficial) tutorial: http://openfoamwiki.net/index.php/Ge..._-_planeWall2D
this is odd... why didn't I create the page with the correct prefix? Mmm, OK, it's because most of the other ones don't have it either here: http://openfoamwiki.net/index.php/Main_Tutorials


@Nikola: OK, now I understand your question... it's because on this page: http://www.openfoam.org/docs/user/turbulence.php - it's currently not stated in which situations the files "turbulenceProperties", "RASProperties" and "LESProperties" are needed.
At least up to OpenFOAM 2.3.x (because things are changing in the current OpenFOAM-dev repository), these 3 files are needed only depending on the specific solver you're running. Therefore, as Alexey already hinted, you should check the tutorial cases provided in OpenFOAM, to determine which files you need for the solver to properly choose the correct turbulence model.

For these specific solvers (chtMultiRegion*Foam), only the file "RASProperties" is read, therefore, the file "turbulenceProperties" is completely ignored... OK, the tutorials aren't very reliable in this case, because they have both files. Well, when in doubt, omit the three files and run the solver; the solver will then complain which is the first file it is looking for and that is missing .

For more details, see the comments on this bug report: http://www.openfoam.org/mantisbt/view.php?id=1464

Best regards,
Bruno

[Nkl]

Exactly, that's the tutorial I was talking about. Thank you very much for the explanation Bruno!

Nikola

[Nkl]

I am still studying all the files in the tutorial. I don't understand at all the entries in the changeDictionaryDict file. Here is an example regarding the bottomAir region (the mesh has been divided into three different regions). I understand that it is changing the values of the different variables for each region, but for example what is the "bottomAir_to_.*" entry?

 dictionaryReplacement
{
    boundary
    {
        bottomAir_bottom
        {
            type            symmetryPlane;
        }
    }

    U
    {
        internalField   uniform (0.01 0 0);

        boundaryField
        {
            leftLet
            {
                type            fixedValue;
                value           uniform ( 0.1 0 0 );
            }

            rightLet
            {
                type            inletOutlet;
                inletValue      uniform ( 0 0 0 );
                value           uniform ( 0.1 0 0 );
            }

            bottomAir_bottom
            {
                type            symmetryPlane;
            }
            
            "bottomAir_to_.*"
            {
                type            fixedValue;
                value           uniform (0 0 0);
            }
        }
    }

    T
    {
        internalField   uniform 500;

        boundaryField
        {
            leftLet
            {
                type            fixedValue;
                value           uniform 500;
            }

            rightLet
            {
                type            zeroGradient;
            }

            bottomAir_bottom
            {
                type            symmetryPlane;
            }

            "bottomAir_to_.*"
            {
                type            compressible::turbulentTemperatureCoupledBaffleMixed;
                Tnbr            T;
                kappa           fluidThermo;
                kappaName       none;
                value           uniform 300;
            }
        }
    }

    epsilon
    {
        internalField   uniform 0.01;

        boundaryField
        {
            leftLet
            {
                type            inletOutlet;
                inletValue      uniform 0.01;
                value           uniform 0.01;
            }

            rightLet
            {
                type            fixedValue;
                value           uniform 0.01;
            }

            bottomAir_bottom
            {
                type            symmetryPlane;
            }

            "bottomAir_to_.*"
            {
                type            compressible::epsilonWallFunction;
                value           uniform 0.01;
            }
        }
    }

    k
    {
        internalField   uniform 0.1;

        boundaryField
        {
            leftLet
            {
                type            inletOutlet;
                inletValue      uniform 0.1;
                value           uniform 0.1;
            }

            rightLet
            {
                type            fixedValue;
                value           uniform 0.1;
            }

            bottomAir_bottom
            {
                type            symmetryPlane;
            }

            "bottomAir_to_.*"
            {
                type            compressible::kqRWallFunction;
                value           uniform 0.1;
            }
        }
    }

    p_rgh
    {
        internalField   uniform 1e5;

        boundaryField
        {
            ".*"
            {
                type            fixedFluxPressure;
                value           uniform 1e5;
            }

            bottomAir_bottom
            {
                type            symmetryPlane;
            }

            leftLet
            {
                type            fixedValue;
                value           uniform 1e5;
            }

            frontAndBack
            {
                type            empty;
            }
          
        }
    }

    p
    {
        internalField   uniform 1e5;

        boundaryField
        {
            ".*"
            {
                type            calculated;
                value           uniform 1e5;
            }

            bottomAir_bottom
            {
                type            symmetryPlane;
            }

            leftLet
            {
                type            calculated;
                value           uniform 1e5;
            }

            frontAndBack
            {
                type            empty;
            }
          
        }
    }
}

[Nkl]

So here are some more precise questions:

- why does it change the internal field from 0.1 to 0.01?
- why does it put the inletOulet condition for K and Epsilon at the leftLet (which is the inlet) instead at the rightLet, as it does for velocity field U?
- regarding field "p", why does it add a calculated boundary at the leftLet when it is already specified in the ".*"? Moreover, the entries are the same of the p filed file in the 0 folder. So what's the need of writing them again in the changeDictionaryDict?

Thanks in advance!

[alexeym]

Hi,

In general quoted things in dictionaries are regular expressions. So "bottomAir_to_.*" means anything that starts with bottomAir_to_ (dot means any character, star means 0 or more repetition). Guess it was used to make changeDictionaryDict independent from solid region name.

[Nkl]

Thanks! So, bottomAir_to indicates probably the boundary between air and solid?

[alexeym]

If you take a look at planeWall2D/0/bottomAir/p:

...
boundaryField
{
    ...
    bottomAir_to_wall
    {
        type            calculated;
        value           uniform 100000;
    }
}

wall is solid region according to planeWall2D/constant/regionProperties.

[Nkl]

Thank you a lot! Do you know the answer to my other questions?

[alexeym]

Unfortunately no. You can try to find answers in the report: http://www.tfd.chalmers.se/~hani/kur...inesqFoam7.pdf. At least there is answer to bottomAir_to_* question (on page 14).

[Nkl]

Thank you very much!

[Nkl]

One last doubt: in the tutorial you sent me (which is for openfoam-2.1, i am using 2.3.1) the U field in the changeDictionaryDict is kept the same as in the original file contained in 0, i.e. internal field is specified like this (0.1 0 0). If you take a look at mine, the internal field is changed to (0.01 0 0). This looks like a mistake, right?

[alexeym]

Well, the links to PDF that I have posted was in fact taken from the last section of http://openfoamwiki.net/index.php/Ge..._-_planeWall2D, the tutorial you said you were using.

As the page was created and maintained by Bruno Santos, I guess, you should wait for him to answer the questions. To me it looks like variations of the case that were made during test runs and somehow slipped into archives posted on the page. Also as you are running steady state solver, this initial internal field should affect only convergence time not the final result.

[wyldckat]

Greetings to all!

Originally Posted by alexeym

As the page was created and maintained by Bruno Santos, I guess, you should wait for him to answer the questions.

Good thing I checked the posts here on this thread
Alexey is right for the most part and possibly on all details. I still have to check the files, to double-check what on Earth I did back then

Nonetheless, do notice the disclaimer on the wiki page, and I quote:

Warning: You should keep in mind that these examples have not been checked to confirm if they are physically sane, since the objective is simply to introduce you, the reader, to how simulation cases can be set-up for using with these solvers. Therefore, please do properly investigate each and every single detail in this page and tutorial case and properly diagnose the results for yourself.

Now let's see...

• Originally Posted by Nkl

  - why does it change the internal field from 0.1 to 0.01?

  Alexey is right, this doesn't affect much the final solution, because this was set-up for a steady-state run; and if it wasn't, it would give a nice flow evolution .
  As the wiki page attempts to explain, this "tutorial" isn't a solved problem. It's something that is sort-of half-cooked, where the person reading/studying/learning should:
  1. Not be afraid to try things out.
  2. Train one's mind to question things and to find the answers for oneself. Remember, you're "doing science" here!
  This tutorial example was built around things that can be easily verifiable to check if the results are correct or not.

• Originally Posted by Nkl

  - why does it put the inletOulet condition for K and Epsilon at the leftLet (which is the inlet) instead at the rightLet, as it does for velocity field U?

  Good question... whoops... it was sort-of inherited from the tutorial file "heatTransfer/chtMultiRegionFoam/multiRegionHeater/system/topAir/changeDictionaryDict":
  

      epsilon
      {
          internalField   uniform 0.01;
  
          boundaryField
          {
              ".*"
              {
                  type            compressible::epsilonWallFunction;
                  value           uniform 0.01;
              }
  
              minX
              {
                  type            fixedValue;
                  value           uniform 0.01;
              }
              maxX
              {
                  type            inletOutlet;
                  inletValue      uniform 0.01;
                  value           uniform 0.01;
              }
          }
      }

  Apparently I mixed the two up, because I was in a hurry and didn't compare each part side-by-side.
  • But although these boundary conditions were incorrectly defined in the "planeWall2D" example cases, the flow profile isn't half-bad... in theory, this is because the whole field is defined to use "0.01", therefore this set-up is not expecting these turbulence fields to go much over or under "0.01".
  • I've added now this as an exercise to the suggested exercises.

• Originally Posted by Nkl

  - regarding field "p", why does it add a calculated boundary at the leftLet when it is already specified in the ".*"? Moreover, the entries are the same of the p filed file in the 0 folder. So what's the need of writing them again in the changeDictionaryDict?

  As for this issue, it seems you haven't studied any other one of OpenFOAM's tutorial cases? Because many of the solvers that handle heat transfer will operate over the "p_rgh", while the "p" field is simply:
  

  p = p_rgh + rho*g*h;

• Originally Posted by Nkl

  One last doubt: in the tutorial you sent me (which is for openfoam-2.1, i am using 2.3.1) the U field in the changeDictionaryDict is kept the same as in the original file contained in 0, i.e. internal field is specified like this (0.1 0 0). If you take a look at mine, the internal field is changed to (0.01 0 0). This looks like a mistake, right?

  Not exactly a mistake, because as I mentioned above, this is meant to make you question how the case is set-up.

Do keep in mind that although this example case is set-up in a strange way, it doesn't necessarily mean that it's incorrect, because:

1. It is possible that this case was trying to study what would happen if we start the simulation at a point where the flow rate was increased in one of the sides.
2. By fixing the turbulence values at the end, this could imply that there is something at the outlet that is forcing this to happen, for example, some sort of diffuser.

The problem here is that these two details were not mentioned in the wiki page.


Sorry if the wiki page isn't clear cut and provide ready to be used, but there were a few major reasons of why this was done in this way:

1. It takes a lot of time to make such a tutorial case to be completely accurate and correct. Time which I don't have and am not being paid to do...
2. Heat exchange simulations (as any other simulations) are something that should not be done without putting enough thought into it.
3. You're using OpenFOAM. You should test and question everything! And then to try to solve it yourself as well... because this is a pretty simple example case, that if we were to give you the fully working tutorial case, ready to be used, you would incorrectly assume it would work exactly the same for the radiator on a 3000 horse-power engine... this to say that such a complex case certainly have a ton of other details, which would make it impossible to solve if you don't first master the basics! And to always keep close by this type of simple + proven test cases so that you can ascertain what might be going wrong in the 3000 HP simulation on each particular detail/problem

Best regards,
Bruno

[Nkl]

Thanks for the exhaustive answer! I tried to solve the doubts I had on my own and I obtained reasonable results. Since I am new with OpenFOAM I was not sure about some details (how much they were important) and I may asked some irrilevant questions.

Regards!

[wyldckat]

Hi Nikola,

You're welcome! And I'm glad you're figure things out!

Your questions were in fact relevant, since you were (and are) on the right track to notice every single detail, which is a skill that is extremely necessary to have and apply when it comes to OpenFOAM! My apologies for not emphasising this sooner!

Best regards,
Bruno

[Nkl]

I have another doubt, this time regarding the way the mesh is divided into the 3 regions.
As specified in the tutorial, the top and bottom patches of the mesh are defined as symmetry planes in order that the air flows inside two pipes (the symmetry planes act as the axis of the pipes).
In the blockMesh dict the mesh is defined as a 1x1 cube.
In the topoSetDict the mesh is divided into three regions: considering y-axis, from 0 to 0.4 is the bottomAir region, from 0.4 to 0.6 the Wall and from 0.6 to 1 the topAir.
In the changeDict the bottom and top boundaries are set as symmetryPlane, as specified at the beginning of the tutorial.
When I run blockMesh, topoSet and splitMeshRegions and open the mesh in paraview, if I measure the geometry I find that it is still a 1x1 cube. From what I understand there is a redundancy. If we set the bottom and top patches as symmetry planes, shouldn't our mesh be a rectangle 3 times higher? Isn't it enough to define the regions in the topoSetDict and then assign a fixedWall boundary to the bottom and top patches?

Many thanks in advance again!

Nikola

[wyldckat]

Hi Nikola,

Originally Posted by Nkl

When I run blockMesh, topoSet and splitMeshRegions and open the mesh in paraview, if I measure the geometry I find that it is still a 1x1 cube.

In the Allrun script, you'll find this at the bottom:

echo
echo "creating files for paraview post-processing"
echo
paraFoam -touchAll

It will create the following files:

planeWall2D{bottomAir}.OpenFOAM
planeWall2D{topAir}.OpenFOAM
planeWall2D{wall}.OpenFOAM

Each one of these files will render in ParaView the respective region.
The file "planeWall2D.OpenFOAM" will show the whole original mesh.

Originally Posted by Nkl

From what I understand there is a redundancy. If we set the bottom and top patches as symmetry planes, shouldn't our mesh be a rectangle 3 times higher?

I'm not 100% certain what you meant by your question. The "symmetryPlane" is a boundary condition/definition, where it essentially it indicates that a mirror effect should occur there. It does not mean that the whole mesh will be automatically mirrored across that boundary.

Originally Posted by Nkl

Isn't it enough to define the regions in the topoSetDict and then assign a fixedWall boundary to the bottom and top patches?

Then that would mean that the pipe on each side would be half the diameter and that there was no heat transfer at the top and bottom walls.

As for using the "symmetryPlane" boundary: it's because it's sometimes the go-to option when we need to define something that is infinite, without having to create the actual mesh for it. Although more to the point, because this way we don't have a no-slip condition on those top and bottom boundaries, which would strongly affect the heat transfer process.

Again, you should not fear having to test these details yourself.

Best regards,
Bruno

[Nkl]

Thanks again for the answer.

Originally Posted by wyldckat

I'm not 100% certain what you meant by your question. The "symmetryPlane" is a boundary condition/definition, where it essentially it indicates that a mirror effect should occur there. It does not mean that the whole mesh will be automatically mirrored across that boundary.

As for using the "symmetryPlane" boundary: it's because it's sometimes the go-to option when we need to define something that is infinite, without having to create the actual mesh for it. Although more to the point, because this way we don't have a no-slip condition on those top and bottom boundaries, which would strongly affect the heat transfer process.

Ok, I tought uncorrectly that this would mirror the entire mesh. So, as far as I understand now, in this way what we see when displaying the results it's just half of the pipes geometry?
Regarding the definition of something that is infinite, isn't this done by applying the Cyclic boundary on the rightLet and leftLet? What we want is an infinite wall in those directions, right?

Nikola