[Andyjoe]

Hello,

scince I'm able to configure an run simple OpenFoam cases, I went through the motorBike tutorial the last days. Everything worked. So I changed the stl file with a new geometry made in Blender. A big surprise happend: it worked imediately. Motivated by that, I began to write a superSonic case. I still used the "windtunnel" and the snappyHexMeshDict from the motorBike tutorial. After some trying it worked, but at a certain time the simulation stoped, because of too many iterations. Have I done anything wrong or is this a numerical problem?
Scince I want to apply the data in real life, it would be better, to know what I do. So I tryed to understand the motorBike tutorial in detail. But there are almost no explanations anywhere. Here some things, I don't understand:
First to the snappyHexMeshDict:

geometry
{
    phoenix.stl
    {
        type triSurfaceMesh;
        name phoenix;
    }

    refinementBox
    {
        type searchableBox;
        min (-1.0 -0.7 0.0);
        max ( 8.0  0.7 2.5);
    }
};

I don't understand the refinemantBox. Actually I found some text in the Internet about it, but it's still not clear. Is it a place, from which the refinement of the Mesh starts?

addLayersControls
{
    relativeSizes true;

    // Per final patch (so not geometry!) the layer information
    layers
    {
        minZ
        {
            nSurfaceLayers 1;
        }
        motorBike_frt-fairing:001%1
        {
            nSurfaceLayers 1;
        }
        motorBike_windshield:002%2
        {
            nSurfaceLayers 1;
        }
        motorBike_rr-wh-rim:005%5
        {
            nSurfaceLayers 1;
        }
        motorBike_rr-wh-rim:010%10
        {
            nSurfaceLayers 1;
        }
        motorBike_fr-wh-rim:011%11
        {
            nSurfaceLayers 1;
        }
        [... and so on ...]
        }
        motorBike_radiator-shadow%86
        {
            nSurfaceLayers 1;
        }
        motorBike_rear-shock-link-shadow%87
        {
            nSurfaceLayers 1;
        }
        motorBike_rear-brake-fluid-pot-bracket-shadow%88
        {
            nSurfaceLayers 1;
        }
        motorBike_rr-wh-chain-hub-shadow%89
        {
            nSurfaceLayers 1;
        }
    }

I don't know, what the %number , for example %88 means. Is it ok for my case, when I write

addLayersControls
{
    relativeSizes true;

    // Per final patch (so not geometry!) the layer information
    layers
    {
        minZ
        {
            nSurfaceLayers 1;
        }
        phoenix
        {
            nSurfaceLayers 1;
        }
    }

Has anyone an idea, what minZ means?
When I start the case, the terminal shows me, that many patches of the stl file are read in, 8224. So in the boundary file I've got 8224 patches. Is this ok? If yes, why this is done? Wouldn't it be enough to have one wall? Actually the original motorBike boundary file hasn't as much patches, only the patches mentioned in the layer definition in the snappyHexMeshDict.
My boundary file looks like this:

   8230
(
    frontAndBack
    {
        type            patch;
        nFaces          440;
        startFace       1580732;
    }
    inlet
    {
        type            patch;
        nFaces          64;
        startFace       1581172;
    }
    outlet
    {
        type            patch;
        nFaces          64;
        startFace       1581236;
    }
    lowerWall
    {
        type            wall;
        nFaces          4366;
        startFace       1581300;
    }
    upperWall
    {
        type            patch;
        nFaces          244;
        startFace       1585666;
    }
    phoenix_patch0
    {
        type            wall;
        nFaces          0;
        startFace       1585910;
    }
   [..... all patches look similar....]
    }
    phoenix_patch8223
    {
        type            wall;
        nFaces          0;
        startFace       1585910;
    }
   phoenix_patch8224
    {
        type            wall;
        nFaces          108556;
        startFace       1585910;
    }

Furthermore I wanted to ask something about the decomposeParDict
the header looks like this:

FoamFile
{
    version         2.0;
    format          ascii;

    root            "/home/penfold/mattijs/foam/mattijs2.1/run/icoFoam";
    case            "cavity";
    instance        "system";
    local           "";

    class           dictionary;
    object          decomposeParDict;
}

Seemingly there is a path of the computer of the developer of this file. Because my root would be /home/andreas. I think I have to change it. But this file is out of the motorBike tutorial. Why there is "case "cavity" "?
Here some other lines of the code:

manualCoeffs
{
    dataFile        "cellDecomposition";
}

I used the search function of my computer, but couldn't find any file "cellDecomposition".
A lot of questions. I would be thankful if theres anyone who can help me.

[foam_noob]

Hey,

To your first question:

Originally Posted by Andyjoe

I don't understand the refinemantBox. Actually I found some text in the Internet about it, but it's still not clear. Is it a place, from which the refinement of the Mesh starts?

With min max you define two points in your mesh. Later you can define the refinement level with the refinement box. All the cells within the box will have this value as their refinement level.

Hope this helped,

Patrick

[Andyjoe]

Thank you very much for your reply, it helped a lot, so the first qestion is answered now.

[thekay]

A bit trivial, but: Have you tried lowering the time step to see if it converges? With supersonic flows it needs to calculate values in smaller time intervals so your simulation does not get out of hand with divergence.

Hope this helps.

[Andyjoe]

Thank you for replying. I used a time step of 2*10^-8s first. Because this is very small, I tried an timestep of 2*10^-5s too, of course it crashes earlier then. Do you think it would make sense, to try even a smaller timestep than
2*10^-8s. I would have the chance too let my case run on a super computer. But scince it crashes, I thought, that this wouldn't make sense at the moment. But it would be possible to decrease the time step, because the supercomputer should simulate them very fast.

[thekay]

You need to go lower then (shorter time). I would try 2*10^-10 and see how it goes. And as you said, since it crashes, it makes no sense trying to run it on a supercomputer. It will only crash faster! Try to have it running for a reasonable amount of time and if it doesn't crash it's an indication (but nothing more than a mere indication, if you are not very experienced with predicting which timestep will do best for you) that it will run until the end.

[Andyjoe]

I try 2*10^-10s, and it is still running scince a few hours. I think I have to stop the simulation tomorrow. The problem is, that the time I can simulate is only limited, and in 10^-6s there isn't much change. Is it possible, that the system crashes after a certain time, for example the time, in which the influence of the body reaches the bigger cell cized regions more far away from the body?.
And I wonder if there is a physical sense to simulate a timestep of 2*10^-10s. This is the time, in which light travels 6cm. What is the smallest timestep you ever used? At the moment I'm a beginner and have almost no experience.

[thekay]

The physical meaning of having very small time steps is that the pressure changes that are the reason behind the shock waves formation in supersonic speeds are so rapid, that you need very small time steps to capture them. You have a compressible solver running and at those speeds you expect to see shock waves. If the time step cannot capture the shock wave your solution will not be accurate and ultimately it will diverge. Also, you have a very large domain and it is inevitable that it will take some time. If with a smaller time step you have exceeded the time at which the simulation crashed with the larger time step, the size of the previous (larger) time step was your problem. I had been running a flow of 800m/s with sonicFoam in a domain of a bit more than million elements and it took about 48 hours to simulate on 8 processors. So this might give you an idea on how long you need to wait.

Some other thoughts/suggestions: take note of the time at which the simulation crashes and see if it goes on after that time with a smaller time step (as mentioned above).
When it crashes, I reckon pressure diverges with this particular solver. See the crash log from top to bottom (last 2-3 time steps will do in most cases). Also check pressure (or other values) at the time step BEFORE the crash. Iterations, final residual, etc. It will give you a good indication on what diverged (if this is the case). Post the previous and last time step from your log if you like.

Good luck.

[shogan50]

I'm a newb and haven't attempted this tutorial because I only have 2 processors at the moment, but I am curious why "adjustTimeStep" isn't used or being suggested. In the limited simulations I have done, I have used this feature with rhoPisoFoam solver for flows that are approximately .4 Ma. Is it perhaps not applicable to some of the other solvers or supersonic flow?

[Andyjoe]

Hello,
it should be no problem, that you have only 2 processors. You dont have to run the decomposePar routine. Consequently the case runs only on one core. But of course the decomposeParDict file can be changed in a way, that the tutorial runs on 2 cores. This could look like this:

// The FOAM Project // File: decomposeParDict
/*
-------------------------------------------------------------------------------
 =========         | dictionary
 \\      /         | 
  \\    /          | Name:   decomposeParDict
   \\  /           | Family: FoamX configuration file
    \\/            | 
    F ield         | FOAM version: 2.1
    O peration     | Product of Nabla Ltd.
    A and          | 
    M anipulation  | Email: Enquiries@Nabla.co.uk
-------------------------------------------------------------------------------
*/
// FoamX Case Dictionary.

FoamFile
{
    version         2.0;
    format          ascii;
    instance        "system";
    local           "";

    class           dictionary;
    object          decomposeParDict;
}

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //


numberOfSubdomains 2;

method          hierarchical;
//method          metis;
//method          parMetis;

simpleCoeffs
{
    n               (2 1 1);
    delta           0.001;
}

hierarchicalCoeffs
{
    n               (2 1 1);
    delta           0.001;
    order           xyz;
}

/*manualCoeffs
{
    dataFile        "cellDecomposition";
}*/

metisCoeffs
{
    //n                   (5 1 1);
    //cellWeightsFile     "constant/cellWeightsFile";
}
distributed     yes;

roots ("/home/user/OpenFOAM/OpenFOAM-1.6/");   // mostly it is necessary to change this line when running on an other computer

// ************************************************************************* //

I think it should be possible to use adjustTimeStep. Because it just checks the courent number and if its too high (over the limit set in the line below), it sets the timestep to a lower value. But of course I havent tried this function with every solver.

[aero3]

Hi Andyjoe,

As you, I tried to simply replace the 3D model of the motorBike tutorial and the result is really bad. Openfoam perform the calculation but the result is horrible as you can see on the link below:
http://api.ning.com/files/9677Xpk6On...penfoambug.jpg

I greatly improve the resolution of my wing on Blender and export on a stl (ascii) format as said on forums but same result...

Did you had this problem?
Thanks.