1. 31 Oct, 2019 1 commit
  2. 16 Aug, 2019 1 commit
    • sergio's avatar
      ENH: Add components to allow overset with multiple motion solvers · d96ad1cd
      sergio authored
      1) Add softWall rigidBody restrain
      2) Add linearSpringDamper sixDoF restrain to work as soft rope
      3) dynamicMotionSolverListFvMesh changed to dictionary based input
      4) Add Time reference access to sixDof restraints
      5) Add drivenLinearMotion to solidBodyMotionFunctions.
  3. 05 Jul, 2019 1 commit
  4. 06 Feb, 2019 1 commit
  5. 01 Oct, 2018 1 commit
    • Mark Olesen's avatar
      ENH: improve, simplify, rationalize coordinate system handling (issue #863) · 6697bb47
      Mark Olesen authored
      Previously the coordinate system functionality was split between
      coordinateSystem and coordinateRotation. The coordinateRotation stored
      the rotation tensor and handled all tensor transformations.
      The functionality has now been revised and consolidated into the
      coordinateSystem classes. The sole purpose of coordinateRotation
      is now just to provide a selectable mechanism of how to define the
      rotation tensor (eg, axis-angle, euler angles, local axes) for user
      input, but after providing the appropriate rotation tensor it has
      no further influence on the transformations.
      The coordinateSystem class now contains an origin and a base rotation
      tensor directly and various transformation methods.
        - The origin represents the "shift" for a local coordinate system.
        - The base rotation tensor represents the "tilt" or orientation
          of the local coordinate system in general (eg, for mapping
          positions), but may require position-dependent tensors when
          transforming vectors and tensors.
      For some coordinate systems (currently the cylindrical coordinate system),
      the rotation tensor required for rotating a vector or tensor is
      The new coordinateSystem and its derivates (cartesian, cylindrical,
      indirect) now provide a uniform() method to define if the rotation
      tensor is position dependent/independent.
      The coordinateSystem transform and invTransform methods are now
      available in two-parameter forms for obtaining position-dependent
      rotation tensors. Eg,
            ... = cs.transform(globalPt, someVector);
      In some cases it can be useful to use query uniform() to avoid
      storage of redundant values.
            if (cs.uniform())
                vector xx = cs.transform(someVector);
                List<vector> xx = cs.transform(manyPoints, someVector);
      Support transform/invTransform for common data types:
         (scalar, vector, sphericalTensor, symmTensor, tensor).
        Breaking Changes
      - These changes to coordinate systems and rotations may represent
        a breaking change for existing user coding.
      - Relocating the rotation tensor into coordinateSystem itself means
        that the coordinate system 'R()' method now returns the rotation
        directly instead of the coordinateRotation. The method name 'R()'
        was chosen for consistency with other low-level entities (eg,
        The following changes will be needed in coding:
            Old:  tensor rot = cs.R().R();
            New:  tensor rot = cs.R();
            Old:  cs.R().transform(...);
            New:  cs.transform(...);
        Accessing the runTime selectable coordinateRotation
        has moved to the rotation() method:
            Old:  Info<< "Rotation input: " << cs.R() << nl;
            New:  Info<< "Rotation input: " << cs.rotation() << nl;
      - Naming consistency changes may also cause code to break.
            Old:  transformVector()
            New:  transformPrincipal()
        The old method name transformTensor() now simply becomes transform().
        New methods
      For operations requiring caching of the coordinate rotations, the
      'R()' method can be used with multiple input points:
             tensorField rots(cs.R(somePoints));
         and later
             Foam::transformList(rots, someVectors);
      The rotation() method can also be used to change the rotation tensor
      via a new coordinateRotation definition (issue #879).
      The new methods transformPoint/invTransformPoint provide
      transformations with an origin offset using Cartesian for both local
      and global points. These can be used to determine the local position
      based on the origin/rotation without interpreting it as a r-theta-z
      value, for example.
        Input format
      - Streamline dictionary input requirements
        * The default type is cartesian.
        * The default rotation type is the commonly used axes rotation
          specification (with e1/e2/3), which is assumed if the 'rotation'
          sub-dictionary does not exist.
          Compact specification:
                  origin  (0 0 0);
                  e2      (0 1 0);
                  e3      (0.5 0 0.866025);
          Full specification (also accepts the longer 'coordinateRotation'
          sub-dictionary name):
                  type    cartesian;
                  origin  (0 0 0);
                      type    axes;
                      e2      (0 1 0);
                      e3      (0.5 0 0.866025);
         This simplifies the input for many cases.
      - Additional rotation specification 'none' (an identity rotation):
                origin  (0 0 0);
                rotation { type none; }
      - Additional rotation specification 'axisAngle', which is similar
        to the -rotate-angle option for transforming points (issue #660).
        For some cases this can be more intuitive.
        For example,
                type    axisAngle;
                axis    (0 1 0);
                angle   30;
                type    axes;
                e2      (0 1 0);
                e3      (0.5 0 0.866025);
      - shorter names (or older longer names) for the coordinate rotation
           euler         EulerRotation
           starcd        STARCDRotation
           axes          axesRotation
        Coding Style
      - use Foam::coordSystem namespace for categories of coordinate systems
        (cartesian, cylindrical, indirect). This reduces potential name
        clashes and makes a clearer declaration. Eg,
            coordSystem::cartesian csys_;
        The older names (eg, cartesianCS, etc) remain available via typedefs.
      - added coordinateRotations namespace for better organization and
        reduce potential name clashes.
  6. 05 Mar, 2018 1 commit
  7. 11 Jun, 2018 1 commit
  8. 07 Jul, 2017 1 commit
    • Andrew Heather's avatar
      INT: Integration of Mattijs' collocated parallel IO additions · d8d6030a
      Andrew Heather authored
      Original commit message:
      Parallel IO: New collated file format
      When an OpenFOAM simulation runs in parallel, the data for decomposed fields and
      mesh(es) has historically been stored in multiple files within separate
      directories for each processor.  Processor directories are named 'processorN',
      where N is the processor number.
      This commit introduces an alternative "collated" file format where the data for
      each decomposed field (and mesh) is collated into a single file, which is
      written and read on the master processor.  The files are stored in a single
      directory named 'processors'.
      The new format produces significantly fewer files - one per field, instead of N
      per field.  For large parallel cases, this avoids the restriction on the number
      of open files imposed by the operating system limits.
      The file writing can be threaded allowing the simulation to continue running
      while the data is being written to file.  NFS (Network File System) is not
      needed when using the the collated format and additionally, there is an option
      to run without NFS with the original uncollated approach, known as
      The controls for the file handling are in the OptimisationSwitches of
          //- Parallel IO file handler
          //  uncollated (default), collated or masterUncollated
          fileHandler uncollated;
          //- collated: thread buffer size for queued file writes.
          //  If set to 0 or not sufficient for the file size threading is not used.
          //  Default: 2e9
          maxThreadFileBufferSize 2e9;
          //- masterUncollated: non-blocking buffer size.
          //  If the file exceeds this buffer size scheduled transfer is used.
          //  Default: 2e9
          maxMasterFileBufferSize 2e9;
      When using the collated file handling, memory is allocated for the data in the
      thread.  maxThreadFileBufferSize sets the maximum size of memory in bytes that
      is allocated.  If the data exceeds this size, the write does not use threading.
      When using the masterUncollated file handling, non-blocking MPI communication
      requires a sufficiently large memory buffer on the master node.
      maxMasterFileBufferSize sets the maximum size in bytes of the buffer.  If the
      data exceeds this size, the system uses scheduled communication.
      The installation defaults for the fileHandler choice, maxThreadFileBufferSize
      and maxMasterFileBufferSize (set in etc/controlDict) can be over-ridden within
      the case controlDict file, like other parameters.  Additionally the fileHandler
      can be set by:
      - the "-fileHandler" command line argument;
      - a FOAM_FILEHANDLER environment variable.
      A foamFormatConvert utility allows users to convert files between the collated
      and uncollated formats, e.g.
          mpirun -np 2 foamFormatConvert -parallel -fileHandler uncollated
      An example case demonstrating the file handling methods is provided in:
      The work was undertaken by Mattijs Janssens, in collaboration with Henry Weller.
  9. 01 Dec, 2016 1 commit
    • Henry Weller's avatar
      dynamicMotionSolverListFvMesh: New mesh-motion solver supporting multiple moving regions · 1c687baa
      Henry Weller authored
      e.g. the motion of two counter-rotating AMI regions could be defined:
      dynamicFvMesh   dynamicMotionSolverListFvMesh;
              solver solidBody;
              cellZone        rotor1;
              solidBodyMotionFunction  rotatingMotion;
                  origin        (0 0 0);
                  axis          (0 0 1);
                  omega         6.2832; // rad/s
              solver solidBody;
              cellZone        rotor2;
              solidBodyMotionFunction  rotatingMotion;
                  origin        (0 0 0);
                  axis          (0 0 1);
                  omega         -6.2832; // rad/s
      Any combination of motion solvers may be selected but there is no special
      handling of motion interaction; the motions are applied sequentially and
      potentially cumulatively.
      To support this new general framework the solidBodyMotionFvMesh and
      multiSolidBodyMotionFvMesh dynamicFvMeshes have been converted into the
      corresponding motionSolvers solidBody and multiSolidBody and the tutorials
      updated to reflect this change e.g. the motion in the mixerVesselAMI2D tutorial
      is now defined thus:
      dynamicFvMesh   dynamicMotionSolverFvMesh;
      solver solidBody;
          cellZone        rotor;
          solidBodyMotionFunction  rotatingMotion;
              origin        (0 0 0);
              axis          (0 0 1);
              omega         6.2832; // rad/s
  10. 18 May, 2016 1 commit
  11. 25 Jan, 2016 1 commit
    • mattijs's avatar
      ENH: glboal file handling: initial commit · e4240592
      mattijs authored
      Moved file path handling to regIOobject and made it type specific so
      now every object can have its own rules. Examples:
      - faceZones are now processor local (and don't search up anymore)
      - timeStampMaster is now no longer hardcoded inside IOdictionary
        (e.g. uniformDimensionedFields support it as well)
      - the distributedTriSurfaceMesh is properly processor-local; no need
        for fileModificationChecking manipulation.
  12. 08 Dec, 2015 1 commit
  13. 11 Nov, 2015 1 commit
  14. 13 Oct, 2015 2 commits
  15. 03 Jun, 2014 1 commit
  16. 31 Aug, 2012 1 commit
  17. 14 Aug, 2011 1 commit
  18. 19 Jan, 2011 1 commit
  19. 14 Jan, 2011 1 commit
  20. 07 Jan, 2011 1 commit
  21. 05 Jan, 2011 2 commits
  22. 28 Jul, 2010 1 commit
  23. 29 Mar, 2010 1 commit
  24. 08 Feb, 2010 1 commit
  25. 23 Mar, 2009 2 commits
  26. 20 Mar, 2009 1 commit
    • mattijs's avatar
      common base for displacement solvers · ee3d5243
      mattijs authored
      	modified:   fvMotionSolver/Make/files
      	modified:   fvMotionSolver/fvMotionSolvers/displacement/SBRStress/displacementSBRStressFvMotionSolver.C
      	modified:   fvMotionSolver/fvMotionSolvers/displacement/SBRStress/displacementSBRStressFvMotionSolver.H
      	new file:   fvMotionSolver/fvMotionSolvers/displacement/displacementFvMotionSolver/displacementFvMotionSolver.C
      	new file:   fvMotionSolver/fvMotionSolvers/displacement/displacementFvMotionSolver/displacementFvMotionSolver.H
      	modified:   fvMotionSolver/fvMotionSolvers/displacement/interpolation/displacementInterpolationFvMotionSolver.C
      	modified:   fvMotionSolver/fvMotionSolvers/displacement/interpolation/displacementInterpolationFvMotionSolver.H
      	modified:   fvMotionSolver/fvMotionSolvers/displacement/laplacian/displacementLaplacianFvMotionSolver.C
      	modified:   fvMotionSolver/fvMotionSolvers/displacement/laplacian/displacementLaplacianFvMotionSolver.H
      	modified:   fvMotionSolver/pointPatchFields/derived/surfaceSlipDisplacement/surfaceSlipDisplacementPointPatchVectorField.C