|
[Sponsors] |
[snappyHexMesh] Trying to understand the motorBike tutorial |
|
LinkBack | Thread Tools | Search this Thread | Display Modes |
January 26, 2010, 09:24 |
Trying to understand the motorBike tutorial
|
#1 |
New Member
Andreas Jörg
Join Date: Jan 2010
Posts: 20
Rep Power: 16 |
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: Code:
geometry { phoenix.stl { type triSurfaceMesh; name phoenix; } refinementBox { type searchableBox; min (-1.0 -0.7 0.0); max ( 8.0 0.7 2.5); } }; Code:
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; } } Code:
addLayersControls { relativeSizes true; // Per final patch (so not geometry!) the layer information layers { minZ { nSurfaceLayers 1; } phoenix { nSurfaceLayers 1; } } 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: Code:
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; } the header looks like this: Code:
FoamFile { version 2.0; format ascii; root "/home/penfold/mattijs/foam/mattijs2.1/run/icoFoam"; case "cavity"; instance "system"; local ""; class dictionary; object decomposeParDict; } Here some other lines of the code: Code:
manualCoeffs { dataFile "cellDecomposition"; } A lot of questions. I would be thankful if theres anyone who can help me. Last edited by Andyjoe; January 26, 2010 at 09:43. |
|
January 26, 2010, 13:03 |
|
#2 | |
New Member
Patrick Wang
Join Date: Dec 2009
Location: Stuttgart, Germany
Posts: 26
Rep Power: 16 |
Hey,
To your first question: Quote:
Hope this helped, Patrick |
||
January 26, 2010, 13:16 |
|
#3 |
New Member
Andreas Jörg
Join Date: Jan 2010
Posts: 20
Rep Power: 16 |
Thank you very much for your reply, it helped a lot, so the first qestion is answered now.
|
|
January 28, 2010, 02:08 |
|
#4 |
Member
|
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. |
|
January 28, 2010, 09:08 |
|
#5 |
New Member
Andreas Jörg
Join Date: Jan 2010
Posts: 20
Rep Power: 16 |
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. |
|
January 28, 2010, 10:16 |
|
#6 |
Member
|
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.
|
|
January 28, 2010, 15:02 |
|
#7 |
New Member
Andreas Jörg
Join Date: Jan 2010
Posts: 20
Rep Power: 16 |
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. |
|
January 28, 2010, 20:27 |
|
#8 |
Member
|
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. |
|
April 4, 2010, 13:21 |
|
#9 |
New Member
Scott Hogan
Join Date: Mar 2010
Location: Washington State, USA
Posts: 12
Rep Power: 16 |
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?
|
|
April 4, 2010, 20:50 |
|
#10 |
New Member
Andreas Jörg
Join Date: Jan 2010
Posts: 20
Rep Power: 16 |
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: Code:
// 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 // ************************************************************************* // |
|
August 10, 2014, 17:57 |
|
#11 |
New Member
me
Join Date: Aug 2014
Posts: 1
Rep Power: 0 |
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. |
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
motorbike tutorial | Jam Racing 2015 | OpenFOAM Pre-Processing | 8 | June 21, 2017 15:10 |
Motorbike tutorial for snappyhexmesh taking forever to run? | massive_turbulence | OpenFOAM Running, Solving & CFD | 0 | April 27, 2014 03:00 |
motorBIke Tutorial runs with kEpsilon but not with relizableKE | bastil | OpenFOAM Running, Solving & CFD | 0 | December 13, 2011 08:53 |
[snappyHexMesh] Tweaked motorbike tutorial doesn't show my icosphere | mfiandor | OpenFOAM Meshing & Mesh Conversion | 0 | October 9, 2011 19:39 |
Wrong file in motorBike tutorial? | lovecraft22 | OpenFOAM | 3 | August 4, 2011 14:03 |