- Nov 22, 2017
-
-
Mark OLESEN authored
- in most cases already checked valid() so don't need additional check for setting an existing pointer
-
- Apr 28, 2016
-
-
Henry Weller authored
When the GeometricBoundaryField template class was originally written it was a separate class in the Foam namespace rather than a sub-class of GeometricField as it is now. Without loss of clarity and simplifying code which access the boundary field of GeometricFields it is better that GeometricBoundaryField be renamed Boundary for consistency with the new naming convention for the type of the dimensioned internal field: Internal, see commit a25a449c This is a very simple text substitution change which can be applied to any code which compiles with the OpenFOAM-dev libraries.
-
- Apr 25, 2016
-
-
Henry Weller authored
Resolves bug-report http://www.openfoam.org/mantisbt/view.php?id=1938 Because C++ does not support overloading based on the return-type there is a problem defining both const and non-const member functions which are resolved based on the const-ness of the object for which they are called rather than the intent of the programmer declared via the const-ness of the returned type. The issue for the "boundaryField()" member function is that the non-const version increments the event-counter and checks the state of the stored old-time fields in case the returned value is altered whereas the const version has no side-effects and simply returns the reference. If the the non-const function is called within the patch-loop the event-counter may overflow. To resolve this it in necessary to avoid calling the non-const form of "boundaryField()" if the results is not altered and cache the reference outside the patch-loop when mutation of the patch fields is needed. The most straight forward way of resolving this problem is to name the const and non-const forms of the member functions differently e.g. the non-const form could be named: mutableBoundaryField() mutBoundaryField() nonConstBoundaryField() boundaryFieldRef() Given that in C++ a reference is non-const unless specified as const: "T&" vs "const T&" the logical convention would be boundaryFieldRef() boundaryFieldConstRef() and given that the const form which is more commonly used is it could simply be named "boundaryField()" then the logical convention is GeometricBoundaryField& boundaryFieldRef(); inline const GeometricBoundaryField& boundaryField() const; This is also consistent with the new "tmp" class for which non-const access to the stored object is obtained using the ".ref()" member function. This new convention for non-const access to the components of GeometricField will be applied to "dimensionedInternalField()" and "internalField()" in the future, i.e. "dimensionedInternalFieldRef()" and "internalFieldRef()".
-
- Apr 24, 2016
-
-
Henry Weller authored
-
- Mar 22, 2016
-
-
Henry Weller authored
-
- Feb 26, 2016
-
-
Henry Weller authored
The deprecated non-const tmp functionality is now on the compiler switch NON_CONST_TMP which can be enabled by adding -DNON_CONST_TMP to EXE_INC in the Make/options file. However, it is recommended to upgrade all code to the new safer tmp by using the '.ref()' member function rather than the non-const '()' dereference operator when non-const access to the temporary object is required. Please report any problems on Mantis. Henry G. Weller CFD Direct.
-
- Jan 10, 2016
-
-
Henry Weller authored
-
- Apr 27, 2015
-
-
Henry authored
This formulation provides C-grid like pressure-flux staggering on an unstructured mesh which is hugely beneficial for Euler-Euler multiphase equations as it allows for all forces to be treated in a consistent manner on the cell-faces which provides better balance, stability and accuracy. However, to achieve face-force consistency the momentum transport terms must be interpolated to the faces reducing accuracy of this part of the system but this is offset by the increase in accuracy of the force-balance. Currently it is not clear if this face-based momentum equation formulation is preferable for all Euler-Euler simulations so I have included it on a switch to allow evaluation and comparison with the previous cell-based formulation. To try the new algorithm simply switch it on, e.g.: PIMPLE { nOuterCorrectors 3; nCorrectors 1; nNonOrthogonalCorrectors 0; faceMomentum yes; } It is proving particularly good for bubbly flows, eliminating the staggering patterns often seen in the air velocity field with the previous algorithm, removing other spurious numerical artifacts in the velocity fields and improving stability and allowing larger time-steps For particle-gas flows the advantage is noticeable but not nearly as pronounced as in the bubbly flow cases. Please test the new algorithm on your cases and provide feedback. Henry G. Weller CFD Direct
-
- Apr 12, 2015
-
-
Henry authored
Updated tutorials to converge pressure during PIMPLE loop to avoid phase-fraction unboundedness which limits thermodynamics convergence.
-
- Apr 08, 2015
-
-
Henry authored
-
Henry authored
Reduces or eliminates staggering patterns due to cell-force imbalances Resolves bug-report http://www.openfoam.org/mantisbt/view.php?id=1363
-
- Dec 10, 2014
-
-
Henry authored
-