|
[Sponsors] |
October 6, 2017, 17:26 |
simpleFoam - wrong results?
|
#1 |
New Member
Join Date: Oct 2017
Posts: 13
Rep Power: 9 |
Good evening Foamers! I’m rather new in terms of using OF (I’m switching from Ansys) and I don’t know why I obtain wrong results in presumably very simple simulation. To cut a long story short, I’d like to simulate a flow in the pipe (10 mm diameter, 300 mm length). On the inlet I set velocity equal to 0.97 m/s, whereas on the outlet pressure equal to 15 kPa (since the density of the fluid is 1050 kg/m3, the kinematic pressure is equal to 14.29 m2/s2). I’m using simpleFoam solver in which I assume a laminar flow - the Reynolds number is not so high – around 3000 (anyway I got a question about turbulence, but I’ll come to that later on).
Here you can see my boundary condition files and some data files: pressure file: Code:
dimensions [0 2 -2 0 0 0 0]; internalField uniform 0; boundaryField { thatIsWall { type zeroGradient; } outletPatch { type fixedValue; value uniform 14.29; } inletPatch { type zeroGradient; } } Code:
dimensions [0 1 -1 0 0 0 0]; internalField uniform (0 0 0); boundaryField { thatIsWall { type fixedValue; value uniform (0 0 0); } outletPatch { type zeroGradient; } inletPatch { type surfaceNormalFixedValue ; refValue -0.97; } } Code:
simulationType laminar; RAS { RASModel kOmegaSSTSAS; turbulence off; printCoeffs off; } Code:
application simpleFoam; startFrom startTime; startTime 0; stopAt endTime; endTime 2.0; deltaT 0.005; writeControl runTime; writeInterval 0.1; purgeWrite 0; writeFormat ascii; writePrecision 6; writeCompression off; timeFormat general; timePrecision 6; runTimeModifiable false; Code:
transportModel Newtonian; nu [ 0 2 -1 0 0 0 0 ] 3.3e-06; The second question is connected with modeling turbulence – I’d like to use RAS kwSST model. For the simulation where I use Newtonian liquid and I know the inlet velocity, I can easily calculate the Reynolds number and some other turbulence parameters necessary to create files. What about a situation for the outlets (where I don’t know the velocity, only pressure) and what about a situation when I don’t know the viscosity (cause e.g. I’m using a power law model)? Thank you in advance for your time and help! Zibi |
|
October 8, 2017, 08:05 |
|
#2 |
Senior Member
|
Hi,
It seems, you simulation is just diverging (or is not converged at 2 s, simpleFoam is steady-state solver, so 2 s do not make real sense, let's call it 400 iterations). Could you post: 1. checkMesh output. 2. Solver output just before the end of simulation. Or just whole log-file, since simulation is not long. |
|
October 8, 2017, 12:16 |
|
#3 |
New Member
Join Date: Oct 2017
Posts: 13
Rep Power: 9 |
Hello Alexeym,
I'm grateful for your fast response. Indeed, I should have written '400 iterations', thank you for making a clarification. I decided to attach a log file as a separate file, whereas checkMesh output (and also the last solver output) can be found below. checkMesh: Code:
Mesh stats points: 32832 internal points: 21249 faces: 332307 internal faces: 309145 cells: 160363 faces per cell: 4 boundary patches: 3 point zones: 0 face zones: 0 cell zones: 0 Overall number of cells of each type: hexahedra: 0 prisms: 0 wedges: 0 pyramids: 0 tet wedges: 0 tetrahedra: 160363 polyhedra: 0 Checking topology... Boundary definition OK. Cell to face addressing OK. Point usage OK. Upper triangular ordering OK. Face vertices OK. Number of regions: 1 (OK). Checking patch topology for multiply connected surfaces... Patch Faces Points Surface topology inletPatch 179 106 ok (non-closed singly connected) outletPatch 179 106 ok (non-closed singly connected) thatIsWall 22804 11433 ok (non-closed singly connected) Checking geometry... Overall domain bounding box (-0.005 -0.005 0) (0.005 0.005 0.3) Mesh has 3 geometric (non-empty/wedge) directions (1 1 1) Mesh has 3 solution (non-empty) directions (1 1 1) Boundary openness (-8.6468e-018 1.35511e-017 7.75888e-019) OK. Max cell openness = 2.53749e-016 OK. Max aspect ratio = 6.17915 OK. Minimum face area = 1.64551e-007. Maximum face area = 1.69073e-006. Face area magnitudes OK. Min volume = 3.26337e-011. Max volume = 7.12368e-010. Total volume = 2.3447e-005. Cell volumes OK. Mesh non-orthogonality Max: 56.5526 average: 16.2739 Non-orthogonality check OK. Face pyramids OK. Max skewness = 0.641243 OK. Coupled point location match (average 0) OK. Mesh OK. End Code:
Time = 2 smoothSolver: Solving for Ux, Initial residual = 0.0309148, Final residual = 0.00308236, No Iterations 1 smoothSolver: Solving for Uy, Initial residual = 0.0314383, Final residual = 0.000396976, No Iterations 2 smoothSolver: Solving for Uz, Initial residual = 0.0168423, Final residual = 0.000215721, No Iterations 2 GAMG: Solving for p, Initial residual = 0.128034, Final residual = 0.00434386, No Iterations 2 time step continuity errors : sum local = 0.0641924, global = -0.000195599, cumulative = -0.316464 ExecutionTime = 522.224 s ClockTime = 522 s End In the log file, there is an initial warning concerning the usage of surfaceNormalFixedValue - when I use fixedValue boundary condition this warning is gone, however, results are the same. Hence, it doesn't have an impact on the simulation results. I had to remove some lines since the size of the file was too big (decided to remove results from time 1.22 to 1.59). Zibi |
|
October 9, 2017, 04:47 |
|
#4 |
Senior Member
|
Hi,
Let's start with your mesh. It is tetrahedral with maximum non-orthogonality of 55 degrees. For such a mesh I would propose to use leastSquares gradient scheme and 2 non-orthogonal correctors. It is hard to figure out your schemes from log, yet it is clear, you do not have non-orthogonal corrector iterations at all. To avoid warning with surfaceNormalFixedValue, use Code:
refValue uniform -0.97; |
|
October 9, 2017, 09:12 |
|
#5 | |
New Member
JD
Join Date: May 2017
Posts: 24
Rep Power: 9 |
Quote:
Just based on your response here, I'd like to know how does one come to a conclusion on grad schemes based on the mesh. Sincerely. |
||
October 9, 2017, 15:40 |
|
#6 |
Senior Member
|
Hi,
@dickcruz There are: 1. https://ntrs.nasa.gov/archive/nasa/c...0140011550.pdf 2. https://hal.archives-ouvertes.fr/hal-01532882 3. http://www.tfd.chalmers.se/~hani/kur...stPractice.pdf First two papers discuss order of accuracy of Gauss-Green theorem for estimation of gradients, third is just general "best practices". In general, in tutorial cases "Gauss linear" is used, which is not quite applicable for non-orthogonal meshes. |
|
October 9, 2017, 20:01 |
|
#7 |
New Member
Join Date: Oct 2017
Posts: 13
Rep Power: 9 |
Hello,
I changed all the data you proposed, however, unfortunately I still obtain wrong results: near the inlet the pressure is the highest (3.5e+4 m2/s2) and it gradually decreases till the outlet which has -6.753+3 m2/s2 (yes, with negative sign...). Concerning velocity, the highest values are in the vicinity of the outlet (206.5 m/s), whereas the smallest near the inlet (0.0 m/s, don't know why, since the boundary condition imply that it should be constantly 0.97 m/s). I attach new log file as an attachment and some scripts below: fvSolution: Code:
solvers { p { solver GAMG; smoother GaussSeidel; cacheAgglomeration on; agglomerator faceAreaPair; nCellsInCoarsestLevel 10; mergeLevels 1; tolerance 1e-7; relTol 0.1; } U { solver smoothSolver; smoother symGaussSeidel; tolerance 1e-7; relTol 0.1; } } SIMPLE { residualControl { p 1e-6; U 1e-6; } nNonOrthogonalCorrectors 2; } relaxationFactors { fields { p 0.3; } equations { U 0.7; } } Code:
ddtSchemes { default steadyState; } gradSchemes { default leastSquares; //default Gauss linear; //limited cellLimited Gauss linear 1; //grad(U) $limited; //grad(k) $limited; //grad(epsilon) $limited; } divSchemes { default none; div(phi,U) bounded Gauss linearUpwind limited; //div(phi,U) Gauss linear; turbulence bounded Gauss limitedLinear 1; div(phi,k) $turbulence; div(phi,epsilon) $turbulence; div((nuEff*dev2(T(grad(U))))) Gauss linear; } laplacianSchemes { default Gauss linear corrected; } interpolationSchemes { default linear; } snGradSchemes { default corrected; } Zibi Last edited by Zibi; October 9, 2017 at 20:05. Reason: small typo |
|
October 10, 2017, 06:48 |
|
#8 |
Senior Member
|
Hi,
It would be MUCH easier if you post your case, cause posts are becoming inconsistent. Initially you said, you set fixed value for pressure at the outlet and it was positive, now it is negative. You still do not reach convergence, so values are a little bit meaningless. In the log file there is no signs of convergence, so, guess, you messed up boundary conditions. Strictly speaking "Gauss linear" is applicable only to the case of orthogonal meshes (this is what papers 1 and 2 are about). So I would use leastSquares even for 20 degrees of non-orthogonality. Last edited by alexeym; October 10, 2017 at 06:53. Reason: Forgotten Gauss linear part |
|
October 10, 2017, 08:43 |
|
#9 |
New Member
Join Date: Oct 2017
Posts: 13
Rep Power: 9 |
Hello,
My case is as follows: I want to simulate a flow of the incompressible liquid (density equal to 1050 kg/m3) in the straight pipe (0.3 m length and 0.01 m diameter). It is a steady-state simulation, so I decided to use simpleFoam solver. Boundary conditions are as follows: inlet: velocity equal to 0.97 m/s, outlet: pressure equal to 15 kPa (so 14.29 m2/s2). I don't know how can I upload the entire case since all files weight too much (mainly those connected with polyMesh). Anyway, I copy all other files (boundary conditions, fvSolutions, etc.) once more. U file: Code:
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: 3.0.x | | \\ / A nd | Web: www.OpenFOAM.org | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class volVectorField; object U; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // dimensions [0 1 -1 0 0 0 0]; internalField uniform (0 0 0); boundaryField { thatIsWall { type fixedValue; value uniform (0 0 0); } outletPatch { type zeroGradient; } inletPatch { type surfaceNormalFixedValue ; refValue uniform -0.97; } } Code:
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: 3.0.x | | \\ / A nd | Web: www.OpenFOAM.org | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class volScalarField; object p; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // dimensions [0 2 -2 0 0 0 0]; internalField uniform 0; boundaryField { thatIsWall { type zeroGradient; } outletPatch { type fixedValue; value uniform 14.29; } inletPatch { type zeroGradient; } } Code:
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: 3.0.x | | \\ / A nd | Web: www.OpenFOAM.org | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class dictionary; object RASProperties; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // transportModel Newtonian; nu [ 0 2 -1 0 0 0 0 ] 3.3e-06; Code:
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: 3.0.x | | \\ / A nd | Web: www.OpenFOAM.org | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class dictionary; object RASProperties; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // simulationType laminar; RAS { RASModel kOmegaSSTSAS; turbulence off; printCoeffs off; } Code:
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: 3.0.x | | \\ / A nd | Web: www.OpenFOAM.org | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class polyBoundaryMesh; location "constant/polyMesh"; object boundary; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // 3 ( inletPatch { type patch; nFaces 179; startFace 309145; } outletPatch { type patch; nFaces 179; startFace 309324; } thatIsWall { type wall; nFaces 22804; startFace 309503; } ) Code:
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: 3.0.x | | \\ / A nd | Web: www.OpenFOAM.org | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class dictionary; object controlDict; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // application simpleFoam; startFrom startTime; startTime 0; stopAt endTime; endTime 2.0; deltaT 0.005; writeControl runTime; writeInterval 0.1; purgeWrite 0; writeFormat ascii; writePrecision 6; writeCompression off; timeFormat general; timePrecision 6; runTimeModifiable false; Code:
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: 3.0.x | | \\ / A nd | Web: www.OpenFOAM.org | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class dictionary; object fvSchemes; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // ddtSchemes { default steadyState; } gradSchemes { default leastSquares; } divSchemes { default none; div(phi,U) bounded Gauss linearUpwind limited; turbulence bounded Gauss limitedLinear 1; div(phi,k) $turbulence; div(phi,epsilon) $turbulence; div((nuEff*dev2(T(grad(U))))) Gauss linear; } laplacianSchemes { default Gauss linear corrected; } interpolationSchemes { default linear; } snGradSchemes { default corrected; } Code:
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: 3.0.x | | \\ / A nd | Web: www.OpenFOAM.org | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format ascii; class dictionary; object fvSolution; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // solvers { p { solver GAMG; smoother GaussSeidel; cacheAgglomeration on; agglomerator faceAreaPair; nCellsInCoarsestLevel 10; mergeLevels 1; tolerance 1e-7; relTol 0.1; } U { solver smoothSolver; smoother symGaussSeidel; tolerance 1e-7; relTol 0.1; } } SIMPLE { residualControl { p 1e-6; U 1e-6; } nNonOrthogonalCorrectors 2; } relaxationFactors { fields { p 0.3; } equations { U 0.7; } } Zibi Last edited by Zibi; October 10, 2017 at 08:46. Reason: small typo |
|
October 10, 2017, 10:50 |
|
#10 |
Senior Member
|
Without mesh it would be difficult to find error in your case. Reduce order of discretisation schemes, increase number of iterations.
I have created test 2D axisymmetric case with the same geometry and boundary conditions. It needs et least 407 iterations to converge with upwind discretisation (with second order schemes it even does not converge in laminar case). You can find archived case attached to the message. |
|
October 10, 2017, 13:48 |
|
#11 |
New Member
Join Date: Oct 2017
Posts: 13
Rep Power: 9 |
Hello,
I tried to run a case you sent and it took 418 iteration to converge - the results seem to be appropriate. Hence, unfortuanetly, constant failures are connected with my mesh... Could I somehow provide you with my mesh file, so you could inspect whether all failures are due to it? Zibi Last edited by Zibi; October 10, 2017 at 13:57. Reason: corrected information |
|
October 10, 2017, 14:29 |
|
#12 |
Senior Member
|
There are (in order of my familiarity with the service):
1. Dropbox 2. Microsoft OneDrive 3. Google Docs With all of them you can upload your case and post a link to it. You can even use GitHub or BitBucket to create repository with your case. |
|
October 10, 2017, 20:16 |
|
#13 |
New Member
Join Date: Oct 2017
Posts: 13
Rep Power: 9 |
Here is a link to DropBox files with that case:
https://www.dropbox.com/s/yqo58n2dac..._Case.rar?dl=0 Please have a look at those files. Thank you for your time and help. Zibi |
|
October 11, 2017, 06:38 |
|
#14 |
Senior Member
|
I though RAR was dead, but no, it is second time people send me RAR archive.
If you run Code:
checkMesh -allGeometry -allTopology If you set initial conditions for velocity to (0 0 0.97) instead (0 0 0), it could possible to converge with your mesh and limited non-orthogonal correction (i.e. "limited 0.333" instead of "corrected" in laplacian and snGrad schemes). Though finally I have decided, it is a waste of time (it is 400th iteration and residuals for velocity are around 0.003). Attached is a 3D case with the same geometry BUT with a slightly better mesh. It converges in 99 iterations with the second order spatial discretisation schemes. |
|
October 11, 2017, 17:48 |
|
#15 |
New Member
Join Date: Oct 2017
Posts: 13
Rep Power: 9 |
Hello,
Thanks for the files - your case works perfectly, apart from the noSlip condition - my OpenFOAM doesn't recognize it, hence, I switched to fixed value (0 0 0) on the walls. Forgot to mention that during the earlier case. I checked my mesh with the more advanced checkMesh method as you proposed and you are right - mesh has some errors. That's extremely bad news for me - in my future work I've to use opensource software that creates volumetric mesh from the STL files (without named patches). It's a VMTK software: it loads STL file, performs cuts to open oulets/inlets (simultaneously user can indicate names of particular patch), generates volumetric mesh basing on the surface triangles and then tetrahedralizes it. Afterwards, it saves the Fluent file. I tested it today on a relatively simple geometry, to be precise: a bended pipe. Traditional checkMesh option says that mesh is fine, however, the more advanced one outlines several errors. And that's terrible since I cannot improve the mesh topology. Do you have any idea how to fix/overcome this obstacle or is it a dead end for me? P.S. Sorry for the late reply, but I wanted to test VMTK output mesh (Fluent mesh) prior to posting. Zibi Last edited by Zibi; October 11, 2017 at 17:50. Reason: added info |
|
October 12, 2017, 09:48 |
|
#16 |
Senior Member
|
Hi,
If you need to generate mesh for OpenFOAM from STL, why no use: 1. snappyHexMesh 2. foamyHexMesh 3. cfMesh All of them will try to generate hexahedral-dominant meshes and will write them directly in OpenFOAM format. In your algorithm of mesh generation I see to many points of failure. I do not know quality of meshes generated by VMTK; I do not know if VMTK writes Fluent files correctly; I do not know if Fluent files, written by VMTK, can be converted to OpenFOAM correctly. If VMTK is The Vascular Modeling Toolkit, then it can write meshes in other formats, it can generate meshes with boundary layers; though it generates meshes mainly for FEM software. Why not try FEniCS? |
|
October 12, 2017, 12:42 |
|
#17 |
New Member
Join Date: Oct 2017
Posts: 13
Rep Power: 9 |
I wanted to give snappyHexMesh a try some time ago, however, my program generates pure STL files - edges between inlet/outlet and adjacent wall are not always sharp (due to marching cubes algorithm), so the 'user' has to cut those areas off and create a proper boundary. Moreover, snappyHexMesh requires STLs with named patches, but STLs that I obtain are label-less. Those two arguments made me use VMTK software.
Concerning the FEniCS software, I haven't ever heard of it. Will try to figure it out - well, I guess I don't have another option anyway. Zibi |
|
October 12, 2017, 17:49 |
|
#18 |
Senior Member
|
Maybe I did not get your message right, but I have looked at my cases, where I generate mesh with snappyHexMesh, and STLs there are without any labels. Background mesh defines boundaries, STL surface defines another boundary (so, it is either a hole in the mesh defined by STL or mesh outer surface defined by STL).
So, unfortunately, I do not get your problems with snappyHexMesh. Maybe you can come up with an example case? Also VMTK can generate meshes, that are more suitable for OpenFOAM, it depends of settings, you provide to the software. |
|
October 12, 2017, 18:35 |
|
#19 |
New Member
Join Date: Oct 2017
Posts: 13
Rep Power: 9 |
I will try to explain what I'd like to achieve in my work. I'd like to perform a simulation of the blood flow inside the human cerebral arteries. Moreover, I'd like to create a software that automatically (or at least with minimal user interaction) performs meshing and generates openfoam scripts. I'm reconstructing a complex geometry of the human brain arteries and software I created (so far) can export the STL file of that geometry. To obtain flat surfaces on inlets/outlets I have to somehow cut off specific parts and recreate the flat plane (VMTK is used for that purpose). Since I'd like to simulate a flow inside those arteries, I've to create the internal volumetric mesh (like in Ansys CFX) and again VMTK is used in here. It can export numerous types of meshes, including the Fluent mesh (.MSH) that can be loaded into the Ansys Fluent, CFX and presumably OpenFOAM. Here are some other formats: vtk, ngneut, gambit, tetgen. Unfortunately, as you could observe on the simple mesh I posted several posts before, the mesh had some errors and simulation gave wrong results - so I've to abandon meshes generated by VMTK (will try gambit one though).
If there is an option to perform a simulation basing on the STL file, it could save me. However, the problem begins with the labels of the patches: in order to perform a simulation, there have to be defined boundary names, like inletPatch, outletPatch, someOtherName, etc. In such a complicated geometry, those surfaces are randomly oriented (they have different locations in 'space' and they aren't usually coplanar in the global coordinate frame) and defining them in the blockMeshDict file is rather impossible. To be honest, I have 0 experience with snappyHexMesh and I don't know whether such a complicated issue as defining those patches is even possible. In tutorial cases, everything is practically done - all files are created (so all the vertices, edges, blocks, etc. are defined) so it doesn't help me to understand how to get things done from scratch. And usually all cases I found have patches faced in particular direction (x, y or z), so they are easily defineable. Zibi |
|
October 16, 2017, 08:09 |
|
#20 |
Member
Ashish Magar
Join Date: Jul 2016
Location: Mumbai, India
Posts: 81
Rep Power: 10 |
Hello Zibi,
Looking at your output at final iteration, it sees that your solution is not converged. Code:
Time = 2 smoothSolver: Solving for Ux, Initial residual = 0.0309148, Final residual = 0.00308236, No Iterations 1 smoothSolver: Solving for Uy, Initial residual = 0.0314383, Final residual = 0.000396976, No Iterations 2 smoothSolver: Solving for Uz, Initial residual = 0.0168423, Final residual = 0.000215721, No Iterations 2 GAMG: Solving for p, Initial residual = 0.128034, Final residual = 0.00434386, No Iterations 2 time step continuity errors : sum local = 0.0641924, global = -0.000195599, cumulative = -0.316464 ExecutionTime = 522.224 s ClockTime = 522 End Mesh seems fine, according to orthogonality.. add a few nonOrthogonalCorrectors if you want to use the same mesh. Cheers. |
|
Tags |
boundary condition, simplefoam |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
parallel get wrong results for parallel_computation.py inv_ONERAM6.cfg | nuaa_bird | SU2 | 3 | June 15, 2017 09:55 |
simpleFoam turbulent flow laminar results | NicolasB | OpenFOAM Running, Solving & CFD | 22 | March 25, 2016 13:31 |
Fluent results in wrong coordinates after imported to Tecplot | soriyoshi | FLUENT | 0 | October 11, 2014 07:57 |
Wrong results after Modifying yPlus.C & OP 1.6-ext | sasanghomi | OpenFOAM | 5 | September 22, 2013 15:11 |
Wrong results from motorByke tutorial in OpenFoam 2.1.1 | jsc | OpenFOAM Running, Solving & CFD | 3 | April 16, 2013 08:26 |