b6a30fae61
Parts of the adjoint optimisation library were re-designed to generalise the way sensitivity derivatives (SDs) are computed and to allow easier extension to primal problems other than the ones governed by incompressible flows. In specific: - the adjoint solver now holds virtual functions returning the part of SDs that depends only on the primal and the adjoint fields. - a new class named designVariables was introduced which, apart from defining the design variables of the optimisation problem and providing hooks for updating them in an optimisation loop, provides the part of the SDs that affects directly the flow residuals (e.g. geometric variations in shape optimisation, derivatives of source terms in topology optimisation, etc). The final assembly of the SDs happens here, with the updated sensitivity class acting as an intermediate. With the new structure, when the primal problem changes (for instance, passive scalars are included), the same design variables and sensitivity classes can be re-used for all physics, with additional contributions to the SDs being limited (and contained) to the new adjoint solver to be implemented. The old code structure would require new SD classes for each additional primal problem. As a side-effect, setting up a case has arguably become a bit easier and more intuitive. Additional changes include: --------------------------- - Changes in the formulation and computation of shape sensitivity derivatives using the E-SI approach. The latter is now derived directly from the FI approach, with proper discretization for the terms and boundary conditions that emerge from applying the Gauss divergence theorem used to transition from FI to E-SI. When E-SI and FI are based on the same Laplace grid displacement model, they are now numerically equivalent (the previous formulation proved the theoretical equivalence of the two approaches but numerical results could differ, depending on the case). - Sensitivity maps at faces are now computed based (and are deriving from) sensitivity maps at points, with a constistent point-to-face interpolation (requires the differentiation of volPointInterpolation). - The objective class now allocates only the member pointers that correspond to the non-zero derivatives of the objective w.r.t. the flow and geometric quantities, leading to a reduced memory footprint. Additionally, contributions from volume-based objectives to the adjoint equations have been re-worked, removing the need for objectiveManager to be virtual. - In constrained optimisation, an adjoint solver needs to be present for each constraint function. For geometric constraints though, no adjoint equations need to solved. This is now accounted for through the null adjoint solver and the geometric objectives which do not allocate adjoint fields for this kind of constraints, reducing memory requirements and file clutter. - Refactoring of the updateMethod to collaborate with the new designVariables. Additionally, all updateMethods can now read and write restart data in binary, facilitating exact continuation. Furthermore, code shared by various quasi-Newton methods (BFGS, DBFGS, LBFGS, SR1) has been organised in the namesake class. Over and above, an SQP variant capable of tackling inequality constraints has been added (ISQP, with I indicating that the QP problem in the presence of inequality constraints is solved through an interior point method). Inequality constraints can be one-sided (constraint < upper-value) or double-sided (lower-value < constraint < upper-value). - Bounds can now be defined for the design variables. For volumetricBSplines in specific, these can be computed as the mid-points of the control points and their neighbouring ones. This usually leads to better-defined optimisation problems and reduces the chances of an invalid mesh during optimisation. - Convergence criteria can now be defined for the optimisation loop which will stop if the relative objective function reduction over the last objective value is lower than a given threshold and constraints are satisfied within a give tolerance. If no criteria are defined, the optimisation will run for the max. given number of cycles provided in controlDict. - Added a new grid displacement method based on the p-Laplacian equation, which seems to outperform other PDE-based approaches. TUT: updated the shape optimisation tutorials and added a new one showcasing the use of double-sided constraints, ISQP, applying no-overlapping constraints to volumetric B-Splines control points and defining convergence criteria for the optimisation loop. |
||
|---|---|---|
| .gitlab | ||
| applications | ||
| bin | ||
| doc | ||
| etc | ||
| META-INFO | ||
| modules | ||
| src | ||
| tutorials | ||
| wmake | ||
| .gitignore | ||
| .gitmodules | ||
| Allwmake | ||
| CONTRIBUTORS.md | ||
| COPYING | ||
| README.md | ||
About OpenFOAM
OpenFOAM is a free, open source CFD software released and developed by OpenCFD Ltd since 2004. It has a large user base across most areas of engineering and science, from both commercial and academic organisations. OpenFOAM has an extensive range of features to solve anything from complex fluid flows involving chemical reactions, turbulence and heat transfer, to acoustics, solid mechanics and electromagnetics. See documentation
OpenFOAM is professionally released every six months to include customer sponsored developments and contributions from the community - individual and group contributors, integrations (eg, from FOAM-extend and OpenFOAM Foundation Ltd) as well as governance guided activities.
License
OpenFOAM is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. See the file COPYING in this directory or http://www.gnu.org/licenses/, for a description of the GNU General Public License terms under which you may redistribute files.
OpenFOAM Trademark
OpenCFD Ltd grants use of its OpenFOAM trademark by Third Parties on a licence basis. ESI Group and OpenFOAM Foundation Ltd are currently permitted to use the Name and agreed Domain Name. For information on trademark use, please refer to the trademark policy guidelines.
Please contact OpenCFD if you have any questions about the use of the OpenFOAM trademark.
Violations of the Trademark are monitored, and will be duly prosecuted.
Using OpenFOAM
If OpenFOAM has already been compiled on your system, simply source
the appropriate etc/bashrc or etc/cshrc file and get started.
For example, for the OpenFOAM-v2312 version:
source /installation/path/OpenFOAM-v2312/etc/bashrc
Compiling OpenFOAM
If you are compiling OpenFOAM from source, please see the relevant guides:
| Location | Readme | Requirements | Build |
|---|---|---|---|
| OpenFOAM | readme | system requirements | build |
| ThirdParty | readme | system requirements | build |
If you need to modify the versions or locations of ThirdParty software, please read how the OpenFOAM configuration is structured.
How do I know which version I am currently using?
The value of the $WM_PROJECT_DIR or even $WM_PROJECT_VERSION are
not guaranteed to have any correspondence to the OpenFOAM release
(API) value. If OpenFOAM has already been compiled, the build-time
information is embedded into each application. For example, as
displayed from blockMesh -help:
Using: OpenFOAM-com (2012) - visit www.openfoam.com
Build: b830beb5ea-20210429 (patch=210414)
Arch: LSB;label=32;scalar=64
This output contains all of the more interesting information that we need:
| item | value |
|---|---|
| version | com (eg, local development branch) |
| api | 2012 |
| commit | b830beb5ea |
| author date | 20210429 |
| patch-level | (20)210414 |
| label/scalar size | 32/64 bits |
The Arch information may also include the solveScalar size
if different than the scalar size.
As can be seen in this example, the git build information is
supplemented by the date when the last change was authored, which can
be helpful when the repository contains local changes. If you simply
wish to know the current API and patch levels directly, the
wmake -build-info provides the relevant information even
when OpenFOAM has not yet been compiled:
$ wmake -build-info
make
api = 2012
patch = 210414
branch = master
build = 308af39136-20210426
Similar information is available with foamEtcFile, using the
-show-api or -show-patch options. For example,
$ foamEtcFile -show-api
2012
$ foamEtcFile -show-patch
210414
This output will generally be the easiest to parse for scripts.
The $FOAM_API convenience environment variable may not reflect the
patching changes made within the currently active environment and
should be used with caution.
ThirdParty directory
OpenFOAM normally ships with a directory of 3rd-party software and build scripts for some 3rd-party software that is either necessary or at least highly useful for OpenFOAM, but which are not necessarily readily available on every operating system or cluster installation.
These 3rd-party sources are normally located in a directory parallel to the OpenFOAM directory. For example,
/path/parent
|-- OpenFOAM-v2312
\-- ThirdParty-v2312
There are, however, many cases where this simple convention is inadequate:
-
When no additional 3rd party software is actually required (ie, the operating system or cluster installation provides it)
-
When we have changed the OpenFOAM directory name to some arbitrary directory name, e.g. openfoam-sandbox2312, etc..
-
When we would like any additional 3rd party software to be located inside of the OpenFOAM directory to ensure that the installation is encapsulated within a single directory structure. This can be necessary for cluster installations, or may simply be a convenient means of performing a software rollout for individual workstations.
-
When we have many different OpenFOAM directories for testing or developing various different features but wish to use or reuse the same 3rd party software for them all.
The solution for these problems is a newer, more intelligent discovery when locating the ThirdParty directory with the following precedence:
- PROJECT/ThirdParty
- for single-directory installations
- PREFIX/ThirdParty-VERSION
- this corresponds to the traditional approach
- PREFIX/ThirdParty-vAPI
- allows for an updated value of VERSION, eg,
v2312-myCustom, without requiring a renamed ThirdParty. The API value would still be2312and the originalThirdParty-v2312/would be found.
- allows for an updated value of VERSION, eg,
- PREFIX/ThirdParty-API
- same as the previous example, but using an unadorned API value.
- PREFIX/ThirdParty-common
- permits maximum reuse for various versions, for experienced users who are aware of potential version incompatibilities
If none of these directories are found to be suitable, it reverts to using PROJECT/ThirdParty as a dummy location (even if the directory does not exist). This is a safe fallback value since it is within the OpenFOAM directory structure and can be trusted to have no negative side-effects. In the above, the following notation has been used:
| name | value | meaning |
|---|---|---|
| PROJECT | $WM_PROJECT_DIR |
The OpenFOAM directory |
| PREFIX | dirname $WM_PROJECT_DIR |
The OpenFOAM parent directory |
| API | foamEtcFiles -show-api |
The api or release version |
| VERSION | $WM_PROJECT_VERSION |
The version we have chosen |
To reduce the potential of false positive matches (perhaps some other
software also uses ThirdParty-xxx for its naming), the directory test
is accompanied by a OpenFOAM-specific sanity test. The OpenFOAM
ThirdParty directory will contain either an Allwmake file or a
platforms/ directory.
Useful Links
- Download source and download and installation instructions
- Documentation
- Reporting bugs/issues/feature requests
- Issue tracker
- Code wiki and General wiki
- Governance, Governance Projects
- Contacting OpenCFD
Copyright 2016-2023 OpenCFD Ltd