openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2023-12-18T15:59:33Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/653ENH: fileOperation: fix fileOperation::nProcs to handle multiple candidates2023-12-18T15:59:33ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: fileOperation: fix fileOperation::nProcs to handle multiple candidatesAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/652ENH: add profiling hooks for Extrae into the OpenFOAM profiling (#3043)2023-12-19T14:45:45ZMark OLESENENH: add profiling hooks for Extrae into the OpenFOAM profiling (#3043)- the hooks are defined as weak symbols and are compiled into OpenFOAM
by default. If the library is not loaded (via LD_PRELOAD) the hooks
have no effect.
- https://tools.bsc.es/extrae
- https://tools.bsc.es/paraver- the hooks are defined as weak symbols and are compiled into OpenFOAM
by default. If the library is not loaded (via LD_PRELOAD) the hooks
have no effect.
- https://tools.bsc.es/extrae
- https://tools.bsc.es/paraverv2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/651ENH: cyclicAMI: add non-blocking for GAMG2023-12-18T12:56:35ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: cyclicAMI: add non-blocking for GAMG### Summary
- see #3052 : add polling support for processorGAMGInterfaceField
- extend cyclicAMI, cyclicACMI to add non-blocking support for cyclicA(C)MIGAMGInterfaceField
### Resolved bugs (If applicable)
#3052
### Risks
- proces...### Summary
- see #3052 : add polling support for processorGAMGInterfaceField
- extend cyclicAMI, cyclicACMI to add non-blocking support for cyclicA(C)MIGAMGInterfaceField
### Resolved bugs (If applicable)
#3052
### Risks
- processorGAMGInterfaceField fix is for adding polling and not risky
- cyclicAMI, cyclicACMI support has been tested little
@markAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/650Improved DimensionedField/GeometricField factory methods2023-12-12T11:58:00ZMark OLESENImproved DimensionedField/GeometricField factory methodsAs as precursor to future changes, support more flexible creation of tmp GeometricFieldsAs as precursor to future changes, support more flexible creation of tmp GeometricFieldsv2312Andrew 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/648ENH: KinematicWeberNumber: New cloud function object2023-12-05T09:48:44ZKutalmış BerçinENH: KinematicWeberNumber: New cloud function object### Summary
Calculates and writes particle Weber number field on the cloud.
See the header file documentations for the details.
### Risks
No change in existing input/output.
#### Metadata
- [x] linux64ClangDPInt32Opt (clang15)
- [x]...### Summary
Calculates and writes particle Weber number field on the cloud.
See the header file documentations for the details.
### Risks
No change in existing input/output.
#### Metadata
- [x] linux64ClangDPInt32Opt (clang15)
- [x] linux64GccDPInt32Opt
- [x] linux64GccSPDPInt64Debug
- [x] Alltest: No new error/No change in existing output
- [x] Test cases: `$FOAM_TUTORIALS/lagrangian/kinematicParcelFoam/spinningDisk`v2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/647Extended patchSeedSet to generate seed points more uniformly2023-12-08T11:42:23ZAndrew HeatherExtended patchSeedSet to generate seed points more uniformlyUpdated method of creating seed points on patches to provide a more uniform distribution
See #3014Updated method of creating seed points on patches to provide a more uniform distribution
See #3014v2312Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/646Extract case and solver information2023-12-04T09:51:36ZAndrew HeatherExtract case and solver informationSeries of changes to support extraction of case/solver information in OpenFOAM dictionary/JSON formats.
- ENH: checkMesh - added -writeChecks option
- TUT: Added caseInfo function object example
- ENH: Added new caseInfo function object...Series of changes to support extraction of case/solver information in OpenFOAM dictionary/JSON formats.
- ENH: checkMesh - added -writeChecks option
- TUT: Added caseInfo function object example
- ENH: Added new caseInfo function object
- ENH: Added new JSONformatter to write Ostream content in JSON format
- ENH: polyMeshCheck - added mesh quality metrics to meshState dictionary
- STYLE: Refactoring use of meshState in {fv|faMesh}
- STYLE: renamed/moved 'data' to 'meshState'v2312Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/645ENH: GAMG: processor agglomeration extended for all interfaces2023-12-21T17:39:07ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: GAMG: processor agglomeration extended for all interfaces# Support for `cyclicAMI` in processorAgglomeration (inside GAMG)
## Problem description:
When running in parallel on many cores the coarsest level solver (e.g. `PCG`) might become the scaling bottleneck. One way to get around this is t...# Support for `cyclicAMI` in processorAgglomeration (inside GAMG)
## Problem description:
When running in parallel on many cores the coarsest level solver (e.g. `PCG`) might become the scaling bottleneck. One way to get around this is to agglomerate coarse level matrices onto less or even one processor. This is collects processors' matrices to create a single, larger matrix with all the inter-processor boundaries replaced with internal faces. This is not supported for other boundary types, e.g. cyclicAMI. When used in combination with processor agglomeration these will display an error message when serialising the boundary, e.g.
```
[2] --> FOAM FATAL ERROR:
[2] Not implemented
[2]
[2] From virtual void Foam::cyclicAMIGAMGInterface::write(Foam::Ostream&) const
[2] in file AMIInterpolation/GAMG/interfaces/cyclicAMIGAMGInterface/cyclicAMIGAMGInterface.H at line 160.
[2]
FOAM parallel run aborting
```
## Solution
The handling of boundaries was generalised to all coupled boundaries (e.g. `cyclic`, `cyclicAMI`). All will implement
- writing to / constructing from a stream (i.e. serialisation) to collect all parts of a coupled boundary on the agglomerating processor.
- cloning (on the agglomerating processor) from the received parts. For `cyclicAMI` this involves assembling the local face-to-cell addressing from the individual parts and adapting the stencils accordingly. (see below)
## Effect
A case with two 20x10x1 blocks coupled through `cyclicAMI` (decomposed into 4) was compared to a single 40x10x1 block (so using processor boundaries) using the `masterCoarsest` processor agglomeration (output from running with the `-debug-switch GAMGAgglomeration` command line option):
- processor boundaries:
```
nCells nInterfaces
Level nProcs avg max avg max
----- ------ --- --- --- ---
0 4 100 100 1.5 2
1 4 50 50 1.5 2
2 1 100 100 0 0
3 1 48 48 0 0
```
The number of boundaries ('nInterfaces') becomes 0 as all processor faces become internal.
- cyclicAMI boundaries:
```
nCells nInterfaces
Level nProcs avg max avg max
----- ------ --- --- --- ---
0 4 100 100 3 3
1 4 50 50 3 3
2 1 100 100 2 2
3 1 48 48 2 2
```
Here the number of boundaries goes from 3 to 2 since only the two `cyclicAMI` get preserved.
## Distributed cyclicAMI
A big benefit of cyclicAMI is that the source and target faces do not have to reside on the same processor. This is handled internally using a distribution map:
- `AMI.srcMap()` : transfers the source-side data to the target side.
- `AMI.tgtMap()` : transfers the target-side data to the source side.
When assembling the cyclicAMI interface from the various contributing processors a large part is the assembling of the src and tgt maps. Each map consists of local data (myProcNo) followed by data from the various remote (proci != myProcNo) procs:
|index | contents |
|-------------|-----------|
|0 | local |
|localSize | |
| | remote from 0 |
| | remote from 1 |
| | .. |
| | remote from n |
|constructSize| |
The data is constructed by
- starting from the local data
- using the `subMap` to indicate which elements of this local data need to go where
- making additional space to receive remote data
- using the `constructMap` to indicate where the received data slots into
If we start from four processors and combine the processors 0,1 into new 0 and 2,3 into new 1 the assembled layout is agglomerated:
- the local data is the agglomeration of local datas so local data on new0 is old0, old1
- the remote data is sorted according to originating 'new' processor (so new0 agglomerates the data sent to old procs 0,1 from old procs2,3)
- any remote data from assembled processors is removed (since it is now in the assembled local slots)
The two maps indexing the data will be renumbered accordingly. In general most maps will have lots of local data and just a bit of remote (note that this might not be optimal for cyclicAMI purposes since quite likely the two sides get decomposed onto separate processors) so the new numbering is
- startOfLocal[mapi] : gives for `mapi` (assumed to originate from rank `mapi`) the offset in the assembled data
- compactMaps[mapi][index] : gives the `mapi` the new index for every old index
## Notes
- `cyclicAMI` with all faces becoming local will be reset to become non-distributed i.e. directly operating on provided fields without any additional copying.
- `cyclicAMI` with a rotational transformation is not yet supported. This is not a fundamental limitation but requires additional rewriting of the stencils to take into account transformations.
- `processorCyclic` (a `cyclic` with owner and neighbour cells on different processors) is not yet supported. This is treated as a normal processor boundary so will loose any transformation. Note that `processorCyclic` can be avoided by using the `patches` constraint in decomposeParDict, e.g.
```
constraints
{
patches
{
//- Keep owner and neighbour on same processor for faces in patches
// (only makes sense for cyclic patches and cyclicAMI)
type preservePatches;
patches (cyclic);
}
}
```
- only `masterCoarsest` has been tested but the code should support any other processor-agglomeration method.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/644Added Abaqus sampling and writing2023-12-04T12:32:19ZAndrew HeatherAdded Abaqus sampling and writingAdds:
- Abaqus mesh `sampledSet` : `abaqusMesh`
- Abaqus co-ord set writer : `abaqus`
- Added field level/scale from surface writers to co-ord writersAdds:
- Abaqus mesh `sampledSet` : `abaqusMesh`
- Abaqus co-ord set writer : `abaqus`
- Added field level/scale from surface writers to co-ord writersv2312Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/643Draft: INT: introduce demand-driven fvSchemes and fvSolution2023-12-12T11:58:15ZMark OLESENDraft: INT: introduce demand-driven fvSchemes and fvSolution- functionality similar to that introduced by openfoam.org
fvSchemes/fvSolution now demand-driven and accessed by their respective
member functions schemes() and solution().
This means that the corresponding system files ...- functionality similar to that introduced by openfoam.org
fvSchemes/fvSolution now demand-driven and accessed by their respective
member functions schemes() and solution().
This means that the corresponding system files are not required upon
construction (which simplifies initialization) and potentially allows
supporting different file locations (TBD).v2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/642Draft: ENH: shm: blockLevel through ray-shooting2023-11-23T16:33:49ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comDraft: ENH: shm: blockLevel through ray-shooting### Summary
shm uses a `blockLevel` specification to close small gaps. This is not really useful for small features which might reside inside a single cell. Also it can quite easily give errors if the geometry is not sufficiently resolv...### Summary
shm uses a `blockLevel` specification to close small gaps. This is not really useful for small features which might reside inside a single cell. Also it can quite easily give errors if the geometry is not sufficiently resolved enough. In this feature we use a similar ray-shooting method as is used for the `gapLevel` refinement - opposite rays are shot from each (candidate) cell centre and if both hit a 'blockLevel' surface it sees if the cell is to be deleted.
The disadvantage of the method is if the gap is much bigger than the refinement level - the cells in the middle of the gap are never seen as candidates and will not get removed.
### Details of new models (If applicable)
v2206 tutorial `mesh/snappyHexMesh/opposite_walls`:
![v2206_slice](/uploads/d7333940e8e86c8f596d3b7fbe94e547/v2206_slice.png)
With this change:
![v2312_slice](/uploads/5300bfae192386a41ac03d7d5b9daf75/v2312_slice.png)
### Risks
(Possible regressions?)
(Changes to user inputs?)Prashant SonakarPrashant Sonakarhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/641ENH: cyclicACMI: add non-blocking matrix updates.2023-11-27T13:58:05ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: cyclicACMI: add non-blocking matrix updates.Adds cyclicACMI nonblocking matrix update similar to cyclicAMI (#2963). Does not yet do the patchNeighbourField caching (see !628) since this conflicts with the update order for the non-overlap patches.Adds cyclicACMI nonblocking matrix update similar to cyclicAMI (#2963). Does not yet do the patchNeighbourField caching (see !628) since this conflicts with the update order for the non-overlap patches.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/640Extend some Pstream, PstreamBuffers and globalIndex functionality2023-11-20T10:10:51ZMark OLESENExtend some Pstream, PstreamBuffers and globalIndex functionality- extend mpiAllGather to include more standard types
- consolidate and revise PstreamBuffers exchange options. Now possible to request finished sends with NBX, independent of any static configurations
- some more globalIndex queries
- n...- extend mpiAllGather to include more standard types
- consolidate and revise PstreamBuffers exchange options. Now possible to request finished sends with NBX, independent of any static configurations
- some more globalIndex queries
- new copy_unpack functionality for CompactListList, which allows unpacking into existing storage.v2312Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/639ENH: Reduced-order modelling field reconstruction with DMD2023-11-24T19:57:20ZKutalmış BerçinENH: Reduced-order modelling field reconstruction with DMD#### Acknowledgement
OpenCFD would like to acknowledge and thank **Marco Kiewat** for his contributions, elaborate suggestions and help, and critical recommendations. Highly appreciated.
#### Problem
- OpenFOAM currently lacks one of ...#### Acknowledgement
OpenCFD would like to acknowledge and thank **Marco Kiewat** for his contributions, elaborate suggestions and help, and critical recommendations. Highly appreciated.
#### Problem
- OpenFOAM currently lacks one of the key advantages of DMD:
- the capability to generate a field based on given modes and their associated dynamics, without the need for any CFD computations at arbitrary intermediate and/or future time points.
- This functionality would allow users to condense an entire simulation into a few modes and mode dynamics, and subsequently generate fields at any desired time or predict their future states of periodic or pseudo-periodic systems, all without the need for additional CFD analyses.
#### Solution
Implement and verify the method proposed by [Kiewat (2019)](https://mediatum.ub.tum.de/doc/1482652/815436.pdf) to generate time-variant field data from DMD data for a set of specified times.
#### Verification
##### Coarse mesh
![image](/uploads/a00f43670020abb4737a0e37306ea550/image.png)
![coarse](/uploads/000bb2117e883f9ca7cfebeb2c3b7f2c/coarse.mp4)
##### Fine mesh
![image](/uploads/d3e5ba304c0997de719d6eb07dee918b/image.png)
![fine](/uploads/6d1d980ba1a1eb42ba8a8cc79d8d0396/fine.mp4)
#### Discussion
- The quality of results depends on the capabilities of the underlying reduced-order model, and the quality of the input data.
- To improve the reconstruction results, one needs to make sure that modes are correctly extracted from the flow.
- The easiest method to check the quality:
- Inspect the real part of the first mode visually.
- Compare it with the time-mean of the operand decomposed field.
- The real part of the first mode should always look like the time-mean of the operand decomposed field.
- If both fields are dissimilar, expect low quality results from the `createROMfields`.
#### Risks
- No change in existing input/output.
- The tutorial `$FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/cylinder2D` is run for a longer period.
- Also, the parallel `renumberMesh` operation is removed from its existing `Allrun` script.
#### Metadata
- [x] linux64ClangDPInt32Opt (clang15)
- [x] linux64GccDPInt32Opt
- [x] linux64GccSPDPInt64Debug
- [x] Alltest: No new error/No change in existing output
- [x] Test cases: `$FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/cylinder2D`v2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/638ENH: additional handling for global (non-processor) time paths2023-11-08T10:12:30ZMark OLESENENH: additional handling for global (non-processor) time paths- new methods added to IOobject to ease mixed (serial vs parallel)
file locations. Some redirect to Time, others are defined for
IOobject only.
- provide Time::NewGlobalTime factory methods for better accessibility- new methods added to IOobject to ease mixed (serial vs parallel)
file locations. Some redirect to Time, others are defined for
IOobject only.
- provide Time::NewGlobalTime factory methods for better accessibilityMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/637support creation of boundaries/zones from list of entries2023-11-08T10:12:25ZMark OLESENsupport creation of boundaries/zones from list of entries- this makes it easier to split creation into a two-stage process as required
- extend handling for polyBoundaryMeshEntries, faBoundaryMeshEntries
with more functionality. Ensure that these are never registered.
ENH: addition...- this makes it easier to split creation into a two-stage process as required
- extend handling for polyBoundaryMeshEntries, faBoundaryMeshEntries
with more functionality. Ensure that these are never registered.
ENH: addition writeEntry methods for polyBoundaryMesh
- simplifies streaming and collating into other files
ENH: polyMesh rereading - update owner/neighbour header information
- this avoids accidentally reading the "cells" file if the mesh has
been created with NO_READ and then updated
FYI @gregorweissAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/636ENH: simplify calling of decomposition, support CompactListList2023-11-08T19:29:57ZMark OLESENENH: simplify calling of decomposition, support CompactListList- combined most of the unweighted and weighted decomposition routines
such that an empty weight field is treated as uniform weighting.
This allows default parameters and cuts down on the number of
decompose methods.
- for topology...- combined most of the unweighted and weighted decomposition routines
such that an empty weight field is treated as uniform weighting.
This allows default parameters and cuts down on the number of
decompose methods.
- for topology-driven decomposition, it is now possible to pass in the
owner/neighbour connectivity as a CompactListList directly instead
of first creating a labelListList (which was internally repacked into
a CompactListList in many cases).
However, multiLevelDecomp still uses unpacking (to avoid a larger
reworking of code).
- support direct creation of some methods (eg, random, scotch etc)
without a dictionary
- fix incorrect neighbour face weighting (fixes #3019)
ENH: relocate calcCellCells from decompositionMethod to globalMeshData
- makes it more universally availableAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/635ENH: wall functions: swap the order of switch statements and for loops2023-12-08T11:21:06ZKutalmış BerçinENH: wall functions: swap the order of switch statements and for loopsv2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/634support user specification of ensight time format/precision (#2999)2023-10-19T10:39:09ZMark OLESENsupport user specification of ensight time format/precision (#2999)v2312Andrew HeatherAndrew Heather