- 30 Oct, 2015 1 commit
-
-
Henry Weller authored
Reported in http://www.openfoam.org/mantisbt/view.php?id=1856
-
- 21 Jan, 2015 1 commit
-
-
Henry authored
The old separate incompressible and compressible libraries have been removed. Most of the commonly used RANS and LES models have been upgraded to the new framework but there are a few missing which will be added over the next few days, in particular the realizable k-epsilon model. Some of the less common incompressible RANS models have been introduced into the new library instantiated for incompressible flow only. If they prove to be generally useful they can be templated for compressible and multiphase application. The Spalart-Allmaras DDES and IDDES models have been thoroughly debugged, removing serious errors concerning the use of S rather than Omega. The compressible instances of the models have been augmented by a simple backward-compatible eddyDiffusivity model for thermal transport based on alphat and alphaEff. This will be replaced with a separate run-time selectable thermal transport model framework in a few weeks. For simplicity and ease of maintenance and further development the turbulent transport and wall modeling is based on nut/nuEff rather than mut/muEff for compressible models so that all forms of turbulence models can use the same wall-functions and other BCs. All turbulence model selection made in the constant/turbulenceProperties dictionary with RAS and LES as sub-dictionaries rather than in separate files which added huge complexity for multiphase. All tutorials have been updated so study the changes and update your own cases by comparison with similar cases provided. Sorry for the inconvenience in the break in backward-compatibility but this update to the turbulence modeling is an essential step in the future of OpenFOAM to allow more models to be added and maintained for a wider range of cases and physics. Over the next weeks and months more turbulence models will be added of single and multiphase flow, more additional sub-models and further development and testing of existing models. I hope this brings benefits to all OpenFOAM users. Henry G. Weller
-
- 12 Jan, 2015 2 commits
- 12 Mar, 2013 1 commit
-
-
andy authored
-
- 26 Sep, 2012 1 commit
-
-
andy authored
-
- 14 Aug, 2011 1 commit
-
-
Henry authored
-
- 19 Jan, 2011 1 commit
-
- 07 Jan, 2011 1 commit
-
-
graham authored
-
- 05 Jan, 2011 2 commits
-
-
Andrew Heather authored
This reverts commit b18f6cc1.
-
graham authored
-
- 28 Jul, 2010 1 commit
-
-
graham authored
-
- 29 Mar, 2010 1 commit
-
-
Mark Olesen authored
-
- 14 Jan, 2010 1 commit
-
-
mattijs authored
-
- 29 Nov, 2009 1 commit
-
-
Mark Olesen authored
- the blockMesh interface is splineEdge.H, selectable as "spline" The first tests look fine - it works as expected for the case with buggy polySpline reported on the forum. Should of course do some more extensive testing. The advantages compared to the current B-Spline implementation: - Doesn't need a matrix solver. - The coding resembles something that can be found in the literature. - In contrast to the B-Spline implementation, it is fairly clear what is actually going on. I don't even know if the B-Spline are actually B-Spline, Beta-Splines or something else. - Catmull-Rom splines seem to be what all the graphics people have as their stable workhorse. We now have 3 different names for splines in blockMesh: - "spline" - *new* Catmull-Rom for arbitrary segments. - "simpleSpline" - B-Spline for a single segment - "polySpline" - B-Spline for a multiple segments Assuming the Catmull-Rom splines continue to behave nicely, there is no reason to keep the other (broken) B-Splines. This would help clean up the blockMesh interface too. Placed the older ones under legacy/ for easier identification in the future. TODO: - currently no handling of non-zero end tangents - could be extended to handle closed loops, which might be useful for feature edges from CAD (eg, for the cvm mesher)
-
- 23 Nov, 2009 1 commit
-
-
Mark Olesen authored
- slightly better code isolation, dropped unneed variables, changed vector -> point in the appropriate places - the spline stuff is still horribly broken. Needs a complete rewrite or needs to get chucked.
-
- 07 Oct, 2009 1 commit
-
-
Mark Olesen authored
- also sifted through code to find out why polySplineEdge is going wrong It doesn't seem to be a virtual/non-virtual issue, but appears to be an issue with how BSpline is solving for the new points.
-
- 21 Sep, 2009 1 commit
-
-
Mark Olesen authored
-
- 17 Sep, 2009 1 commit
-
-
Mark Olesen authored
- Unless the points(), cells(), patches() methods are called, the classes should know maintain a lightweight representation for as long as possible. - bugfix: old-code used xferMove() instead of xferCopy() when creating the topology mesh - causing const pointField& to break if the code order was changed - relocate blockMesh from src/meshing -> src/mesh
-
- 16 Sep, 2009 2 commits
-
-
Mark Olesen authored
-
Mark Olesen authored
-
- 31 Dec, 2008 1 commit
-
-
Mark Olesen authored
-
- 25 Jun, 2008 2 commits
-
-
Mark Olesen authored
-
Mark Olesen authored
-
- 15 Apr, 2008 1 commit
-
-
OpenFOAM-admin authored
-