Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-03-01T21:36:07Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2376VTK export specifies binary format but writes ASCII files2022-03-01T21:36:07ZAaronVTK export specifies binary format but writes ASCII filesI noticed the vtk files written by openfoam are quite large - by reading and re-writing from paraview they can be made half the size.
It seems the default format:binary option mentioned in [functionObjects/utilities/vtkWrite.H](https://...I noticed the vtk files written by openfoam are quite large - by reading and re-writing from paraview they can be made half the size.
It seems the default format:binary option mentioned in [functionObjects/utilities/vtkWrite.H](https://develop.openfoam.com/Development/openfoam/blob/OpenFOAM-v2112/src/functionObjects/utilities/vtkWrite/vtkWrite.H) does not work - the resulting files are ASCII. Same for the [vtkSurfaceWriter.H](https://www.openfoam.com/documentation/guides/latest/api/vtkSurfaceWriter_8H_source.html)
This is easy to reproduce, just run the following on the motorbike tutorial.
`postProcess -funcs '(expCl_isoP expCl_wallVtp)'`
[expCl_isoP](/uploads/e2a2f3f81683436252fb53d23b90e0e0/expCl_isoP)
[expCl_wallVtp](/uploads/4b042f77d217611ffe846dc0bfe46adc/expCl_wallVtp)
It would be useful to have binary, compressed files as the files can get quite large for unsteady runs. Reporting as a bug since the source code and documentation suggest this capability is intended to be there already.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2375inconsistency in documentation or implementation using Pstream::maxCommsSize2022-03-16T18:06:04ZMark OLESENinconsistency in documentation or implementation using Pstream::maxCommsSizeby inspection in Pstreams/exchange.C
The number of exchange iterations is calculated with the byte count:
```
nIter = (maxNBytes-1)/Pstream::maxCommsSize+1;
```
but later on in the loop the send sizes per iteration are calculated in th...by inspection in Pstreams/exchange.C
The number of exchange iterations is calculated with the byte count:
```
nIter = (maxNBytes-1)/Pstream::maxCommsSize+1;
```
but later on in the loop the send sizes per iteration are calculated in the element count, not the byte count:
```
nSend[proci] = min
(
Pstream::maxCommsSize,
sendBufs[proci].size()-startSend[proci]
);
// and
charSendBufs[proci] = reinterpret_cast<const char*>
(
&(sendBufs[proci][startSend[proci]])
);
```
I think that requested `Pstream::maxCommsSize` needs to be translated into a maxNumElems, with the appropriate sizeof(T) granularity and that is what should be used.
@Mattijs for comments?Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2374Default for foamToVTK conversion of finiteArea fields2022-03-16T18:01:40ZIan CowanDefault for foamToVTK conversion of finiteArea fields### Summary
When using foamToVTK on the results from a case that includes finiteArea fields (eg $FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/inclinedPlaneFilm), by default the finiteArea fields are not processed. Instead, you need...### Summary
When using foamToVTK on the results from a case that includes finiteArea fields (eg $FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/inclinedPlaneFilm), by default the finiteArea fields are not processed. Instead, you need to apply the -finite-area flag to force them to write. Furthermore, the -finite-area and -surfaceFields flags are not documented in the help blurb for foamToVTK.
### Steps to reproduce / example case
1. run the $FOAM_TUTORIALS/incompressible/pimpleFoam/laminar/inclinedPlaneFilm tutorial.
2. run utility foamToVTK without any parameters.
3. look in the VTK folder ... observe that there's no finite-area data (or just read the foamToVTK output).
4. execute foamToVTK -help and examine the text output.
OpenFOAM version : v2112
Operating system : ubuntu
### Possible fixes
Some quality-of-life improvements:
1. Add a description of the -finite-area flag to the "foamToVTK -help" output. Whilst at it, perhaps document the -surfaceFields flag as well.
2. For consistency with the surfaceFields flag, should this flag not be called "finiteAreaFields"?
3. Lastly, surely the default for foamToVTK should be to write surface and finiteArea fields, if they are present, rather than the user having to request them? Why would you ever want to calculate the fields and then not look at them? Perhaps adjust the logid to write them by default, and then have flags to suppress their output instead?https://develop.openfoam.com/Development/openfoam/-/issues/2373remove additional template on CompactListList2022-03-14T16:18:23ZMark OLESENremove additional template on CompactListListThe `Container` template parameter is only being used from construction from different sublist types (eg, face instead of labelList) and deserializing (with the `operator()`).
Both would be better served with a pack factory method and a...The `Container` template parameter is only being used from construction from different sublist types (eg, face instead of labelList) and deserializing (with the `operator()`).
Both would be better served with a pack factory method and an unpack() method, which would also allow unpacking into different container types from the same compact content.
Partial motivation is reuse for a CSRList type etc.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2372kinematicParcelFoam -postProcess tries to load surfaceFilmProperties always2022-04-13T22:59:02ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comkinematicParcelFoam -postProcess tries to load surfaceFilmProperties always<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
All solvers with kinematic parcels when in `-postProcess` mode try to load `surfaceFilmProperties` even if `surfaceFilmModel none'.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run `tutorials/lagrangian/kinematicParcelFoam/spinningDisk` with
`kinematicParcelFoam -postProcess`
### What is the current *bug* behaviour?
<!-- What actually happens -->
Tries to load surfaceFilmProperties
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Not load anything since is not used.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112
### Possible fixes
`regionModels/surfaceFilmModels/surfaceFilmModel/surfaceFilmModelNew.C` does a `MUST_READ`. Could be `READ_IF_PRESENT`?
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2371apply RIST improvements2022-07-08T10:40:49ZMark OLESENapply RIST improvementsVarious improvements noted in EP1829 that warrant integration, but need proper code refactoring and integration.
@taka, @azami @MattijsVarious improvements noted in EP1829 that warrant integration, but need proper code refactoring and integration.
@taka, @azami @MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2370atmTurb.HeatFluxTemp. with buo.Bouss.PimpleFoam raises unallocated autoPtr2022-03-29T11:43:20ZHiroki OnoatmTurb.HeatFluxTemp. with buo.Bouss.PimpleFoam raises unallocated autoPtr<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
buoyantBoussinesqPimpleFOAM crashes when using atmTurbulentHeatFluxTemperature BC.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run a atmForestStability tutorial with SIMPLE->PIMPLE replacement.
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
On the 2nd time loop, solver crashes on executing TEqn.H.
A 1st time step looks fine.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
```
--> FOAM FATAL ERROR: (openfoam-2112)
unallocated autoPtr of type N4Foam9Function1IdEE
From T* Foam::autoPtr<T>::operator->() [with T = Foam::Function1<double>]
in file /home/xxxxx/OpenFOAM/OpenFOAM-v2112/src/OpenFOAM/lnInclude/autoPtrI.H at line 178.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::error::simpleExit(int, bool) at ??:?
#2 Foam::atmTurbulentHeatFluxTemperatureFvPatchScalarField::updateCoeffs() at ??:?
#3 Foam::fvMatrix<double>::fvMatrix(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&, Foam::dimensionSet const&) at ??:?
#4 Foam::tmp<Foam::fvMatrix<double> > Foam::fv::optionList::source<double>(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>&, Foam::word const&, Foam::dimensionSet const&) at ??:?
#5 ? at ??:?
#6 __libc_start_main in /lib64/libc.so.6
#7 ? at ??:?
Aborted (core dump)
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112
- Operating system : Red Hat Enterprise Linux Server release 7.4 (Maipo)
- Hardware info : Xeon cluster
- Compiler : GCC10.3.0 (built in ThirdParty)
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/2368masterUncollated with #include inside decomposeParDict hangs2022-02-24T16:31:22ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commasterUncollated with #include inside decomposeParDict hangs<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
#include a file in the decomposeParDict. Now any parallel run will hang when run with -fileHandler masterUncollated.
See https://exchange.openfoam.com/node/1828
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Any case. See above.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Hangs. Stuck in some gatherList when parsing the dictionary (on the master).
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
decomposeParDict is special - it gets read during startup to read any roots and the number of processors. At this point the dictionary reading is not yet 'set up' so it should disable any parallel communication. The #include statement in the decomposeParDict triggers parallel communication.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2365thermoCoupleProbes tutorial crash2022-06-28T11:01:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comthermoCoupleProbes tutorial crash<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
Tutorial heatTransfer/buoyantPimpleFoam/thermocoupleTestCase crashes
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
foamRunTutorials
### Example case
See above
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
```
-> FOAM FATAL ERROR: (openfoam-2112)
T not found in table. Valid entries: 0()
```
### Relevant logs and/or images
see above
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : >v2112Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2363AMIMethod not restartable2022-02-24T16:31:22ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comAMIMethod not restartable<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
Various AMIMethods do not output their optional inputs.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
E.g. create a blockMeshDict a cyclicAMI
AMIMethod nearestFaceAMI;
maxDistance2 1e-10; // optional max search distance (squared)
run blockMesh and look at the boundary file.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112
@andyMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2362writeDictionary function object with too many disk accesses2022-02-11T19:01:50ZMark OLESENwriteDictionary function object with too many disk accessesNoted in EP1794 when monitoring "controlDict"
Since the writeDictionary is attached to a regionFunctionObject, it will not see objects registered on time. For items that are not registered at all, it needs some improved logic.
@chiaraNoted in EP1794 when monitoring "controlDict"
Since the writeDictionary is attached to a regionFunctionObject, it will not see objects registered on time. For items that are not registered at all, it needs some improved logic.
@chiaraMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2361sample/store fields may cause dimension check error2022-06-24T15:14:55ZMark OLESENsample/store fields may cause dimension check errorIssue raised as EP1826 with surface sampling. The stored fields are dimensioned.
However, it is perhaps possible that the named field changes dimensions (@Chiara?)
In which case,
```
//OLD dimfield->dimensions() = dims;
//NEW
dimfield-...Issue raised as EP1826 with surface sampling. The stored fields are dimensioned.
However, it is perhaps possible that the named field changes dimensions (@Chiara?)
In which case,
```
//OLD dimfield->dimensions() = dims;
//NEW
dimfield->dimensions().reset(dims);
```
in polySurfacesTemplates.CMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2360Bug in activePressureForceBaffleVelocity boundary condition2022-05-06T10:02:50ZTobias HolzmannBug in activePressureForceBaffleVelocity boundary condition<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
The activePressureForceBaffleVelocity boundary condition calculates the pressure difference between the two blocked cyclic patches in a wrong matter if we use a NONE forced-based approach because the weighting area is wrong. The set-up for such a boundary condition is as follows:
- two cyclic patches
- duplicate the two cyclic patches and merged them together to get one patch -> blocking wall
In the updateCoeffs function of the activePressureForceBaffleVelocity condition, we first calculate the force at the cyclic (master) patch and subtract the force at the cyclic (slave) patch. This force difference gets divided by the patch area which is the wall-patch (the wall patch has the master and slave area; so it's double as large as a single cyclic patch). The result is, the BC condition does not open at the user-defined threshold but rather when we reached the doubled delta value.
I found this issue a while ago while creating this case: https://holzmann-cfd.com/community/training-cases/tank-with-safety-valve
; same behavior for the OpenFOAM tutorial: $FOAM_TUTORIALS/combustion/PDRFoam/flamePropagationWithObstacles
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Download either the case I provided on my website or use the tutorial case and check the output of the log -> activation is not given within the specified threshold.
<!-- How one can reproduce the issue - this is very important -->
### Example case
https://holzmann-cfd.com/community/training-cases/tank-with-safety-valve
$FOAM_TUTORIALS/combustion/PDRFoam/flamePropagationWithObstacles
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
Wrong area (division) is used in the calculation of the dp calculation and hence, the BC condition does not switch its behavior when we reach the user-defined threshold.
<!-- What actually happens -->
### What is the expected *correct* behavior?
The condition should switch its behavior after the user-defined threshold is reached.
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2106 and v2112
- Operating system : Ubuntu 21.04
- Hardware info : Not relevant
- Compiler : Not relevant
### Possible fixes
Correct the used area for NONE forced-based calculations.
Patch attached - additionally I added some more information to the output (for transparency reasons)
Code line which is wrong: https://develop.openfoam.com/Development/openfoam/-/blob/master/src/finiteVolume/fields/fvPatchFields/derived/activePressureForceBaffleVelocity/activePressureForceBaffleVelocityFvPatchVectorField.C#L278
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
[0001-BUG-activePressureForceBaffleVelocity-wrong-area-in-.patch](/uploads/68fae4aa17583ff777cd90fb8e46cc73/0001-BUG-activePressureForceBaffleVelocity-wrong-area-in-.patch)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2359singleProcessorFaceSets not working in parallel2022-06-28T11:01:41ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsingleProcessorFaceSets not working in parallel<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
The decomposition constraint 'singleProcessorFaceSets' does not work in combination with `redistributePar`. It works with `decomposePar`. The setup collects all cyclicAMI faces into a faceSet and then uses the constraint to keep all of them on the same processor.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
decomposePar a case. Make sure that e.g. cyclicAMI is distributed (check that multiple processors have faces for the patch e.g. by looking at processorDDD/constant/polyMesh/boundary). Use `topoSet` in parallel to collect the patch faces into a faceSet, e.g. a sample `topoSetDict` to collect the faces in patches `fan*`:
```
actions
(
// Left fan
{
name fanLeftFaceSet;
type faceSet;
action new;
source patchToFace;
patches (fanLeft_master fanLeft_slave);
}
// Right fan
....
}
```
Then add a constraint to the `decomposeParDict`:
```
method ptscotch;
constraints
{
keepCyclicAtOnePatch
{
type singleProcessorFaceSets;
sets
(
(fanLeftFaceSet -1)
(fanRightFaceSet -1)
);
enabled true;
}
}
```
Run
```
mpirun -np DDD redistributePar -parallel
```
and check where the cyclicAMI faces have ended up.
### Example case
Unfortunately a bit too big to attach. Take any case with multiple cyclicAMI and e.g. random decomposition and follow above receipe.
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
Faces are not on a single processor
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Faces/cells point-connected to the faceSet should be on a single processor.
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2112
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2358add min/max/average/size results for probes2022-05-11T09:48:38ZMark OLESENadd min/max/average/size results for probesMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2356checkMesh report AMI coverage on mapped patches2022-06-28T11:03:55ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh report AMI coverage on mapped patches### Functionality to add/problem to solve
When doing explicit coupling (e.g. chtMultiRegionFoam) it uses the 'mappedPatch', 'mappedWall' type patches to store the coupling information. For `AMI` coupling it might be good to know the act...### Functionality to add/problem to solve
When doing explicit coupling (e.g. chtMultiRegionFoam) it uses the 'mappedPatch', 'mappedWall' type patches to store the coupling information. For `AMI` coupling it might be good to know the actual coverage, similar to cyclicAMI. This can be added to checkMesh (which already outputs the weights for cyclicAMI).
### Target audience
Explicit coupling using AMI.
### Proposal
When run with `-allGeometry` also output the weights on the AMI for the mapped patch.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2353ThirdParty documentation inconsistency2022-02-11T19:02:44ZDarrin StephensThirdParty documentation inconsistency
### Summary
The ThirdParty SOURCES.md says that the ADIOS2 version for OpenFOAM-v2112 is 2.7.1. However the version set in
etc/config.sh/adios2 and etc/config.csh/adios2 is still 2.6.0.
### Possible fixes
Update the etc/config.sh/adio...
### Summary
The ThirdParty SOURCES.md says that the ADIOS2 version for OpenFOAM-v2112 is 2.7.1. However the version set in
etc/config.sh/adios2 and etc/config.csh/adios2 is still 2.6.0.
### Possible fixes
Update the etc/config.sh/adios2 and etc/config.sh/adios2 files to use version 2.7.1.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2351FixedList/Pair writeEntry is not opposite of primitiveEntry reading2022-03-04T17:49:31ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comFixedList/Pair writeEntry is not opposite of primitiveEntry reading<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
Write a Pair or FixedList to a binary stream using 'writeEntry' and the result cannot be read as a dictionary.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run attached test app (bit of hack) and it fails with some stream error on the worker processor. Run on e.g. cavity decomposed into two.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
Have specialised writeEntry for FixedList which does not use the << operator (or the write routine) to maintain backwards compatibility but instead outputs 'like a List'.[Test-parallel-communicators.C](/uploads/af137f4bf2e969ad2355ae1f8f3ae353/Test-parallel-communicators.C)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2350Extending the buoyantPimpleFoam solver for LTS support2024-01-11T18:54:54ZTobias HolzmannExtending the buoyantPimpleFoam solver for LTS support### Functionality to add/problem to solve
Implementing the LTS support for buoyantPimpleFoam. I would like to make some test analysis in the HVAC analysis and check, if I can reach a better convergence rather than using SIMPLE(C). In my...### Functionality to add/problem to solve
Implementing the LTS support for buoyantPimpleFoam. I would like to make some test analysis in the HVAC analysis and check, if I can reach a better convergence rather than using SIMPLE(C). In my former company, I used the pseudo-transient method almost all the time for the HVAC analysis. Would be interesting to test as I do have a test case which seems to be quite instable for steady-state algorithms.
### Target audience
Mainly HVAC analysis in terms of convergence optimisation and stability. Some cases seems to behave badly by using the steady-state approach (small convective and larger buoyancy forces).
### Proposal
Simply implement LTS support for buoyantPimpleFoam.
### What does success look like, and how can we measure that?
I would do some HVAC analysis with buoyantSimpleFoam and buoyantPimpleFoam + LTS and compare the results.
### Links / references
See implementation in pimpleFoam
### Funding
Feature exist in pimpleFoamhttps://develop.openfoam.com/Development/openfoam/-/issues/2349untriggered bug with vtk write uniform field in parallel2022-02-11T19:02:55ZMark OLESENuntriggered bug with vtk write uniform field in parallelThe VTK writers writeUniform method uses writeValueParallel (in parallel), which includes
a low-level MPI gather. However the wrapping routine contains an
additional safety check for is_contiguous which is not defined for
various `std::p...The VTK writers writeUniform method uses writeValueParallel (in parallel), which includes
a low-level MPI gather. However the wrapping routine contains an
additional safety check for is_contiguous which is not defined for
various `std::pair<..>` combinations.
Bug is not triggered with current code use, but should be eliminated.Mark OLESENMark OLESEN