Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-04-13T22:59:02Zhttps://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/2369Energy not conserved - a sealed room heated up using buoyantPimpleFoam solver...2022-03-03T20:22:30ZPGEnergy not conserved - a sealed room heated up using buoyantPimpleFoam solver with boussinesq equation of stateThe case is a sealed room with 80W output heat source. The problem I met is that the total enthalpy increase inside the whole room in 1s is 75J. A buoyantPimpleFoam solver with boussinesq equation of state is used for the case.
The set...The case is a sealed room with 80W output heat source. The problem I met is that the total enthalpy increase inside the whole room in 1s is 75J. A buoyantPimpleFoam solver with boussinesq equation of state is used for the case.
The setting of the heat source is to use scalarSemiImplicitSource, which used part of the room air as a cellSet heat source. The code is shown as follow
`
heat1
{
type scalarSemiImplicitSource;
enabled true;
active true;
scalarSemiImplicitSourceCoeffs
{
selectionMode cellSet;
cellSet heat1;
volumeMode absolute;
injectionRateSuSp
{
h
{
Su table
(
(0 80)
);
Sp 0.0;
}
}
}
}
`
To measure the enthalpy increase inside the room, a swak4Foam code is used as follow, where 298.15 is the reference temperature T0, 1000 is the mass heat capacity Cp, and vol() is the volume for each cell.
`
T_volSum_room
{
name T_volSum_room;
type swakExpression;
valueType cellSet;
libs ("libsimpleSwakFunctionObjects.so" );
outputControlMode timeStep;
outputInterval 10;
writeStartTime no;
setName room;
expression "(T-298.15)*1000*vol()*rho";
autoInterpolate true;
accumulations (sum);
verbose true;
}
`
The case folder is in the attachment. To reproduce this issue just simple extract the zip file, entering the folder, execute ./Allrun.
Once the case finishes runing, open the postProcessing/swakExpression_T_volSum_room/0/T_volSum_roomOnce and will see time vs enthalpy, an enthalpy increase rate can be calculated based on that and it is 6-7% less than 80W heat source input.
Regards,
Pu
[sealedRoom.zip](/uploads/3335736471e00521a6d692f28eee2ad0/sealedRoom.zip)
Regard
Puhttps://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/2367mapFields not working with collated file format2022-03-23T17:07:32ZFilippo GiussanimapFields not working with collated file format### Summary
mapFields (serial application) fails to map from parallelSource to parallelTarget if the fileHandler format is collated. On the other hand the same applications works if the fileHandler is uncollated.
### Steps to reproduc...### Summary
mapFields (serial application) fails to map from parallelSource to parallelTarget if the fileHandler format is collated. On the other hand the same applications works if the fileHandler is uncollated.
### Steps to reproduce
I started from the incompressible/simpleFoam/backwardFacingStep2D with the collated specified in the controlDict and decomposed in 8 subdomain using hierarchical decomposition with n (4 2 1) . I run 30 iterations. ( this is my collatedSourceCase)
I then created a copy of this tutorial and only run the same blockMesh and run the decomposition with collated format. (this my collatedTargetCase).
Then inside the folder of the collatedTargetCase I execute the command :
mapFields "path_of_sourceCaseCollated" -mapMethod interpolate -parallelSource -parallelTarget -sourceTime latestTime
I tried with all the available interpolation method but it failed every time in the same way
### What is the current *bug* behaviour?
It fails when It tries to read a block of the targetCollatedCase.
Since the mesh between the 2 cases is exactly the same, so are the meshes of the subdomains since the decomposition is deterministic.
As you may see from the log below, it mapped correctly the first block but then it fails when it tries to map the second block.
This happens because the original target collated file is overwritten so it loses all the info about the other blocks. So, the the next time the program tries to read the target collated field it cannot find the others blocks.
As a proof I suggest to run the example I mentioned and to have a look at the p field collated file and you will notice that the other blocks are missing.
### What is the expected *correct* behaviour?
The original collated target case should be updated when the write happens at the end of each mapping loop. This means that the blocks should be moved and the number of bytes updated. This is probably the most difficult part.
### Relevant logs and/or images
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Source: "/scratch/filippo.giussani/OpenFOAM/openfoam-libraries/run/mapFieldsTest" "sourceCaseCollated"
Target: "/scratch/filippo.giussani/OpenFOAM/openfoam-libraries/run/mapFieldsTest" "targetCaseCollated"
Mapping method: interpolate
Create databases as time
Overriding OptimisationSwitches according to controlDict
fileHandler (unregistered)
maxThreadFileBufferSize 0;
maxMasterFileBufferSize 2e+09;
Overriding fileHandler to collated
I/O : collated [unthreaded] (maxThreadFileBufferSize = 0).
Writing may be slow for large file sizes.
Overriding OptimisationSwitches according to controlDict
fileHandler (unregistered)
maxThreadFileBufferSize 0;
maxMasterFileBufferSize 2e+09;
Source processor 0
Overriding OptimisationSwitches according to controlDict
fileHandler (unregistered)
maxThreadFileBufferSize 0;
maxMasterFileBufferSize 2e+09;
Source time: 30
Target time: 0
mesh size: 2567
Target processor 0
Overriding OptimisationSwitches according to controlDict
fileHandler (unregistered)
maxThreadFileBufferSize 0;
maxMasterFileBufferSize 2e+09;
mesh size: 2567
Mapping fields for time 30
interpolating p
interpolating nut
interpolating k
interpolating omega
interpolating U
Target processor 1
Overriding OptimisationSwitches according to controlDict
fileHandler (unregistered)
maxThreadFileBufferSize 0;
maxMasterFileBufferSize 2e+09;
mesh size: 2567
Mapping fields for time 30
interpolating p
--> FOAM FATAL IO ERROR: (openfoam-2112)
incorrect first token, expected <int>, found on line 25: error
file: processors8/0/p at line 25.
From Foam::Istream& Foam::List<T>::readList(Foam::Istream&) [with T = char]
in file primitives/chars/lists/charList.C at line 103.
FOAM exiting
### Environment information
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112
Operating system : centos 8
Compiler : gcc 8.4.0
### Possible fixes
adding functionality to the decomposedBlockData class to write multiple times on the collated target field without loosing previous informationhttps://develop.openfoam.com/Development/openfoam/-/issues/2366include json in openfoam dictionaries2022-03-03T20:21:56ZHenning Scheuflerinclude json in openfoam dictionaries@mark
@kuti
Hi,
I created a functionEntry that allows embedding jsons in OpenFOAM dicts
https://github.com/HenningScheufler/ofjson
## Usage
```
#json "<case>/test.json";
```
cat test.json:
```json
{
"string": "string",
...@mark
@kuti
Hi,
I created a functionEntry that allows embedding jsons in OpenFOAM dicts
https://github.com/HenningScheufler/ofjson
## Usage
```
#json "<case>/test.json";
```
cat test.json:
```json
{
"string": "string",
"istream": "istream;",
"label": 10,
"scalar": 10.1,
"vector": [1.1, 2.2, 3.3],
"subDict": {
"sub_string": "string",
"sub_istream": "istream;",
"sub_label": 10,
"sub_scalar": 10.1
},
"scalarField": {
"type": "scalarField",
"value": [1.1, 2.2, 3.3, 4.4]
}
}
```
The standard OpenFOAM access patterns apply:
```
{
$string; // would return string
$scalar; // would return 10.1
}
```
Kind Regards,
Henninghttps://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/2364allow overset HOLE cells to be marked to arbitrary shape of fringe, but Cd cu...2023-01-25T09:36:01ZChen Jingleallow overset HOLE cells to be marked to arbitrary shape of fringe, but Cd curve is rougher### Functionality to add/problem to solve
This implemtation is inspire by [louis](https://develop.openfoam.com/Development/openfoam/-/issues/2106), who put the HOLE cells further by n layers (n is set by user). However, this is subjecte...### Functionality to add/problem to solve
This implemtation is inspire by [louis](https://develop.openfoam.com/Development/openfoam/-/issues/2106), who put the HOLE cells further by n layers (n is set by user). However, this is subjected to only the shape of the wall patches. As a better way utilizing the overset features, HOLE cells should be near to the fringe.
### Target audience
To who wants HOLE cells to be perfectly matched the fringe like me.
### Proposal
The code is uploaded to [my github](https://github.com/chancesFOAM/inverseDistanceFringe). Just downald it and test!
### What does success look like, and how can we measure that?
The original results of v2006 marking HOLE cells is like:
![问题图](/uploads/51eb4faf2e7658424fc7717fc2fee47e/问题图.PNG)
In my implementation, the HOLE cells could be marked to arbitrary shape of fringe:
ciecle:
![toTheFringe](/uploads/df92629f512985bd8261ebf0dd9f1a1c/toTheFringe.PNG)
rectangle:
![nPushBack_square](/uploads/304c4ec59a32cc0606d22562ecfebe51/nPushBack_square.PNG)
### Problems at present
When I test it with a cylinder case, the force coefficient result is very rough:
![largeCd](/uploads/0a4434f37002e49be20d570d6dced320/largeCd.PNG)
The same phenomenon occours applying louis's pushFront. However, applying the original version of inverseDistance, the Cd curve is also rough but finer:
![origin](/uploads/08370bed1dae00a5fd822f424acf8caa/origin.PNG)
I don't know why. Any ideas?https://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/2357impossible code in particleDistribution2022-02-08T15:32:13ZMark OLESENimpossible code in particleDistributionby inspection - around line 140 of particleDistribution.C
```
if
(
tagFieldName_ != "none"
&& cloudObr.foundObject<IOField<scalar>>(tagFieldName_)
)
{
// Tag field present - generate distribution per...by inspection - around line 140 of particleDistribution.C
```
if
(
tagFieldName_ != "none"
&& cloudObr.foundObject<IOField<scalar>>(tagFieldName_)
)
{
// Tag field present - generate distribution per tag
const IOField<label>& tag =
cloudObr.lookupObject<IOField<label>>(tagFieldName_);
...
```
It is either ignored by the `if` when the tagFieldName_ is actually a labelField, or runtime error if it was found as a scalarField, but followed by a lookup as a labelField.
Unless I missed something here.https://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/2355Enhancement to chtMultiRegion*Foam with residual controls2022-05-06T11:20:20ZTobias HolzmannEnhancement to chtMultiRegion*Foam with residual controls### Functionality to add/problem to solve
During updating my tutorials on my website, I found that the chtMultiRegionFoam does not support:
- Under-relaxation when we want to make more outer corrections
- And hence, I guess a residual co...### Functionality to add/problem to solve
During updating my tutorials on my website, I found that the chtMultiRegionFoam does not support:
- Under-relaxation when we want to make more outer corrections
- And hence, I guess a residual control for outer-correction loop is not possible either
- Furthermore, the steady-state solver does not has an residual control implemented to leave the SIMPLE loop after all convergence criteria are fulfilled
### Target audience
CHT cases with high stiffness in terms of the fluid-region which might need under-relaxation and outer corrections
### Proposal
Extending the solver to work with outer-loops (fluid-region).
Stuff was already implemented in v8.
### What does success look like, and how can we measure that?
Testing on my gin-tonic case should be sufficient in terms of functionality implementations.
Residual-Control can be checked easily using FOAM tutorials
### Links / references
- chtMultiRegionSimpleFoam residual control
- https://github.com/OpenFOAM/OpenFOAM-dev/commit/f04f5b1563d1bc8d0260674d7582a4c961c407fe#diff-04dd65cb42b8ba9960ffb19da381647e574d20def128fc6a0de50f7e88d04ce2
- https://github.com/OpenFOAM/OpenFOAM-dev/commit/53f0c26cf0212cdd0eeaed58bcfa294b063045b1#diff-04dd65cb42b8ba9960ffb19da381647e574d20def128fc6a0de50f7e88d04ce2
- https://github.com/OpenFOAM/OpenFOAM-dev/commit/50bedbb217fbc4c7a278838f53615e5136e0e5bd#diff-04dd65cb42b8ba9960ffb19da381647e574d20def128fc6a0de50f7e88d04ce2
- https://github.com/OpenFOAM/OpenFOAM-dev/commit/fcb142d64d25e6d643dd08a0f8b5ed8178338989#diff-04dd65cb42b8ba9960ffb19da381647e574d20def128fc6a0de50f7e88d04ce2
- chtMultiRegionFoam convergence implementation; Source-Code v9
### Funding
If you want, I can provide the patch.https://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/2352BUG: redistributePar -reconstruct does not reconstruct processorCyclic2022-02-04T16:51:15ZKutalmış BerçinBUG: redistributePar -reconstruct does not reconstruct processorCyclic### Summary
`redistributePar -reconstruct` fails in a simple case with cyclics that end up on different processsors.
### Steps to reproduce
In the attached case, run `./Allrun-parallel-redistributePar` and inspect `log.redistributePar...### Summary
`redistributePar -reconstruct` fails in a simple case with cyclics that end up on different processsors.
### Steps to reproduce
In the attached case, run `./Allrun-parallel-redistributePar` and inspect `log.redistributePar.reconstruct`: [test-case-redistributePar-reconstruct-03Feb22.zip](/uploads/54819af0c6c6b6ccc608d36cc8e6e559/test-case-redistributePar-reconstruct-03Feb22.zip)
For comparisons, `./Allrun` and `./Allrun-parallel-reconstructPar` can be executed without any error.
### What is the current *bug* behaviour?
Attached logs produced by `FOAM_ABORT=true mpirunDebug -np 4 redistributePar -reconstruct -parallel` where `redistributePar` was compiled with `wmake -debug`: [logs.zip](/uploads/9ea3f34b434abcf3054164466ad437fa/logs.zip)
### Environment information
HEAD = 88b64ab054
opts = linux64ClangDPInt32Opt
The same test case has also failed for versions between v2112-v2006.
FYI: @Mattijs @mark