openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2024-03-19T14:53:03Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/669ENH: adjust renumbering methods, extend renumberMesh options2024-03-19T14:53:03ZMark OLESENENH: adjust renumbering methods, extend renumberMesh optionsUpdate to renumber methods. The user-exposed aspect is in the `renumberMesh` application which now has additional options.
* Use -dry-run with -write-maps to visualize the before/after effects of renumbering (creates a VTK file).
* The ...Update to renumber methods. The user-exposed aspect is in the `renumberMesh` application which now has additional options.
* Use -dry-run with -write-maps to visualize the before/after effects of renumbering (creates a VTK file).
* The `-no-fields` option to renumber the mesh only. This is useful and faster when the input fields are uniform and the -overwrite option is specified.
* The `-renumber-method` allows a quick means of specifying a different default renumber method (instead of Cuthill-McKee).
* The `-renumber-coeffs` option allows passing of dictionary content for the method.
Examples,
```plaintext
// Different ways to specify reverse Cuthill-McKee
-renumber-method RCM
-renumber-coeffs 'reverse true;'
-renumber-method CuthillMcKee
-renumber-coeffs 'reverse true;'
-renumber-coeffs 'method CuthillMcKee; reverse true;'
// Other (without dictionary coefficients)
renumberMesh -renumber-method random
// Other (with dictionary coefficients)
renumberMesh \
-renumber-method spring \
-renumber-coeffs 'maxCo 0.1; maxIter 1000; freezeFraction 0.99;'
// Other (with additional libraries)
renumberMesh -renumber-method zoltan -lib zoltanRenumber
```
The new `-decompose` option permits a region-wise decomposition prior to renumbering. The effects of this can be seen in the following![renumberMesh](/uploads/db54f9de5800af743ec670568cc454e9/renumberMesh.png)
The original cells are randomly numbered. With the `-decompose` option, these can be _"lumped"_ into regions before renumbering on a per region basis. If the region-wise renumbering is forcibly _disabled_ (ie, -renumber-method none), it can be seen that the resulting cellIds retain the random nature of the original cell ordering. This corresponds to what `decomposePar` without a subsequent renumber would do, so could be indicative that an optional renumber stage would be reasonable to add into `decomposePar` in the future.v2406Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/688INT: cyclicPeriodicAMI: demo case provided by Hakan Nilsson2024-06-07T11:29:03ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comINT: cyclicPeriodicAMI: demo case provided by Hakan NilssonAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/670Feature overlapping zones2024-03-13T14:44:15ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comFeature overlapping zones### Summary
More functionality to allow overlapping zones (cell,face,pointZones). (note this was already supported in polyMesh and decomposePar)
### Resolved bugs (If applicable)
none
### Details of new models (If applicable)
It is ...### Summary
More functionality to allow overlapping zones (cell,face,pointZones). (note this was already supported in polyMesh and decomposePar)
### Resolved bugs (If applicable)
none
### Details of new models (If applicable)
It is not used by default - it requires explicit code changes to insert overlapping cellZones. So far adaptations have been made:
- mesh.cellZones() / faceZones() etc : investigate which zones items are in
- redistributePar
- subsetMesh
- polyTopoChange
### Risks
Should be backwards compatible.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/667Draft: ENH: Polyhedral AMR2024-06-11T18:23:31ZKutalmış BerçinDraft: ENH: Polyhedral AMR@Development
Test cases: [MR666-test-cases-22Feb24.zip](/uploads/5d70f346da25f7e66088c5dbd0812eef/MR666-test-cases-22Feb24.zip)@Development
Test cases: [MR666-test-cases-22Feb24.zip](/uploads/5d70f346da25f7e66088c5dbd0812eef/MR666-test-cases-22Feb24.zip)Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/649ENH: update of the adjoint library and introduction of topology optimisation2023-12-18T18:01:58ZVaggelis PapoutsisENH: update of the adjoint library and introduction of topology optimisation### Summary
Overhaul and generalization of the adjoint library and introduction of topology optimisation capabilities.
### Details
## Shape optimisation
- An overhaul of the adjoint library to ease extension to flow physics other t...### Summary
Overhaul and generalization of the adjoint library and introduction of topology optimisation capabilities.
### Details
## Shape optimisation
- An overhaul of the adjoint library to ease extension to flow physics other than incompressible flows (see 9a89fcc0 for details)
- Corrections/improvements to shape optimisation, like (see 9a89fcc0 for details)
1. Improved consistency between the E-SI and FI formulations for computing sensitivity derivatives for shape optimisation.
An example of the code behavior before and after the changes is given below, obtained from the tutorial under
$FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/naca0012/laminar/moment/primalAdjoint
| _NACA0012 $C_M$ sensitivities, v2306_ | _NACA0012 $C_M$ sensitivities, v2312_ |
| ------ | ------ |
| ![NACA0012_CM_SDs_v2306](/uploads/de43498c82bffbfa6e1d99c0fd077c64/NACA0012_CM_SDs_v2306.jpg) | ![NACA0012_CM_SDs_v2312](/uploads/9d7c7db2522560cc72fcc03af3846ad5/NACA0012_CM_SDs_v2312.jpg) |
2. Consistent point/face sensitivity maps
| _Drivaer drag sensitivity map computed on boundary faces, v2306_ | _Drivaer drag sensitivity map computed on boundary faces, v2312_ |
| ------ | ------ |
| ![old_top](/uploads/abf5dc373a554e8c8e010ab38e24de76/old_top.png) | ![new_top](/uploads/c85f04a1a4292c30d868285d713b3739/new_top.png) |
| ![old_bottom](/uploads/a18da7e61c27303c508f541662549a29/old_bottom.png) | ![new_bottom](/uploads/a3ee7d84cbf68adfea504a250fa6a35d/new_bottom.png)|
By comparing the drag sensitivity maps computed with v2306 and v2312, it can be observed that: a) the new point-to-face interpolation produces smoother results, even for the raw (i.e. non-smoothed) sensitivities and b) artifacts close to the symmetry plane of the car have disappeared.
3. A new adjoint solver (null) and objective function (geometric) type, for defining geometric constraints without unnecessarily allocating new adjoint fields
4. Three new update methods (ISQP, nullSpace, MMA) for tackling optimisation problems with inequality constraints
5. Introduction of bounds for the design variables; for volumetric B-Splines this can help better preserve the quality of the mesh throughout the optimisation
6. Introduction of convergence criteria for the optimisation loop.
Features 3 to 6 are showcased in the new tutorial
$FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/naca0012/laminar/multipleConstraints
## Topology optimisation
New topology optimisation capabilities, using either a porosity-based or a level-set approach. Both include the capability of exporting the designed geometry as an STL, for production and/or re-evaluation with a body-fitted grid.
The porosity-based approach relies on a field of design variables (artificial porosities, $\alpha$) that block the counter-productive parts of the computational domain by solidifying them. To increase the smoothness of the obtained solutions, a regularisation equation is solved computing the intermediate field $\widetilde{\alpha}$, followed by a sharpening/projection step to compute the almost binary field $\beta$. The latter is then used to introduce sources terms to the flow equations that drive the flow solution to zero in the solidified areas (i.e., areas with $\beta \approx 1$). The steps of the above-mentioned process are showcased below
| _$\alpha$_ | _$\widetilde{\alpha}$_ | _$\beta$_ |
| ------ | ------ | ------ |
![alpha](/uploads/afa2c81bc7c508cfa5c0d1e7f3731ee8/alpha.png) |![alphaTilda](/uploads/12b77de6a2e08214fb641528ddcf3199/alphaTilda.png) |![beta](/uploads/679feaa6bdb0dbad86a4c8881b7a9540/beta.png) |
The following table shows the results of topology optimisation for three different variants of the same case, namely the minimization of total pressure losses ($J_{pt}$) (left), minimization of $J_{pt}$ with a constraint on equally distributing the volume flow rate between the bottom and right outlets ($J_{m}$) (center) and maximization of the flow uniformity ($J_{un}$), under the $J_{pt} \lt J_{pt}^{target}$ constraint (right).
The cases can be found under
`$FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/topologyOptimisation/monoFluidAero/turbulent/1_Inlet_2_Outlet/porosityBased/BP`
| _min. losses_ | _min. losses <br /> flow-rate constr._ | _max. uniformity, <br /> losses constr._ |
| ------ | ------ | ------ |
|![lossesBeta](/uploads/ece378af3dc5fd1b2683e4a904e427aa/lossesBeta.png)|![lossesMassBeta](/uploads/60490f773c693f562b1f5220c6ff5659/lossesMassBeta.png) |![uniBeta](/uploads/3fa45605cb225fcaaf2119256e7310fd/uniBeta.png) |
|![lossesU](/uploads/589d98b42dd5340596ec2987160bfdb3/lossesU.png) |![lossesMassU](/uploads/d31e2fda88b8efea8aaf23ee41291951/lossesMassU.png) |![uniU](/uploads/74a19533bf22ef3c5ecc20c2f4dc1457/uniU.png) |
The next table showcases the outcome of topology optimisation for a 3D manifold, with similar objective and constraint functions. The first row depicts the progression of the boundary between the fluid and solid parts of the computational domain during the optimisation cycles and the last row illustrates the STL files of the three optimised geometries. The process of generating the latter is automatic and executed at the end of each optimisation cycle. These STL files can then be used for performing body-fitted simulations with proper boundary condition or subsequent shape optimisations or even for manufacturing.
The cases can be found under
`$FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/topologyOptimisation/monoFluidAero/laminar/3DBox`
| _min. losses_ | _min. losses <br /> flow-rate constr._ | _max. uniformity, <br /> losses constr., flow-rate constr._ |
| ------ | ------ | ------ |
|![3DBox-losses](/uploads/17dd3d265fd345fea1b48430342e71f4/3DBox-losses.gif) |![3DBox-losses-mass](/uploads/8f01ce07f0334c57ee6362a2b033b193/3DBox-losses-mass.gif) |![3DBox-losses-mass-uniformity](/uploads/216366e0d099c42c6d8dc450ecc6513f/3DBox-losses-mass-uniformity.gif) |
![losses](/uploads/8d0665ccc1df236dff53d52c3c894f5a/losses.gif) |![losses-mass](/uploads/8f09d661b1cb6f21dcfca528a528f687/losses-mass.gif) |![uni-losses-mass](/uploads/77a53324c6ca587f9633baa48af07b93/uni-losses-mass.gif)
More tutorials can be found under
`$FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/topologyOptimisation`
### Risks
The entries of optimisationDict.optimisation have slightly changed, arguably towards something more intuitive. The changes can be observed by comparing, for instance, the optimisationDict of $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/motorbike with its previous variant
Successfully compiles with
- [x] Gcc9.3 int32 DP
- [x] clang 15 int32 DP
- [x] clang 15 int32 SPDPv2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/633ENH: zone improvements2023-10-19T10:23:17ZMark OLESENENH: zone improvementsChanges to retain group information when copying, consistency improvements and reduced overhead when re-readingChanges to retain group information when copying, consistency improvements and reduced overhead when re-readingv2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/617Updates to function objects handling of patches / selection names for parallel consistent order2023-08-01T15:26:44ZMark OLESENUpdates to function objects handling of patches / selection names for parallel consistent order- update IOobjectList to have a `csorted()` method (as per objectRegistry) and noisily deprecate `sorted() const` versions in various places since resolution of the correct return type (`<const T>` vs `<T>`) makes it susceptible to the o...- update IOobjectList to have a `csorted()` method (as per objectRegistry) and noisily deprecate `sorted() const` versions in various places since resolution of the correct return type (`<const T>` vs `<T>`) makes it susceptible to the object access type.
- use sorted patch Ids and selectionNames in functionObjects to avoid possible differences in ordering (parallel consistency).
- prefer use of `sorted()` and `csorted()` instead of via HashTable-based names or toc(), since this generally provides lower overhead and allows more compact expression. It also avoids subsequent hash lookups when accessing the object pointers.
- use MinMax range to simplify binModelsAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/616refine PtrList and other emplace methods2023-07-28T14:41:18ZMark OLESENrefine PtrList and other emplace methods- refine some of the PtrList methods to reduce memory peaks
- other code cleanup- refine some of the PtrList methods to reduce memory peaks
- other code cleanupAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/598ENH: forces: avoid redundant volumetric operations2023-06-06T07:29:08ZKutalmış BerçinENH: forces: avoid redundant volumetric operations#### Problem
It has been observed that employing the `forces` and `forceCoeffs` function objects in several simulations causes a slowdown ranging from 2 to 10%.
The culprits found were:
- Calculation of velocity gradient
- Redundant c...#### Problem
It has been observed that employing the `forces` and `forceCoeffs` function objects in several simulations causes a slowdown ranging from 2 to 10%.
The culprits found were:
- Calculation of velocity gradient
- Redundant calculations performed for various internal fields
#### Solution
- It is recommended to cache 'grad(U)' whenever using `forces` and `forcesCoeffs` function objects.
- The recent commits have eliminated unnecessary computations for the internal field of `devRhoReff`.
- Tests using the `simpleCar` tutorial ('grad(U)' was cached) produced the following 'profiling' figures:
![image](/uploads/c4b1c39cde976ad13cec2ee835523bf1/image.png)
- Tests using an industrial case ('grad(U)' was cached) reduced the `functionObjects.execute()` from ~72[s] to ~23[s].
#### Meta-data
* EP2065
* [x] `linux64ClangDPInt32Opt` (clang13)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new error/No change in existing output
* [x] No output change in all operating conditions (e.g. direct force intensity, porosity, compressible flows etc.)Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/596Improved point-cell and cell-point topology methods2023-03-03T16:41:20ZAlon ZameretImproved point-cell and cell-point topology methods# Goal
The goal of this change is to reduce the runtime of the `pointCells()` and `cellPoints()` methods in the `primitiveMesh` class, which calculate the point-to-cell and cell-to-point addressing, respectively.
# Proposed Change
The...# Goal
The goal of this change is to reduce the runtime of the `pointCells()` and `cellPoints()` methods in the `primitiveMesh` class, which calculate the point-to-cell and cell-to-point addressing, respectively.
# Proposed Change
The `pointCells()` currently calculates the topology using the private method `calcPointCells()`, which utilizes the method `labels()` in the `cell` class. This method introduces significant overhead and reduces performance. The `cellPoints()` method currently calls the `pointCell()` method and inverts the result.
The proposed solution implements the `cellPoints()` method directly using a more efficient algorithm that makes use of the `bitset` data class to mark points that have already been found. Then, the `pointCells()` method is implemented by calling `cellPoints()` and inverting the result. As can be seen below, our implementation improves performance in all cases, even if the user only wants the point-cell topology.
# Results
The speedup values were calculated by running both the current version and the new version on structured cube meshes of varying sizes. It can be seen that the speedup remains constant among all the different mesh sizes.
In the testing, the meshes began without either one of the topologies present. Then 3 different cases were tested:
1. The user wants only point-cell topology
- Speedup = 1.4x
2. The user wants only cell-point topology
- Speedup = 2.4x
3. The user wants both topologies
- Speedup = 1.7x
![Screenshot](/uploads/f817bd3f389edff96fe6c9a62d6146b5/Screenshot.png)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/588Draft: New renumbering based on Hamiltonian path2023-06-23T07:39:56ZAlon ZameretDraft: New renumbering based on Hamiltonian path### Summary
Included a new renumbering method called 'hpathRenumber' which reorder the mesh cells using an Hamiltonian path approach.
### Details of new models
Hamiltonian path is a path that traverses through the mesh faces and visi...### Summary
Included a new renumbering method called 'hpathRenumber' which reorder the mesh cells using an Hamiltonian path approach.
### Details of new models
Hamiltonian path is a path that traverses through the mesh faces and visits each cell exactly once. The Hamiltonian path approach tries to find such a path and renumber the mesh accordingly. This method ensures that after the mesh renumbering, consecutive cells in memory will likely share a common geometrical face. This in turn may allow for more efficient memory access and better vectorization performances when traversing the mesh.
![2D_Cylinder_Hpath](/uploads/90b36b3ca4136da32aaa93090c9300c0/2D_Cylinder_Hpath.png)
### Usage
Described below is the renumberMethodDict example used to apply Hamiltonian path renumbering:
```
method hpath;
hpathCoeffs
{
layered true;
}
```
The 'layered' argument (default true) controls whether the algorithm will separate the mesh cells into different 'layers' (otherwise, all cells are considered to be within the same layer). The layer separation approach is known to obtain better results and improved run-time for 3D cases, while 2D cases where a simpler Hamiltonian path may exist will benefit from avoiding the layer separation.
The algorithm will than try to find an Hamiltonian path traversing through all the cells sharing the same layer, and report the Hamiltonian path accuracy obtained.
The path accuracy is defined as the percentage of consecutive cells in the renumbered order that share a common face.v2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/587Draft: New decomposition method (multiNodeDecomp)2023-06-23T07:40:04ZAlon ZameretDraft: New decomposition method (multiNodeDecomp)### Summary
A new decomposition method 'multiNodeDecomp' which extends the capabilities of the multi-level decomposition method found within OpenFOAM while maintaining full backwards compatibility.
The multiNodeDecomp allow users contro...### Summary
A new decomposition method 'multiNodeDecomp' which extends the capabilities of the multi-level decomposition method found within OpenFOAM while maintaining full backwards compatibility.
The multiNodeDecomp allow users control over the properties of each node within the decomposition tree, as opposed to multi-level decomposition which supports level-based modifications.
### Details of new decomposition method
The multiNodeDecomp method adds the following capabilities:
1. Support decomposition to un-even nodes by changing the number of children of each node. For example:
```
multiNodeCoeffs {
method metis;
domains (3 4);
domains[0] (8);
}
```
In the example above, the mesh will be decomposed into 3 domains, where the first domain (domain[0]) will be further decomposed into 8 subdomains, while the remaining 2 domains will be decomposed into 4 subdomains only.
This will result in a total of 20 subdomains.
Note that the user passes a list value, which allows to have a different number of levels under different branches of the decomposition tree.
2. Simplified interface for decomposition weights - uniform/relative weight distribution may be used to initialize the weight of each node. The user may later overwrite any of the nodes weight.
```
weightsInitialization relative;
weight[0][3] 2;
```
'Uniform' initialization will recursively set all of the nodes weights to 1, while the 'Relative' initialization sets each nodes weight to the number of leaves in its decomposition subtree.
The weight of a node is then used during its parent's decomposition to control the sub-mesh size it will receive.
3. Modify the nodes decomposition method:
```
method[2] {
method scotch;
coeffs {
...
}
}
```
This will overwrite the method of the third subdomain of the root to use scotch and the given coefficients.
### Syntax
multiNodeDecomp supports setting the decomposition properties above on a level scope (parameter[] value) or on a node scope (parameter[#nodeIndex] value).
The square brackets indicate indices of the children we want to modify (0 based indexing). The user may specify ranges by using a hyphen ([0-3]) or specifying all of the children by using empty brackets ([]).v2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/556Draft: unsteady adjoint functionality2024-06-11T18:23:35ZVaggelis PapoutsisDraft: unsteady adjoint functionality### Summary
Introduced unsteady adjoint functionality. Currently supports full storage of the primal time-series or utilization of binomial checkpointing.
This branch also serves as a fetching point for the profiling and improvement o...### Summary
Introduced unsteady adjoint functionality. Currently supports full storage of the primal time-series or utilization of binomial checkpointing.
This branch also serves as a fetching point for the profiling and improvement of the unsteady adjoint code during the exaFoam project.
### Details of new models
- The unsteady adjoint equations are integrated backwards in time. Since each adjoint time-step requires the primal solution of that time-step to be known, schemes for managing the storage/retrieval of the entire flow series are necessary. These are implemented through the primalStorage class and its derived ones. The latter manipulate a new class of fields, called compressedGeometricFields, which provide hooks for compressing/decompressing a field during the time integration of the primal/adjoint equations. The method used for compressing/decompressing is run-time selectable.
- The current commit provides the shortGeometricField implementation which avoids the storage of patchFields that can be retrieved from the internalField (e.g. coupled, zeroGradient, symmetry, etc), to cut on the storage requirements. More elaborate compression approaches will be included in the future, during the exaFoam project.
- Two primalStorage options are included: compressedFullStorage and binomialCheckPointing.
- compressedFullStorage stores the entire flow time-series, potentially by compressing each time-step (only the above-mentioned short approach is available for the moment).
- binomialCheckPointing is based on the homonymous algorithm proposed in
\verbatim
Wang, Q., Moin, P., & Iaccarino, G..
Minimal Repetition Dynamic Checkpointing Algorithm for
Unsteady Adjoint Calculation (2009).
SIAM Journal on Scientific Computing, 31(4), 2549-2567.
10.1137/080727890,
\endverbatim
which stores the solution of the flow equations in a predefined
number of time-steps, named checkpoints. During the
backwards-in-time integration of the adjoint equations, if the
primal solution at a certain time-step is not available, it is
retrieved by re-computing the primal flow field starting from the
closest checkpoint. Checkpoints are optimally distributed
throughout the time-series to invoke the least number of flow
recomputations during the backwards-in-time solution of the
adjoint equations. Binomial checkpointing is the current state of
the art though its re-computation cost frequently amounts for an
extra solution of the flow equations in medium-to-large cases.
- The adjoint to the PISO and PIMPLE solvers, along with their solverControl variants, are additionally included.
- Objective functions are integrated in time, through appropriate entries in the dictionaries defining them.
Authored by Andreas Margetis and reviewed by Vaggelis Papoutsis, with earlier contributions from Dr. Ioannis Kavvadias.v2312Vaggelis PapoutsisVaggelis Papoutsishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/477Implicit treatment of coupled boundary conditions2021-08-03T20:08:53ZSergio FerrarisImplicit treatment of coupled boundary conditions## Summary
The alternative addressing insert new internal faces on selected coupled patches. Extending the matrix addressing allows the implicit treatment of some boundary conditions. At the moment, the BCs which can be made implicit ar...## Summary
The alternative addressing insert new internal faces on selected coupled patches. Extending the matrix addressing allows the implicit treatment of some boundary conditions. At the moment, the BCs which can be made implicit are: cyclic, AMI, ACMI and mapped.
The entry `useImplicit true` is needed in the field BC. Only scalar fields can be made implicit (p, p_rgh, k, epsilon, etc). The U field **cannot** be implicit.
The top solvers are unchanged except for the cht solvers where a single he matrix is built for the multi-region case.
In the case that more than one patch is present, the user can choose which ones are treated implicitly, i.e **p** can be implicit in AMI1 and explicit in AMI2 and **k** the other way around.
Currently, there exists a limitation for parallel cases where AMI patch-pairs need to be on the same processor. For cyclics and mapped patches, the number of faces on each processor **MUST** be the same. Therefore a constraint decomposition needs to be used.
## Details of new models
The model adds a new numbering of internal/boundary coefficients and patch ID's. This is constructed at the call of the matrix.solve() - it is reset to the original addressing after solving.
The original internal/boundary coeffs are cached and used (in some cases with some extra information) to fill the coefficients on the new internal faces and/or source term on the newly formed fvMatrix.
## Tutorials
- tutorials/heatTransfer/chtMultiRegionSimpleFoam/cpuCabinet/
- tutorials/heatTransfer/chtMultiRegionFoam/snappyMultiRegionHeaterImplicit/
- tutorials/basic/laplacianFoam/implicitAMI/
- tutorials/basic/simpleFoam/implicitAMI
- tutorials/basic/chtMultiRegionFoam/2DImplicitCyclic/
## Risks
Addressing of cells on the patches are changed, this needs to be passed to all the lduInterfaces. Use alternative lduAddressing in lduMatrix.
The coupled BCs (cyclics, AMI, mapped) which made implicit don't exist at the moment of solving the matrix. Thus, any fvOption or FO referring to this BC will **Fail**
In general terms when using the implicit approach the lduaddressing changes and therefore any matrix solve will be affected in _all top level solvers and all the linear solvers_.v2112Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/457support parallel creation of finiteArea meshes with on-the-fly decomposition of fields #20842021-05-28T18:14:55ZMark OLESENsupport parallel creation of finiteArea meshes with on-the-fly decomposition of fields #2084v2106Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/450ENH: update geoVoF module (#2076)2021-06-24T16:48:11ZHenning ScheuflerENH: update geoVoF module (#2076)@johan_roenby
Changes:
* renamed interface fields recon::centre -> interfaceCentre.{phaseName}
* interface fields are not written by default
* compatible with AMR and load balancing
Status:
* all tests and tutorial cases pass
the test...@johan_roenby
Changes:
* renamed interface fields recon::centre -> interfaceCentre.{phaseName}
* interface fields are not written by default
* compatible with AMR and load balancing
Status:
* all tests and tutorial cases pass
the testsuite is not included in the commits but is available in issue #2076.v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/405Feature var rho turb vof2020-12-16T17:57:47ZSergio FerrarisFeature var rho turb vof1) PhaseIncompressibleTurbulenceModel class was changed to use
uniform alpha and non-uniform rho templates. This fits the need
of incompressible two phase turbulence models.
2) A new type DPMIncompressibleTurbulenceModel was creat...1) PhaseIncompressibleTurbulenceModel class was changed to use
uniform alpha and non-uniform rho templates. This fits the need
of incompressible two phase turbulence models.
2) A new type DPMIncompressibleTurbulenceModel was created for
non-uniform alpha and uniform rho. It is used in single phase flows
in DPM solvers where alpha represents the volumen occupancy.
3) A new type incompressibleRhoTurbulenceModel was created where
non-uniform rho is allowed.
4) A new base templated turbulent class for two-phase VOF named
VoFphaseTurbulentTransportModel was implemented which is created
templating on PhaseIncompressibleTurbulenceModel and
incompressibleRhoTurbulenceModel
5) In order to make the chnage to rho based VOF turbulence a help
class was added incompressibleInterPhaseTransportModel templated
on the mixing.v2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/384Feature generalized newtonian2021-01-28T12:30:08ZSergio FerrarisFeature generalized newtonian1) Derivative of B in thermo.H (dKcdTbyKc) calculated from S and G instead of dGdT. (ported from org)
For the thermos, S and G are easier to obtain that dGdT.
In our branch the Jacobian dKcdTbyKc is not used in the reaction me...1) Derivative of B in thermo.H (dKcdTbyKc) calculated from S and G instead of dGdT. (ported from org)
For the thermos, S and G are easier to obtain that dGdT.
In our branch the Jacobian dKcdTbyKc is not used in the reaction mechanism, but it could be needed in the
future.
2) Removing hRefConst and eRefConst thermos and adding optional hRef, eRef
and Tref as optional in hCosnt and eConst. Tutorials were updated.
3): adding generalizedNewtonian to laminar turbulence model
The generalizedNewtonian viscosity models were ported from
the org version and added to the laminar turbulence framework.
This allows its use to compressible and incompressible solvers
through the turbulence dictionary under the laminar sub-dictionary.
The thermal laminar viscosity is taken from the thermo for solvers
that use thermo library or from the transportProperties dictionary
for incompressible solvers.
At the moment the option to include viscosity models through the
transportDict is still available.
The icoTabulated EoS, hTabulated thermo and tabulated transport were ported from the org version
All the single phase solvers are ready to use the generalizedNewtonian laminar models. Some multi-phase
solver needs the instantiation of the transport.
The VoF solver icoReactingMultiPhaseInterFoam is capable of using the new models.
Updating tutorial:
tutorials/multiphase/icoReactingMultiPhaseInterFoam/inertMultiphaseMultiComponentv2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/383Feature block mesh edges2020-10-06T08:37:12ZMark OLESENFeature block mesh edges- adds a new, more natural way to specify block mesh _arc_ edges using the arc origin that eliminates tedious and error-prone calculations. For example,
```
arc 0 1 origin (0 0 0);
```
When the keyword is missing, this corresponds to the...- adds a new, more natural way to specify block mesh _arc_ edges using the arc origin that eliminates tedious and error-prone calculations. For example,
```
arc 0 1 origin (0 0 0);
```
When the keyword is missing, this corresponds to the traditional means of specifying the arc via an additional point on the circumference (full backward compatibility). For example,
```
arc 0 1 (0.707 0.707 0);
```Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/370DOC-STYLE: various release changes2020-06-16T12:50:23ZKutalmış BerçinDOC-STYLE: various release changes- Header-file documentation of various new functionalities was moved to the Extended Code Guide.
- Various corrections to the clashes in release commits #1726- Header-file documentation of various new functionalities was moved to the Extended Code Guide.
- Various corrections to the clashes in release commits #1726v2006Andrew HeatherAndrew Heather