openfoam issueshttps://develop.openfoam.com/Development/openfoam/-/issues2022-12-23T14:55:17Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1279fieldToCell does not use lookup; always reads from disk2022-12-23T14:55:17ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfieldToCell does not use lookup; always reads from disk### Functionality to add/problem to solve
fieldToCell currently always reads from disk. Hence it cannot be used in e.g. a functionObject to select some cells during the run (). Would be nice if it would try lookup first instead.
### Pr...### Functionality to add/problem to solve
fieldToCell currently always reads from disk. Hence it cannot be used in e.g. a functionObject to select some cells during the run (). Would be nice if it would try lookup first instead.
### Proposal
- add database lookup first and loading from disk only if that fails
- move fieldToCell to finiteVolume and use proper fields
Example of desired use: plot all cells where the pressure is between 5 and 1000.
```
vtkWrite1
{
type vtkWrite;
libs ("libutilityFunctionObjects.so");
timeStart 10;
writeControl timeStep;
writeInterval 1;
format binary;
legacy false;
decompose false;
fields (p U);
selection
{
threshold
{
action use;
source fieldToCell;
field p;
min 5;
max 1000;
}
}
}
```
There is currently also a bug in that it searches for the last valid p,U instead of loading them from the current time (and failing).v2306Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/3047mapDistribute does not support non-blocking2023-12-09T18:13:44ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commapDistribute does not support non-blocking### Functionality to add/problem to solve
mapDistributeBase supports non-blocking / two-stage communication + consumption. This is not mapped through to mapDistribute. This is currently not used (e.g. non-blocking cyclicAMIFvPatchField ...### Functionality to add/problem to solve
mapDistributeBase supports non-blocking / two-stage communication + consumption. This is not mapped through to mapDistribute. This is currently not used (e.g. non-blocking cyclicAMIFvPatchField applies its own transformation). It might be useful if we want to extend e.g. wall distance calculation to use this two-stage process.
### Proposal
Add an send/receive equivalent to mapDistribute to replace the single mapDistributeBase::distribute.https://develop.openfoam.com/Development/openfoam/-/issues/2977solidBodyFvGeometryScheme caches moved state2023-09-13T08:04:46ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsolidBodyFvGeometryScheme caches moved state### Functionality to add/problem to solve
solidBody fvGeometryScheme caches the 'moved' state by default. This upsets e.g. `snappyHexMesh`.
### Target audience
Using solidBody for non-motion applications.
### Proposal
The current s...### Functionality to add/problem to solve
solidBody fvGeometryScheme caches the 'moved' state by default. This upsets e.g. `snappyHexMesh`.
### Target audience
Using solidBody for non-motion applications.
### Proposal
The current set-up assumes that the points that move are always the same (e.g. solid-body rotation). Thus we can eliminate the marking of the changed points. This can be disabled in the fvSchemes setting:
```
geometry
{
type solidBody;
cacheMotion false;
}
```
The marking of the changed points is very fast - it is the marking of affected faces/cells which is the slower one. Maybe this can be optimised.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2969attachDetach has problems2023-08-28T15:17:53ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comattachDetach has problems### Functionality to add/problem to solve
1) attachDetach performs checking on local patch sizes instead of global sizes.
2) e.g. pimpleFoam does not recalculate Uf/Uf.oldTime()
### Target audience
Topo changes.[TJunctionTopoSwitchin...### Functionality to add/problem to solve
1) attachDetach performs checking on local patch sizes instead of global sizes.
2) e.g. pimpleFoam does not recalculate Uf/Uf.oldTime()
### Target audience
Topo changes.[TJunctionTopoSwitching.tgz](/uploads/5e03c41ec9a86f11ae2fcfd3b689521c/TJunctionTopoSwitching.tgz)
potential fix (but recalculates whole flux):
[pimpleFoam.C](/uploads/88cdf41fc969f071247ef705434efb09/pimpleFoam.C)Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2811Excessive 'cacheAgglomeration no;' for moving mesh cases in tutorials2023-06-21T08:50:10ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comExcessive 'cacheAgglomeration no;' for moving mesh cases in tutorials### Functionality to add/problem to solve
The GAMGAgglomeration automatically is deleted at every mesh movement/topo change so there is no need for disabling the `cacheAgglomeration` if
- agglomeration based on geometry only (= default,...### Functionality to add/problem to solve
The GAMGAgglomeration automatically is deleted at every mesh movement/topo change so there is no need for disabling the `cacheAgglomeration` if
- agglomeration based on geometry only (= default, `faceAreaWeight`)
E.g. run `incompressible/pimpleFoam/laminar/mixerVesselAMI2D` case with/without cacheAgglomeration:
```
mpirun -np 4 pimpleFoam -parallel -debug-switch GAMGAgglomeration=1
```
and you'll see that even with caching it still gets recalculated. With caching off it will re-agglomerate for every pressure solution. Note that it is different for matrix based agglomeration - there even multiple invocations of the GAMG might want to use different agglomerations.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2610windAroundBuildings tutorial leaks when used with cellZones2022-10-20T14:28:00ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comwindAroundBuildings tutorial leaks when used with cellZones### Functionality to add/problem to solve
snappyHexMesh leaks through (topologically) closed surfaces. In the `incompressible/simpleFoam/windAroundBuildings` tutorial change the snappyHexMeshDict to mesh the surface as cellZones
```
...### Functionality to add/problem to solve
snappyHexMesh leaks through (topologically) closed surfaces. In the `incompressible/simpleFoam/windAroundBuildings` tutorial change the snappyHexMeshDict to mesh the surface as cellZones
```
refinementSurfaces
{
buildings
{
level (3 3);
patchInfo { type wall; }
faceZone buildings;
cellZone buildings;
cellZoneInside inside;
}
}
```
This will leak out of the marginal triangles. There are some problems with the surface:
- zero-sized edges
- a region with inconsistent orientation (numbering of neighbouring vertices should be opposite)
but the leakage does not seem to be limited to that.
Ideally the intersection / nearest of the surfaces should not look at the disconnected triangles but look at the surface instead so rays can never shoot in between neighbouring triangles.
The current workaround is to increase the geometric tolerance on the triSurfaceMesh ('tolerance').
### Target audience
snappyHexMesh on marginal triangulations
### Proposal
Look into octree intersection/nearest classification. E.g. `treeDataPrimitivePatch<PatchType>::findIntersection`.
### What does success look like, and how can we measure that?
Above tutorial
### Links / references
### FundingMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2584'value' entry in bc not consistent in fvPatchField vs pointPatchField2022-09-24T09:22:30ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com'value' entry in bc not consistent in fvPatchField vs pointPatchField### Functionality to add/problem to solve
There is inconsistency between pointPatchField, fvPatchField:
pointPatchField : use 'value' field if it is there. Look at valueRequired only if it isn't there.
fvPatchField : use 'value' field ...### Functionality to add/problem to solve
There is inconsistency between pointPatchField, fvPatchField:
pointPatchField : use 'value' field if it is there. Look at valueRequired only if it isn't there.
fvPatchField : use 'value' field only if valueRequired flag sethttps://develop.openfoam.com/Development/openfoam/-/issues/2570foamDictionary does not allow wildcards as key2022-08-22T09:58:39ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamDictionary does not allow wildcards as key### Functionality to add/problem to solve
E.g. we want to change the 'type' for multiple patches :
```
foamDictionary 0/U -entry boundaryField/BFAN.*/type -set foo
```
### Target audience
Complex use of foamDictionary.
### Proposal
...### Functionality to add/problem to solve
E.g. we want to change the 'type' for multiple patches :
```
foamDictionary 0/U -entry boundaryField/BFAN.*/type -set foo
```
### Target audience
Complex use of foamDictionary.
### Proposal
Have each entry expanded into multiple keys by default. Optionally disable with `-literalRE` similar to `changeDictionary` so you could add a wildcard entry to a dictionary.
You could have inbetween where we expand some wildcards but not others but that might be overkill.
### What does success look like, and how can we measure that?
See if we can do above replacement.
### Links / references
### Fundinghttps://develop.openfoam.com/Development/openfoam/-/issues/2558faceAgglomerate assumes viewFactorsDict entries are all patch names2022-08-11T13:44:33ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfaceAgglomerate assumes viewFactorsDict entries are all patch names### Functionality to add/problem to solve
The `faceAgglomerate` app reads the `viewFactorsDict` (as does the `viewFactorsGen` app) . It iterates through the entries and checks if any are patch names. This gives big weirdness if e.g. a p...### Functionality to add/problem to solve
The `faceAgglomerate` app reads the `viewFactorsDict` (as does the `viewFactorsGen` app) . It iterates through the entries and checks if any are patch names. This gives big weirdness if e.g. a patch has the same name as one of the settings needed by `viewFactorsGen`.
### Target audience
Users of view factor radiation.
### Proposal
Put the patch information in `viewFactorsDict` in a sub dictionary:
```
writeViewFactorMatrix true;
writeFacesAgglomeration true;
writePatchViewFactors false;
//- Debug option
debug 1;
//- Dump connectivity rays
dumpRays false;
//- Optional per-patch agglomeration if faceAgglomerate is used
patchAgglomeration
{
".*"
{
nFacesInCoarsestLevel 100; // increase to get more radiation patches (coarse faces)
featureAngle 30; // 0: one radiation patch (coarse face) over one cell face
}
}
//- Maximum length for dynamicList. See /applications/utilities/preProcessing/viewFactorsGen/shootRays.H
maxDynListLength 1000000000;
```
### What does success look like, and how can we measure that?
- be backwards compatible
- use the patchAgglomeration subdictionary if it is thereMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2488redistributePar -decompose with inconsistent nProcs2024-01-08T13:36:51ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar -decompose with inconsistent nProcs### Functionality to add/problem to solve
redistributePar -decompose gives illogical error message if the number of procs does not equal the number in the decomposeParDict. E.g. in decomposeParDict:
```
numberOfSubdomains 2;
```
Run wi...### Functionality to add/problem to solve
redistributePar -decompose gives illogical error message if the number of procs does not equal the number in the decomposeParDict. E.g. in decomposeParDict:
```
numberOfSubdomains 2;
```
Run with
```
mpirun -np 4 redistributePar -decompose -parallel
```
Produces output
```
[0] --> FOAM FATAL ERROR: (openfoam-2202 patch=220310)
[0] number of processor directories = 1 is not equal to the number of processors = 4
```
which is not very helpful.https://develop.openfoam.com/Development/openfoam/-/issues/2486controlPoints do not get reconstructed2022-05-25T11:46:07ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcontrolPoints do not get reconstructed### Functionality to add/problem to solve
interfaceTrackingFvMesh writes some control points to a file
"controlPoints"
(as a vectorIOField). This does not get reconstructed (tested with redistributePar -reconstruct on tutorial incomp...### Functionality to add/problem to solve
interfaceTrackingFvMesh writes some control points to a file
"controlPoints"
(as a vectorIOField). This does not get reconstructed (tested with redistributePar -reconstruct on tutorial incompressible/pimpleFoam/laminar/contaminatedDroplet2D)
### Target audience
finiteArea+mesh motion
### Proposal
Make a DimensionedField instead of IOField?
@markhttps://develop.openfoam.com/Development/openfoam/-/issues/2442chtMultiRegionFoam with anistropic diffusivity2023-12-07T05:40:02ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comchtMultiRegionFoam with anistropic diffusivity### Functionality to add/problem to solve
chtMultiRegionFoam/solidFoam supports anisotropic diffusivity. This gets calculated by converting at startup the thermo properties into the coordinate system.
It does not recalculate the proper...### Functionality to add/problem to solve
chtMultiRegionFoam/solidFoam supports anisotropic diffusivity. This gets calculated by converting at startup the thermo properties into the coordinate system.
It does not recalculate the properties
- if the thermo properties change (e.g. temperature varying alpha)
- if the coordinate system changes (e.g. cylindrical coordinate system, pivoting across second axis)
### Target audience
Anyone using cht with changing solid properties.
### Proposal
Two possibilities:
- have option to update/correct coordinate system and update anisotropic diffusivity accordingly
- not cache aniAlphas but calculate it on-the-fly
@mark @Sergiohttps://develop.openfoam.com/Development/openfoam/-/issues/2331snappyHexMesh consistent parallel v.s. serial refinement2022-11-28T15:04:20ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh consistent parallel v.s. serial refinement### Functionality to add/problem to solve
When running snappyHexMesh in parallel it might not give the exact same result as running non-parallel
### Proposal
Run serial and parallel side-by-side. Make sure refinement is exactly the sa...### Functionality to add/problem to solve
When running snappyHexMesh in parallel it might not give the exact same result as running non-parallel
### Proposal
Run serial and parallel side-by-side. Make sure refinement is exactly the same.
E.g. Tutorial `mesh/snappyHexMesh/gap_detection` and have `random` decomposition.
See also https://exchange.openfoam.com/node/1691.
### What does success look like, and how can we measure that?
Better parallel consistent behaviour. There might still be areas which are not exactly the same just due to e.g. the truncation errors in calculating the face- and cell-centres (different point ordering or orientation of face on processor patch, different ordering of faces in cell)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2295swirl bc does not handle cyclic being decomposed2021-12-10T19:57:14ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comswirl bc does not handle cyclic being decomposed### Functionality to add/problem to solve
swirl bc 'sits' on a cyclic patch. However the patch might get decomposed into a processorCyclic (if the owner and neighbour are not on the same processor). This looses the extra physics from th...### Functionality to add/problem to solve
swirl bc 'sits' on a cyclic patch. However the patch might get decomposed into a processorCyclic (if the owner and neighbour are not on the same processor). This looses the extra physics from the swirl/jump bc (since it has zero faces on the original patch). In addition the particular swirlVelocity bc expects at least one local face on the patch to be able to calculate the swirl axis.
### Proposal
Avoid by e.g. having decomposition constraints:
```
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);
}
}
```
Or maybe add constraint override to decomposePar so the bc type is now again swirl instead of processorCyclic. However now this patch might not be present on all processors or at a different index in the patch list.
@Prashant @markhttps://develop.openfoam.com/Development/openfoam/-/issues/2246chtMultiRegionFoam looses heat due to explicit coupling2021-10-27T17:02:48ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comchtMultiRegionFoam looses heat due to explicit coupling### Functionality to add/problem to solve
chtMultiRegionFoam looses heat when evaluating 'mapped' type bcs (e.g. `compressible::turbulentTemperatureRadCoupledMixed`). This is because the owner side evaluates with 'old' neighbour side va...### Functionality to add/problem to solve
chtMultiRegionFoam looses heat when evaluating 'mapped' type bcs (e.g. `compressible::turbulentTemperatureRadCoupledMixed`). This is because the owner side evaluates with 'old' neighbour side values but the neighbour side evaluates with the 'new'
owner side values.
This should instead use a scheme where the owner side also updates the neighbour side patch.
### Target audience
cht on closed domains. See e.g. https://develop.openfoam.com/Development/openfoam/-/blob/develop/applications/test/multiWorld/solidFoam/solid1_solid2 testcase.
Switch off the kappaLayers, switch to transient, switch on the debug flag for the BC so it prints the heat flux for both sides.https://develop.openfoam.com/Development/openfoam/-/issues/2207uniform Field gets output in ascii2021-09-13T09:33:47ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comuniform Field gets output in ascii### Functionality to add/problem to solve
A uniform field gets output as e.g. (see OpenFOAM/fields/Fields/Field/Field.C)
`uniform 123.456;`
The value gets written in ascii in the current precision. Hence any restart is not exact.### Functionality to add/problem to solve
A uniform field gets output as e.g. (see OpenFOAM/fields/Fields/Field/Field.C)
`uniform 123.456;`
The value gets written in ascii in the current precision. Hence any restart is not exact.https://develop.openfoam.com/Development/openfoam/-/issues/2191patchType does not survive operations2021-08-25T10:35:47ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.compatchType does not survive operations### Functionality to add/problem to solve
Override a bc on a constraint patch type (e.g. cyclicAMI) using the `patchType` override. Now do any kind of operation. E.g. run laplacianFoam (calculates&writes fvc::grad). This will e.g. write...### Functionality to add/problem to solve
Override a bc on a constraint patch type (e.g. cyclicAMI) using the `patchType` override. Now do any kind of operation. E.g. run laplacianFoam (calculates&writes fvc::grad). This will e.g. write gradTx which will have again `type cyclicAMI`. We might want the default `calculated` instead (so preserve the `patchType` override)
@andy @Prashant @mark
### Proposal
Have additional keyword like `patchType`?https://develop.openfoam.com/Development/openfoam/-/issues/2181multi-world operation : setup2021-08-09T14:52:26ZPrashant Sonakarmulti-world operation : setup### Functionality to add/problem to solve
- Case with some BCs using database (syncObjects) and others not: hangs. Maybe add a check at startup
@mark### Functionality to add/problem to solve
- Case with some BCs using database (syncObjects) and others not: hangs. Maybe add a check at startup
@markhttps://develop.openfoam.com/Development/openfoam/-/issues/2150Feature: CFL number2021-07-06T11:17:28ZPrashant SonakarFeature: CFL numberIt is useful to analyze CFL number for compressible cases which takes acoustic speed into account.
@andyIt is useful to analyze CFL number for compressible cases which takes acoustic speed into account.
@andyhttps://develop.openfoam.com/Development/openfoam/-/issues/2128volFieldValue produces empty lines2021-06-17T16:13:39ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comvolFieldValue produces empty lines### Functionality to add/problem to solve
`volFieldValue::read` prints a newline when it does a read (even though it prints nothing else). This produces unnecessary empty lines at startup.
Run e.g.
`incompressible/pisoFoam/RAS/cavity`
...### Functionality to add/problem to solve
`volFieldValue::read` prints a newline when it does a read (even though it prints nothing else). This produces unnecessary empty lines at startup.
Run e.g.
`incompressible/pisoFoam/RAS/cavity`
and there will be about 20 empty lines from the FOvolFieldValue use of volFieldValue in various permutations.
### Proposal
volFieldValue::read, surfaceFieldValue::read : do not output a line if nothing else has been printed. Or always output at least something?Mark OLESENMark OLESEN