1. 12 Dec, 2019 1 commit
  2. 13 Dec, 2019 10 commits
  3. 12 Dec, 2019 16 commits
    • Andrew Heather's avatar
      Merge branch 'feature-adjoint-shapeOptimisation' into 'develop' · 042c529f
      Andrew Heather authored
      ENH: New adjont shape optimisation functionality
      
      See merge request !307
      042c529f
    • Vaggelis Papoutsis's avatar
      ENH: New adjont shape optimisation functionality · b8632543
      Vaggelis Papoutsis authored
      The adjoint library is enhanced with new functionality enabling
      automated shape optimisation loops.  A parameterisation scheme based on
      volumetric B-Splines is introduced, the control points of which act as
      the design variables in the optimisation loop [1, 2].  The control
      points of the volumetric B-Splines boxes can be defined in either
      Cartesian or cylindrical coordinates.
      
      The entire loop (solution of the flow and adjoint equations, computation
      of sensitivity derivatives, update of the design variables and mesh) is
      run within adjointOptimisationFoam. A number of methods to update the
      design variables are implemented, including popular Quasi-Newton methods
      like BFGS and methods capable of handling constraints like loop using
      the SQP or constraint projection.
      
      The software was developed by PCOpt/NTUA and FOSS GP, with contributions from
      
      Dr. Evangelos Papoutsis-Kiachagias,
      Konstantinos Gkaragounis,
      Professor Kyriakos Giannakoglou,
      Andy Heather
      
      [1] E.M. Papoutsis-Kiachagias, N. Magoulas, J. Mueller, C. Othmer,
      K.C.  Giannakoglou: 'Noise Reduction in Car Aerodynamics using a
      Surrogate Objective Function and the Continuous  Adjoint Method with
      Wall Functions', Computers & Fluids, 122:223-232, 2015
      
      [2] E. M. Papoutsis-Kiachagias, V. G. Asouti, K. C. Giannakoglou,
      K.  Gkagkas, S. Shimokawa, E. Itakura: ‘Multi-point aerodynamic shape
      optimization of cars based on continuous adjoint’, Structural and
      Multidisciplinary Optimization, 59(2):675–694, 2019
      b8632543
    • Mark Olesen's avatar
      CONFIG: prefer use of ParaView_MESA_DIR in runTimePostProcessing · a8ab9b87
      Mark Olesen authored
      - when using VTK from ParaView sources it can better to tag them as
        such, but simultaneously not mask the ParaView with hardware
        rendering.
      
        The additional ParaView_MESA_DIR variable allows this.
        The balance of library and path setup is unaffected by this.
      
      DOC: update doc/BuildIssues
      a8ab9b87
    • Mark Olesen's avatar
      STYLE: typo in doc · 455c619e
      Mark Olesen authored
      455c619e
    • Andrew Heather's avatar
      ff995c5d
    • Andrew Heather's avatar
      Merge branch 'misc-kbc' into 'develop' · 58b02969
      Andrew Heather authored
      ENH|BUG: Misc
      
      See merge request !305
      58b02969
    • Kutalmis Bercin's avatar
      BUG: fix kkLOmega model - omegaWallFunction inconsistency (#1484) · 82257333
      Kutalmis Bercin authored
        - `Pkt` was directed to `GName` to allow wall functions
           are usable by kkLOmega model
        - `Pkt` was changed to a non-const object, so that omegaWallFunc
          can modify `Pkt` at the wall, if need be.
        - Elementwise backward compatibility was checked by
          pimpleFoam/RAS/ellipsekkLOmega
        - New implementation was checked by changing omega:hole boundary
          in pimpleFoam/RAS/ellipsekkLOmega to omegaWallFunction
      82257333
    • Kutalmis Bercin's avatar
      BUG: fix QRMatrix (#1261, #1240) · af0e454c
      Kutalmis Bercin authored
          QRMatrix (i.e. QR decomposition, QR factorisation or orthogonal-triangular
          decomposition) decomposes a scalar/complex matrix \c A into the following
          matrix product:
      
          \verbatim
              A = Q*R,
          \endverbatim
      
          where
           \c Q is a unitary similarity matrix,
           \c R is an upper triangular matrix.
      
      Usage
          Input types:
           - \c A can be a \c SquareMatrix<Type> or \c RectangularMatrix<Type>
      
          Output types:
           - \c Q is always of the type of the matrix \c A
           - \c R is always of the type of the matrix \c A
      
          Options for the output forms of \c QRMatrix (for an (m-by-n) input matrix
          \c A with k = min(m, n)):
           - outputTypes::FULL_R:     computes only \c R                   (m-by-n)
           - outputTypes::FULL_QR:    computes both \c R and \c Q          (m-by-m)
           - outputTypes::REDUCED_R:  computes only reduced \c R           (k-by-n)
      
          Options where to store \c R:
           - storeMethods::IN_PLACE:        replaces input matrix content with \c R
           - storeMethods::OUT_OF_PLACE:    creates new object of \c R
      
          Options for the computation of column pivoting:
           - colPivoting::FALSE:            switches off column pivoting
           - colPivoting::TRUE:             switches on column pivoting
      
          Direct solution of linear systems A x = b is possible by solve() alongside
          the following limitations:
           - \c A         = a scalar square matrix
           - output type  = outputTypes::FULL_QR
           - store method = storeMethods::IN_PLACE
      
      Notes
          - QR decomposition is not unique if \c R is not positive diagonal \c R.
          - The option combination:
            - outputTypes::REDUCED_R
            - storeMethods::IN_PLACE
            will not modify the rows of input matrix \c A after its nth row.
          - Both FULL_R and REDUCED_R QR decompositions execute the same number of
            operations. Yet REDUCED_R QR decomposition returns only the first n rows
            of \c R if m > n for an input m-by-n matrix \c A.
          - For m <= n, FULL_R and REDUCED_R will produce the same matrices
      af0e454c
    • Kutalmis Bercin's avatar
    • Kutalmis Bercin's avatar
    • Kutalmis Bercin's avatar
      ENH: add new funcs into `SquareMatrix` · 64614cfc
      Kutalmis Bercin authored
          - query func `symmetric()`
          - query func `tridiagonal()`
          - `resize()`
          - `labelpair` identity constructor
      
          STYLE: add `#if(0 | RUNALL)` to improve test control in Test-Matrix
      64614cfc
    • Kutalmis Bercin's avatar
      f9e53921
    • Kutalmis Bercin's avatar
    • Kutalmis Bercin's avatar
      DOC: add missing tags into Stokes.H (#1509) · be235787
      Kutalmis Bercin authored
        STYLE: add missing comment dashes, DOI
        DOC: add DOI into WatersKing.C
      be235787
    • Mark Olesen's avatar
      Merge branch 'feature-mesh-update-controls' into 'develop' · 55c880b7
      Mark Olesen authored
      Feature mesh update controls
      
      See merge request !306
      55c880b7
    • Mark Olesen's avatar
      ENH: update handling of "writeTime" in timeControl class · 280be631
      Mark Olesen authored
      - handle zero or negative values as being identical to 1.
        As per timeStep control and what the comments suggested.
      
      - drop old outputTime enumeration, since this is covered by the
        writeTime enumeration and a corresponding Enum name.
      
      - support construction of a "pass-through" control object that always
        executes and add some method to test for these conditions and be able
        to output some meaning full information.
        Eg,
      
           if (ctrl.execute())
           {
               if (!ctrl.always())
               {
                   Info<< "Sampling executed based on " << ctrl.type() << nl;
               }
               ...
           }
      
           To produce "Sampling executed based on runTime"
      280be631
  4. 11 Dec, 2019 10 commits
  5. 10 Dec, 2019 3 commits
    • Mark Olesen's avatar
      0c5ff2ef
    • Mark Olesen's avatar
      Merge branch 'feature-particle-patch-postpro-filtering' into 'develop' · 71bc3510
      Mark Olesen authored
      Feature particle patch postpro filtering
      
      ### Summary
      
      Adds options to write particle-patch interactions to file, and to select particle fields to post-process for the `patchPostProcessing` cloud function object
      
      
      ### Resolved bugs (If applicable)
      
      none
      
      
      ### Details of new models (If applicable)
      
      Cloud patch interaction models:
      Optionally write patch interaction statistics, e.g. number and mass of particles that stick, escape etc. to file using the optional `writeToFile` entry, e.g.
      
      ```
          localInteractionCoeffs
          {
              patches
              (
                  "(walls|cyc.*)"
                  {
                      type        rebound;
                  }
      
                  "inlet|outlet"
                  {
                      type escape;
                  }
              );
      
              // New optional entry
              writeToFile     yes;
          }
      ```
      
      Cloud function objects:
      New `fields` optional entry can be used to select which particle fields to post-process; if empty or the entry is not given all fields are written (to provide backwards compatibility)
      
      ```
          patchPostProcessing1
          {
              type            patchPostProcessing;
      
              // Optional new entry
              fields          (position "U.*" d T nParticle);
      
              maxStoredParcels 20;
              patches
              (
                  cycLeft_half0
                  cycLeft_half1
              );
          }
      ```
      
      See the `$FOAM_TUTORIALS/lagrangian/reactingParcelFilm/filter` tutorial for an example
      
      
      ### Risks
      
      Low risk
      
      See merge request !301
      71bc3510
    • Andrew Heather's avatar
      Merge branch 'feature-expressions' into 'develop' · 1b17784a
      Andrew Heather authored
      Feature expressions
      
      ### Summary
      
      This branch represents an implementation of what is considered to be the most useful aspects of swak4Foam ([Swiss-Army-Knife for FOAM](https://openfoamwiki.net/index.php/Contrib/swak4Foam)) from Bernhard Gschaider, namely the ability to use text-based expressions instead of coding in C++ for the following cases:
      - expression-based boundary conditions (also known as _groovy_ boundary conditions)
      - expression-based setFields (also known as _funky_ set fields)
      
      The idea of what we currently term *expressions* was pioneered by
      (Bernhard Gschaider) and is now firmly established in `swak4Foam`.
      Among other things, expressions attempt to bridge the gap between
      using standard, predefined boundary conditions and writing dedicated,
      special-purpose ones. Although part of this gap is now covered within
      OpenFOAM by using dynamically compiled user coding (eg, coded boundary
      conditions), there remains substantial areas where it can be
      significantly more convenient to have a series of predefined functions
      and expression sytax with some access to base OpenFOAM field
      functionality that enables rapid deployment of boundary conditions, or
      custom-defined `setFields` without writing code.
      A significant portion of `swak4Foam` expressions has been adapted for
      direct integration into OpenFOAM. During the integration and rewrite,
      we have tried to pare things down to a smaller subset with the aim of
      covering 90% or more of the common cases. The remaining cases are left
      to be reassessed for extending the *expressions* functionality in the
      future, but they also may be better served with other approaches (eg,
      with coded conditions) that were not available when `swak4Foam` was
      originally conceived.
      
      To the greatest extent possible, the integrated *expressions* have
      been designed to avoid name clashes with `swak` so it should remain
      possible to use the most recent versions of `swak` without problem.
      
      
      ### Risks
      
      - New functionality, so low chance of regression.
      - The scope of the functionality will be revised in the future
      
      ### Naming (for `swak4Foam` users)
      
      The following are the *expressions* correspondences to `swak`:
      
      - The `exprFixedValue` and `exprGradient` boundary conditions are
        roughly equivalent to the _groovy_ boundary conditions.
      
      - The utilities `setExprFields` and `setExprBoundaryFields` are
        roughly equivalent to the _funky_ utilities of similar name.
      
      The naming of the boundary conditions and utilities not only reflects
      the slightly different input requirements, but simultaneously seeks to
      avoid any potential name-clash with `swak4Foam` in a mixed
      environment.
      
      The names for the boundary condition dictionary entries tend be
      shorter and slightly different (eg, `valueExpr` vs `valueExpression`)
      to serve as a small reminder that the *expressions* syntax is slightly
      different than the *groovy* equivalents. It also allows the user to
      fashion dictionary entries that are sufficient for **both** boundary
      condition variants and quickly toggle between them simply by changing
      the boundary condition `type`.
      
      See merge request !300
      1b17784a