Select Git revision
Search by author
- Any Author
- authors
-
Andrew Heather andy
-
Gabriel Barajas
barjasg
-
Johan Roenby johan_roenby
-
Kutalmış Berçin
kuti
-
Mark OLESEN
mark
-
Matej Forman matej
-
Mattijs Janssens Mattijs
-
Pawan Ghildiyal Pawan
-
Prashant Sonakar Prashant
-
Vaggelis Papoutsis vaggelisp
- Sep 22, 2017
-
-
Patch contributed by Alberto Passalacqua, Iowa State University
-
Provides the additional compression necessary to ensure interface integrity adjacent to a boundary at a low angle of incidence to the interface. This is particularly important when simulating planing hulls.
-
swirlFlowRateInletVelocityFvPatchVectorField: Avoid calculating origin and axis for patches with no faces Resolves problem with reconstructPar
-
Improved stability and convergence.
-
-
flowRateOutletVelocityFvPatchVectorField: Outlet equivalent of flowRateOutletVelocityFvPatchVectorField BC Velocity outlet boundary condition which corrects the extrapolated velocity to match the specified flow rate.
-
Resolves bug-report https://bugs.openfoam.org/view.php?id=2574
-
Resolves bug-report https://bugs.openfoam.org/view.php?id=2556
-
Velocity outlet boundary condition which corrects the extrapolated velocity to match the flow rate of the specified corresponding inlet patch.
-
-
Andrew Heather authored
-
which support the specification of the individual velocity components (axial, radial and tangential) as Function1s.
-
Andrew Heather authored
-
Updated the tetrahedron and triangle classes to use the barycentric primitives. Removed duplicate code for generating random positions in tets and tris, and fixed bug in tri random position.
-
This tutorial demonstrates moving mesh and AMI with a Lagrangian cloud. It is very slow, as interaction lists (required to compute collisions) are not optimised for moving meshes. The simulation time has therefore been made very short, so that it finishes in a reasonable time. The mixer only completes a small fraction of a rotation in this time. This is still sufficient to test tracking and collisions in the presence of AMI and mesh motion. In order to generate a convincing animation, however, the end time must be increased and the simulation run for a number of days.
-
and the continuous-phase simulation type For LTS and steady-state simulations the transient option does not need to be provided as only steady-state tracking is appropriate. For transient running the Lagrangian tracking may be steady or transient.
-
The evolution of a KinematicParcel happens in three stages; (1) tracking across the cell, (2) interaction with the face or patch that has been hit, and (3) clculation and and update of parcel and cell properties. The KinematicParcel used to evolve in this order, as steps 1 and 2 were part of the same lower level method. This meant that the update stage was done after interacting with the face, meaning the parcel was not in the cell that had just been tracked through, or, by means of a patch interaction, had been modified such that it was no longer representative of the track through the cell. With the separation of stages 1 and 2 in the base class, it is now possible to do the update stage before interacting with the face (i.e., proceeding in the order 1, 3, 2). This makes the state consistent for the updates, and avoids the issues described. Patch contributed by Timo Niemi, VTT. This resolves bug report https://bugs.openfoam.org/view.php?id=2282
-
-
-
Particle collisions with ACMI patches are now handled. The hit detects whether the location is within the overlap or the coupled region and recurses, calling the hit routine appropriate for the region. The low level tracking methods are now more consistently named. There is now a distinction between tracking to a face and hitting it. Function object side effects have been moved out of the base layer and into the parcels on which they are meaningful.
-
Patch contributed by Timo Niemi, VTT. Resolves bug-report https://bugs.openfoam.org/view.php?id=2655
-
The TrackData::switchProcessor flag was not being set for some of the tracking steps made by the more complicated parcels. In the case that a parcel starts the step already on a processor boundary, this sometimes lead to the particle being transferred back and forth indefinitely. The flag is now explicitly set in all cases.
-
Resolves bug report https://bugs.openfoam.org/view.php?id=2643
-
Tracking through an inverted region of the mesh happens in a reversed direction relative to a non-inverted region. Usually, this allows the tracking to propagate normally, regardless of the sign of the space. However, in rare cases, it is possible for a straight trajectory to form a closed loop through both positive and negative regions. This causes the tracking to loop indefinitely. To fix this, the displacement through inverted regions has been artifically increased by a small amount (1% at the moment). This has the effect that the change in track fraction over the negative part of the loop no longer exactly cancels the change over the positive part, and the track therefore terminates.
-
The KinematicCloud::patchData method has been made consistent on moving meshes and/or when the time-step is being sub-cycled. It has also been altered to calculate the normal component of a moving patch's velocity directly from the point motions. This prevents an infinite loop occuring due to inconsistency between the velocity used to calculate a rebound and that used when tracking. Some minor style improvements to the particle class have also been made.
-
The particle collector was collecting some particles twice due to a tolerance extending the tracked path. This has been removed. The new tracking algorithm does not generate the same sorts of spurious tolerance-scale motions that the old one did, so this extension of the tracking path is unnecessary. Some particles were also not being collected at all as they were hitting a diagonal of the collection polygon and registering as not having hit either of the adjacent triangles. The hit criteria has been rewritten. A hit now occurs when the normals of the triangles created by joining the intersection point with the polygon edges are all in the same direction as the overall polygon normal. This calculation is not affected by the polygon's diagonals. The issue was raised by, and resolved with support from, Karl Meredith at FM Global. This resolves bug-report https://bugs.openfoam.org/view.php?id=2595
-
This change changes the point-tetIndices-face interpolation function method to take barycentric-tetIndices-face arguments instead. This function is, at present, only used for interpolating Eulerian data to Lagrangian particles. This change prevents an inefficiency in cellPointInterpolation whereby the position of the particle is calculated from it's barycentric coordinates, before immediately being converted back to barycentric coordinates to perform the interpolation.
-
The averaging methods now take the particle barycentric coordinates as inputs rather than global positions. This change significantly optimises Dual averaging, which is the most commonly used method. The run time of the lagrangian/MPPICFoam/Goldschmidt tutorial has been reduced by a factor of about two.
-
The logic for generating tetrahedra from a face base point and an offset was duplicated in a few places. It is now confined to the tetIndices class.
-
-
-
now possible with level-sets as well as planes. Removed tetPoints class as this wasn't really used anywhere except for the old tet-cutting routines. Restored tetPointRef.H to be consistent with other primitive shapes. Re-wrote tet-overlap mapping in terms of the new cutting.
-
AMI. Applied the transformation.
-
This was broken when the minimum-step-fraction tolerance was removed.
-
-
terms of the local barycentric coordinates of the current tetrahedron, rather than the global coordinate system. Barycentric tracking works on any mesh, irrespective of mesh quality. Particles do not get "lost", and tracking does not require ad-hoc "corrections" or "rescues" to function robustly, because the calculation of particle-face intersections is unambiguous and reproducible, even at small angles of incidence. Each particle position is defined by topology (i.e. the decomposed tet cell it is in) and geometry (i.e. where it is in the cell). No search operations are needed on restart or reconstruct, unlike when particle positions are stored in the global coordinate system. The particle positions file now contains particles' local coordinates and topology, rather than the global coordinates and cell. This change to the output format is not backwards compatible. Existing cases with Lagrangian data will not restart, but they will still run from time zero without any modification. This change was necessary in order to guarantee that the loaded particle is valid, and therefore fundamentally prevent "loss" and "search-failure" type bugs (e.g., 2517, 2442, 2286, 1836, 1461, 1341, 1097). The tracking functions have also been converted to function in terms of displacement, rather than end position. This helps remove floating point error issues, particularly towards the end of a tracking step. Wall bounded streamlines have been removed. The implementation proved incompatible with the new tracking algorithm. ParaView has a surface LIC plugin which provides equivalent, or better, functionality. Additionally, bug report <https://bugs.openfoam.org/view.php?id=2517> is resolved by this change.
-
- Sep 21, 2017
- Sep 18, 2017
