openfoam issueshttps://develop.openfoam.com/Development/openfoam/-/issues2024-03-27T10:33:08Zhttps://develop.openfoam.com/Development/openfoam/-/issues/3126cellZoneSet does not allow 'set' input2024-03-27T10:33:08ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcellZoneSet does not allow 'set' input<!--
*** 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 -->
`cellZoneSet` does not support `set` input. This was introduced in merge request !674.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
E.g. in topoSet:
```
{
name c1;
type cellZoneSet;
action new;
source cellToCell;
set c0;
}
```
### What is the current *bug* behaviour?
Crash casting c0 to a cellZoneSet
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2312|v2306|v2212|v2206|v2112 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : >2312
### 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
-->
Generalise the *ZoneSet routines to add a topoSet.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/3118snappyHexMesh with cyclic BC: Had *** baffles to create but encountered *** ...2024-03-28T16:19:06ZGuanyang XuesnappyHexMesh with cyclic BC: Had *** baffles to create but encountered *** slave faces originating from patcheable faces.### Summary
Triggered this bug when trying to mesh a 3-directional cyclic base mesh. I DID NOT use parallel meshing (I know a lot of bugs are related to this). Tried to Google but can't find any similar cases.
### Steps to reproduce
I'...### Summary
Triggered this bug when trying to mesh a 3-directional cyclic base mesh. I DID NOT use parallel meshing (I know a lot of bugs are related to this). Tried to Google but can't find any similar cases.
### Steps to reproduce
I'm attaching a minimal case to reproduce. `meshwall.sh` uses `wall` for all 6 faces and can run successfully. But if you run `meshcyclic.sh` and start from a 3-directional cyclic base mesh, this bug will happen.
### Example case
Should take 1min to run. (Uploaded 2nd version for multiregion meshing)
[snappyHexMesh.zip](/uploads/84aa4dfa68c65d22b8c553170f55b60f/snappyHexMesh.zip)
### What is the current *bug* behaviour?
See logs.
### What is the expected *correct* behavior?
`snappyHexMesh` should support cyclic when meshing in serial based on other bug reports, right?
### Relevant logs and/or images
```
--> FOAM FATAL ERROR: (openfoam-2312)
Had 58069 baffles to create but encountered 56363 slave faces originating from patcheable faces.
From Foam::autoPtr<Foam::mapPolyMesh> Foam::meshRefinement::createZoneBaffles(const labelList &, List<labelPair> &, labelList &)
in file meshRefinement/meshRefinementBaffles.C at line 894.
FOAM aborting
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2312|v2306|v2212|v2206|v2112 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2312
- Operating system : ubuntu
- Hardware info : AMD
- Compiler : aocc
### Possible fixes
Tried to remove line 892-899 in `meshRefinementBaffles.C`. It can generate a mesh, but not properly snapped to the feature and generated extra triangles on the boundary patch. So the problem is from somewhere else.https://develop.openfoam.com/Development/openfoam/-/issues/3115interFaceHeight not writing header information2024-03-12T07:45:18ZGuillén Campaña AlonsointerFaceHeight not writing header informationThe functionObject interfaceHeight does not write the header information.
To solve it the following lines should be added to the constructor:
if (Pstream::master())
{
writeFileHeader(fileID::heightFile);
writeFi...The functionObject interfaceHeight does not write the header information.
To solve it the following lines should be added to the constructor:
if (Pstream::master())
{
writeFileHeader(fileID::heightFile);
writeFileHeader(fileID::positionFile);
}Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/3113meshShrinker and displacementMotionSolver motorbike tutorial documentation - ...2024-03-14T13:32:50ZJohnny JonesmeshShrinker and displacementMotionSolver motorbike tutorial documentation - details not foundHi there,
The meshShrinker displacementMotionSolver examples on the following page clearly show the 16 layers on a complex geometry but none of the tutorials they point to include this geometry and I have not been able to replicate it.
...Hi there,
The meshShrinker displacementMotionSolver examples on the following page clearly show the 16 layers on a complex geometry but none of the tutorials they point to include this geometry and I have not been able to replicate it.
https://www.openfoam.com/news/main-news/openfoam-v2312/pre-processing#snappy_layers
Can you please let me know where I can find the working snappyHexMesh file that enabled this motorbike mesh using the displacementMotionSolver.
Thanks!
JJhttps://develop.openfoam.com/Development/openfoam/-/issues/3106snappyHexMesh parallel feature attraction2024-02-22T16:08:39ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh parallel feature attraction<!--
*** 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 -->
snappyHexMesh is not parallel consistent
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Not sure. Visual inspection of code.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Ideally same behaviour parallel/non-parallel
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2312|v2306|v2212|v2206|v2112 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2312
- Operating system :
- Hardware info :
- Compiler :
### 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
-->
Use mesh faces to access mesh face informationMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/3105redistributePar (with cyclicAMI) to more processors2024-03-18T12:15:41ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar (with cyclicAMI) to more processors<!--
*** 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 -->
Changing decomposeParDict to be more processors and running `redistributePar -parallel` hangs.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
```
cd tutorials/incompressible/pimpleFoam/laminar/mixerVesselAMI2D/mixerVesselAMI2D
decomposePar (into e.g. 4 processors)
```
In `system/controlDict` change to `startFrom latestTime` and `stopAt writeNow`. Change decomposeParDict to use more processors (e.g. 8) and `mpirun -np 8 redistributePar -parallel`. This hangs - processors that already have mesh get stuck in `Foam::fvMesh::init`. Processors that are new get stuck in earlier code:
```
15 0x00007f2c1eecb930 in Foam::IOobject::readAndCheckHeader(bool, Foam::word const&, bool, bool, bool) () from develop/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so
#16 0x00007f2c215fae69 in Foam::fvMesh::init(bool) () from develop/platforms/linux64GccDPInt32Opt/lib/libfiniteV
```
### 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?
See above.
<!-- What actually happens -->
### What is the expected *correct* behavior?
Write redistributed mesh to new time directory, including on the new processors.
<!-- 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 : v2312|v2306|v2212|v2206|v2112 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2312
- Operating system :
- Hardware info :
- Compiler :
### 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
-->
@markhttps://develop.openfoam.com/Development/openfoam/-/issues/3093Restart of lagrangian particles fails for reactingParcelFoam dependent on dom...2024-01-29T07:45:01ZUwe JanoskeRestart of lagrangian particles fails for reactingParcelFoam dependent on domain decomposition**Case particles impining on cube:**
Particles are impinging on a cube and form a liquid film with the solver reactingParcelFoam (V22/12).
The duration of the spray is 1000 s. The simulation (on single processor) shows the impingment and...**Case particles impining on cube:**
Particles are impinging on a cube and form a liquid film with the solver reactingParcelFoam (V22/12).
The duration of the spray is 1000 s. The simulation (on single processor) shows the impingment and the formation of a film and after approx. 1.5 the re-entrainment of particles back in the flow. The simulation is splitted in two simulations 0-1s and 1-2s which is a restart of the results for 1s (starting from latestTime).
The results show (see massfilm.jpg) different results based on single / parallel simulation:
- single processor: Mass of film increases after the restart (which was expected)
- 4 proc. (simple 4/1/1) which is a distribution where the particle positons for the injection in reactingCloudProperties are on one processor shows the same results, like on a single processor. The mass of film increases after the restart
- 4 proc. (simple 1/2/2) which is a distribution where the particle injection positions are not on one procesor fails. After the restart no particles are injected and the mass drops.
![massfilm](/uploads/842fe65009eb81231dfca4e2b4599866/massfilm.jpg)
This is a reproducible behaviour for the steps
1. Use endtime = 1 s in controlDict. Run reactingParcelFoam > log1
2. Change endtime = 2 s in controlDict. Run reactingParcelFoam > log2
3. Evaluate result: cat log1 log2 > log
4. ./auswert_particles and look at the mass in the system
This can be run for three different cases, single, parallel (1/2/2) and parallel (4/1/1) distribution in simple decomposition.
Summary:
I.e. dependent on domain decomposition the restart works or works not.
### Testcase
[testcase_cube.tar.gz](/uploads/51ff3d806fe99e599e02b7407b53a230/testcase_cube.tar.gz)
### Environment information
OpenFOAM version : v2212
Operating system : ubuntu
Hardware info : different systems
Compiler : gcc
### Possible fixes
If one removes uniform directory in processor?/1 in all directories and sets start of injection SOI in reactingCloudProperties equal 1 the particles seem to be calculated again independent on decompositionhttps://develop.openfoam.com/Development/openfoam/-/issues/3092MPI_Send MPI_ERR_COUNT: invalid count argument 140 million cells (bug)2024-01-29T18:57:45ZIlya ElizarovMPI_Send MPI_ERR_COUNT: invalid count argument 140 million cells (bug)### Summary
I have encountered a problem with MPI_Send routine while running a 140 million cells case on the cluster: Virgo cluster at GSI Helmholtz Centre for Heavy Ion Research https://hpc.gsi.de/virgo/
I'm using chtMultiRegionSimple...### Summary
I have encountered a problem with MPI_Send routine while running a 140 million cells case on the cluster: Virgo cluster at GSI Helmholtz Centre for Heavy Ion Research https://hpc.gsi.de/virgo/
I'm using chtMultiRegionSimpleFoam to solve a heat transfer problem for a multilayer PCB with vias in great detail. The solver goes through a few regions with no problem, but when it proceeds to a very big region with 141 211 296 cells, it crashes with the error below.
I have tried to increase number of subdomains, e.g. 1024, 2048, 4096 CPUs (all hierarchical method) and 1024 (with ptscotch), but the error persists. This makes me think, that the error is caused by the absolute number of cells in the region and independent of decomposition. A few more things were tried as a solution, but with no success: https://www.cfd-online.com/Forums/openfoam-solving/253681-mpi_send-mpi_err_count-invalid-count-argument.html
### Steps to reproduce
Basically, any solver with with comparable mesh size case should fail. Surely, to run such a case, a lot of computational resources are required that's why it's difficult to reproduce.
Feel free to contact me if you need more details on the Virgo cluster that I'm using. Meanwhile, I will ask OpenFOAM community if anybody could test it on a cluster with comparable size.
### Example case
My case can be found at https://sf.gsi.de/f/4db522c9b39b4125855f/?dl=1 (24,2 Mb)
_Requirements: 1024 CPUs (it's with multithreading), 4 Gb RAM per processor, Slurm workload manager, OpenFOAM installed with WM_LABEL_SIZE=64_
Simply run ./Allrun script
The case uses collated file format.
### What is the current _bug_ behaviour?
It seems that MPI_Send is called with a negative count argument. The count argument is a signed int https://www.open-mpi.org/doc/v4.1/man3/MPI_Send.3.php of 32 bit size, so it is likely overflowing (MPI_Send with a count \> INT_MAX).
### What is the expected _correct_ behavior?
Basically, the solver should proceed with the very big region if there's no hardware limitations like in this situation.
### Relevant logs and/or images
chtMultiRegionSimpleFoam fails with the following error message:
```plaintext
<...>
[lxbk1164:3797445] *** An error occurred in MPI_Send
[lxbk1164:3797445] *** reported by process [710282087,0]
[lxbk1164:3797445] *** on communicator MPI_COMM_WORLD
[lxbk1164:3797445] *** MPI_ERR_COUNT: invalid count argument
[lxbk1164:3797445] *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort,
[lxbk1164:3797445] *** and potentially your MPI job)
slurmstepd: error: *** STEP 19265579.0 ON lxbk1164 CANCELLED AT 2024-01-19T18:02:26 ***
srun: Job step aborted: Waiting up to 32 seconds for job step to finish.
<...>
```
Full logs that were generated by the case can be downloaded at https://sf.gsi.de/f/66935ac60645422da948/?dl=1 log.\* files are ordinary logs that OpenFOAM generates, Slurm-\*.out are logs from the workload manager.
### Environment information
- OpenFOAM version : v2306
- Operating system : CentOS-based
- Hardware info : https://hpc.gsi.de/virgo/user-guide/overview/hardware.html
- OpenMPI : 3.1.6, 4.1.2 (from ThirdParty-v2306), 5.0.0 (tried with three of them)
- Slurm: 21.08.8-2
- Compiler : gcc-toolset-13, gcc 10.2.0 (tried with the two)
### Possible fixes
The PStream interface accepts a std::streamsize and implicitely casts it to the int argument on the mpi interfaces, performing a narrowing conversion https://develop.openfoam.com/Development/openfoam/-/blob/master/src/Pstream/mpi/UOPstreamWrite.C#L56
```plaintext
<source>:3:27: error: static assertion failed
3 | static_assert(sizeof(int) == sizeof(std::streamsize));
| ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:3:27: note: the comparison reduces to '(4 == 8)'
```
(from https://godbolt.org/)
OpenFOAM would have plenty of options to deal with this situation by e.g. issuing multiple MPI_Send or choose a larger MPI_Datatype.
P.S. It seems that there's a problem adding a bug label: /label ~bughttps://develop.openfoam.com/Development/openfoam/-/issues/3079cyclicAMI transformation calculation uses a single face2024-01-11T13:28:32ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcyclicAMI transformation calculation uses a single face<!--
*** 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 -->
cyclicAMI transformation calculation uses a single face so can give large errors
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
`incompressible/simpleFoam/pipeCyclic/`
In system/controlDict add:
```
DebugSwitches
{
cyclicAMI 1;
}
writePrecision 16;
```
and run e.g. checkMesh:
```
cyclicAMIPolyPatch::calcTransforms: patch:side2 Specified rotation: n0:(0 0.7071068286895752 -0.7071068286895752) n1:(0 -0.7071068286895752 -0.7071068286895752) swept angle: 90 [deg] reverse transform: (1 0 0 0 0 -1.00000011920929 0 1.00000011920929 0)
patch: side2
forwardT = 1((1 0 0 0 0 1.00000011920929 0 -1.00000011920929 0))
reverseT = 1((1 0 0 0 0 -1.00000011920929 0 1.00000011920929 0))
separation = 0()
collocated = 1(0)
```
The transformation should be close(r) to 1. Also checkMesh gives an open cells warning.
This is independent of #2635 since I replaced the #eval with calculated values in the blockMeshDict.
<!--
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 -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
no warning about open cells
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2312|v2306|v2212|v2206|v2112 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2312
### 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
-->
It currently uses the largest face.
- does it use the opposite face?
- or can it use some average?https://develop.openfoam.com/Development/openfoam/-/issues/3064streamFunction FO message about not finding seed2023-12-20T13:10:09ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comstreamFunction FO message about not finding seed<!--
*** 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 -->
streamFunction FO reports message about not finding starting seed. Investigate. Also indentation of various FOs (see case below) is not consistent.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run `incompressible/pisoFoam/RAS/cavity`
### What is the current *bug* behaviour?
Message about streamFunction not finding seed.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2310https://develop.openfoam.com/Development/openfoam/-/issues/3059Free Stream BC not working with ABL2023-12-19T10:11:10ZRaphael AranhaFree Stream BC not working with ABL<!--
*** 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 freeStream BC is not working properly with atmBoundaryLayerInletVelocity. It is not loading the information of the ABL and only using the value .
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
if you try to run the example in the link https://www.openfoam.com/documentation/guides/latest/api/classFoam_1_1freestreamFvPatchField.html
it will not work, it will request a value and the value will overwrite the ABL profile
<!--
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 -->
### 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.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2306
- Operating system : ubuntu
- Hardware info :
- Compiler :
### 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/3056checkMesh writes fields with 'calculated' also on empty patches2023-12-13T17:10:59ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh writes fields with 'calculated' also on empty patches<!--
*** 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 -->
`checkMesh -writeAllFields` on case with empty writes volFields with 'calculated' on empty patches. E.g. paraview does not like this at all.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
```
cavity tutorial
checkMesh -writeAllFields
```
and look at e.g. `faceWeight` on frontAndBack empty patches.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Probably not override the empty constraint? Or have paraview accept `patchType` override?
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2310https://develop.openfoam.com/Development/openfoam/-/issues/3055snappyHexMesh :: Prediction of maxNewCells wrong with new code2023-12-15T22:25:11ZTobias HolzmannsnappyHexMesh :: Prediction of maxNewCells wrong with new code<!--
*** 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
Hey everybody,
in v2306, the balancing method within snappy was improved based on the code snippet I provided to L2.
https://develop.openfoam.com/Development/openfoam/-/merge_requests/607
The issue appears now due to a one-liner change from Mattijs:
- This line now calculates only zero for the `maxLocalCell` variable, if we first refine and then balance https://develop.openfoam.com/Development/openfoam/-/commit/4a5f542cb431665fc85165e13b29ab1202b99aa3#31acf059fb90704d54379ac0c705eac1a85803dd_2601_2632
- This is related to the fact that this line was introduced by Mattijs to fix the wrong `balance` calculation: https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/mesh/snappyHexMesh/meshRefinement/meshRefinementRefine.C?ref_type=heads#L2762
Hence, the calculation of `maxLocalCells` is wrong (as it is zero all the time and the trigger value will never be taken into account). However, this value is mainly necessary if e.g., locally on one single proc a refinement happens significantly (imagine a refinement based on the surfaceFeatureAngle while using a `level (4 6)` refinement for example.
The discrepancy at the moment is:
- The balancing factor is calculated correctly (in previous versions we were over predicting the nNewCells value due to the fact that the refinement took place alreads)
- On the other hand, the balancing trigger value `maxLocalCells` is zero now (if refineAndBalance is used) and thus, the trigger will not be used anymore
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
To check that the values of `maxLocalCells` are always zero, simply execute snappyHexMesh while having `maxLocalCells 100000000;` to explicitly go step into the `refineAndBalance` function rather than `balanceAndRefine`.
<!-- How one can reproduce the issue - this is very important -->
<!--
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?
Described in the summary.
<!-- What actually happens -->
### What is the expected *correct* behavior?
If we use `refineAndBalance` the `maxLocalCells` should be calculated correctly.
<!-- What you should see instead -->
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->https://develop.openfoam.com/Development/openfoam/-/issues/3041cht solid temperature distribution2023-12-11T19:23:58ZPekkacht solid temperature distribution### Summary
Solid temperature distribution in steady cht solver with mixture models pureZoneMixture and pureMixture leads nonphysical results. The same case by simulated with separated regions give a different results than single region...### Summary
Solid temperature distribution in steady cht solver with mixture models pureZoneMixture and pureMixture leads nonphysical results. The same case by simulated with separated regions give a different results than single region case.
In pureZoneMixture case temperature distribution look that heat goes from lower to higher temperature. In pureMixture case heat flux does not match between regions. Temperature distribution looks logical but temperature levels are much higher that single region case.
![T2](/uploads/7aaa99e1c9251e903504ed2ac6cd0726/T2.png)
### Steps to reproduce
Please find attached cases. By looking heat flux data from log files and temperature distribution is possible notice difference between mixture models.
### Example case
### What is the current _bug_ behaviour?
Results are unreliable
### What is the expected _correct_ behavior?
In pureZoneMixture case temperature distribution can be "fix" by setting the same Cp values to all materials. I think that in solid solver is used alpha instead of kappa in temperature equation.
### Relevant logs and/or images
T fixed wall0 to 300 and wall1 to 400 K. Heat source 10 W in middle of the model. pureZoneMixture heat flux:
```plaintext
min/max/integ(wall0) = -1322.838, -1322.838, -132.2838
min/max/integ(wall1) = 1222.838, 1222.838, 122.2838
```
difference between in and out 10 W and it is OK. Respectively pureMixture case
```plaintext
min/max/integ(wall0) = -114.41282, -114.41282, -11.441282
min/max/integ(z1_to_z2) = 594.6436, 594.6436, 59.46436
min/max/integ(z2_to_z1) = -594.6436, -594.6436, -59.46436
min/max/integ(z2_to_z3) = 2408.3388, 2408.3388, 240.83388
min/max/integ(wall1) = -15889.687, -15889.687, -1588.9687
min/max/integ(z3_to_z2) = -2408.3388, -2408.3388, -240.83388
```
wall0 and wall1 difference is much higher (1588 - 11) than 10 W.
### Environment information
- OpenFOAM version : v2212
- Operating system : AlmaLinux 8
- Hardware info : Intel Core 8
- Compiler : gcc version 8.5.0 20210514 (Red Hat 8.5.0-18) (GCC)
### Possible fixes
\[chtCases.zip\](/uploads/0b33599299701063e04e68c42a50fb47/chtCases.zip
[chtCases.tar.xz](/uploads/12757bc6320abcbbc15e9fded6189f8e/chtCases.tar.xz)Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/3031BUG: multiple mapFields2023-11-21T14:27:42ZKutalmış BerçinBUG: multiple mapFields### Summary
The problem is that, apart from the first 'mapFields' function object, the following 'mapFields' function objects don't appear to be registering the fields they're working on to the correct region. For instance, in the probl...### Summary
The problem is that, apart from the first 'mapFields' function object, the following 'mapFields' function objects don't appear to be registering the fields they're working on to the correct region. For instance, in the problematic case below, the 'mapFields2' function object maps the 'UMean' from 'region0' to 'coarseMesh'. However, the object registry of 'coarseMesh' lacks any 'UMean'.
### Steps to reproduce
[2274-multiple-mapFields-21Nov23-GitLab.zip](/uploads/656e6c1e94ae2143f2373bad13ea4927/2274-multiple-mapFields-21Nov23-GitLab.zip)
### Environment information
api = 2308
HEAD = 0ae6141397
compiler = clang version 15.0.7
mpi = mpirun (Open MPI) 1.10.7.0.5e373bf1fd
OS = openSUSE Leap 15.5
opts = linux64ClangDPInt32Opt
@Mattijshttps://develop.openfoam.com/Development/openfoam/-/issues/3027Evaporation of two liquid phases using icoReactingMultiphaseInterFoam2023-11-16T15:20:51ZMark YEvaporation of two liquid phases using icoReactingMultiphaseInterFoam### Summary
The Solver I used is the icoReactingMultiphaseInterFoam V2306, the Ubuntu version is 20.04.
I try to simulate two different liquid droplets, i.e., liquid1 and liquid2, evaporating to the gas phase. If I set two liquid drop...### Summary
The Solver I used is the icoReactingMultiphaseInterFoam V2306, the Ubuntu version is 20.04.
I try to simulate two different liquid droplets, i.e., liquid1 and liquid2, evaporating to the gas phase. If I set two liquid droplets, the vapor of the liquid, i.e., vapor1, occurs in both two locations, see the picture(the same as vapor2). Physically, vapor1 should occur in location 1 and vapour2 should occur at location 2.
![figure](/uploads/1b20be65014dcb0ad7784a44b6f28dee/figure.png)
I found the code to calculate the massSpeciesTransfer in multiphaseInter::MassTransferPhaseSystem.C. No matter what species is transferred from the liquid phase (liquid1 or liquid2), the value of Su is the same.
The attached is the setting case.[debug.tar.gz](/uploads/83421f905cc567ec6fd5249dac37fee9/debug.tar.gz)https://develop.openfoam.com/Development/openfoam/-/issues/3026rigidBodyMotion linearAxialAngularSpring theta angle appears to be incorrectl...2023-11-16T15:20:33ZChristian RohrrigidBodyMotion linearAxialAngularSpring theta angle appears to be incorrectly signed - spring acts in wrong direction### Summary
Theta angle used in (at least) `linearAxialAngularSpring.C` in the rigidBodyMotion solver appears to be signed incorrectly.
### Steps to reproduce
Apply the linearAxialAngularSpring restraint to a body, and observe it be p...### Summary
Theta angle used in (at least) `linearAxialAngularSpring.C` in the rigidBodyMotion solver appears to be signed incorrectly.
### Steps to reproduce
Apply the linearAxialAngularSpring restraint to a body, and observe it be pulled in the wrong direction. Have tested with pimpleDyMFoam. This has occured on another case which I cannot share, so I have created a new one from one of the tutorials.
Modifying the code for this restraint to ouptut the current angular position shows that the "theta" variable is signed incorrectly. For example a clockwise rotation around the z axis of 45° will be reported as 45° instead of -45°.
### Example case
Attached a case modified from the overset airfoil simpleFoam tutorial. It has been made transient, switched to rigidBody, and a spring constraint has been applied. Increasing the stiffness of this spring exacerbates the movement of the airfoil rather than assisting.
[testCase_axialSpring.zip](/uploads/676fc081bc3e63b66c9376639aa163e3/testCase_axialSpring.zip)
### What is the current _bug_ behaviour?
Spring moment acts in wrong direction.
### What is the expected _correct_ behavior?
A positive rotation should create a negative torque.
### Relevant logs and/or images
In the example case, I have attached a spring at the bottom of the domain to the airfoil with an Rz joint. The spring pulls the airfoil down and to the right, and this is accelerated for higher spring stiffnesses. Some movement in that direction is expected for the aerodynamic load, but it should reduce with increasing stiffness rather than worsen.
The case should be run with a stiffness of 1 and then with a stiffness of 100 to observe the issue.
Alternatively, add an `Info <<` message reporting the theta angle of the airfoil body at line 143 of `linearAxialAngularSpring.C` : it is signed incorrectly for the observed rotations.
![image.png](/uploads/71c2ddc6030e147d4b073b8df15267aa/image.png){width="314" height="299"}
### Environment information
- OpenFOAM version : v2112
- Operating system : WSL - OpenSUSE Leap 15.4
- Hardware info : x86_64
- Compiler : gcc
### Possible fixes
Manual flip to theta's sign on line `112` of `linearAxialAngularSpring.C`. But I have not been able to get to the bottom of why this is incorrectly signed to begin with. Could this just be due to case configuration?https://develop.openfoam.com/Development/openfoam/-/issues/3024compressibleInterFoam crahes when compiled with gcc 11.4.02024-01-19T20:23:54ZChris SesslercompressibleInterFoam crahes when compiled with gcc 11.4.0<!--
*** 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 provided case crashes within the first 5 iterations due to "Negative initial temperature T0" when compiled with gcc 11.4.0. In contrast, when compiled with gcc 9.5.0 this problem doesn't occur.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run the case after initialization with blockMesh and setFields
### 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
-->
[compressibleInterFoam.zip](/uploads/f52c0f14bdf8eb473e1b5916e70af854/compressibleInterFoam.zip)
### What is the current *bug* behaviour?
<!-- What actually happens -->
This problem only arised with 3D cases, a different 2D case ran perfectly
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Compilation with gcc 9.5.0 runs stable
### 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.
-->
<details><summary>Error log</summary>
[1] [0]
[0]
[0] --> FOAM FATAL ERROR: (openfoam-2012)
[0] Negative initial temperature T0: -180.035335774
[0]
[0] From Foam::scalar Foam::species::thermo<Thermo, Type>::T(Foam::scalar, Foam::scalar, Foam::scalar, Foam::scalar (Foam::species::thermo<Thermo, Type>::*)(Foam::scalar, Foam::scalar) const, Foam::scalar (Foam::species::thermo<Thermo, Type>::*)(Foam::scalar, Foam::scalar) const, Foam::scalar (Foam::species::thermo<Thermo, Type>::*)(Foam::scalar) const) const [with Thermo = Foam::hConstThermo<Foam::perfectGas<Foam::specie> >; Type = Foam::sensibleEnthalpy; Foam::scalar = double; Foam::species::thermo<Thermo, Type> = Foam::species::thermo<Foam::hConstThermo<Foam::perfectGas<Foam::specie> >, Foam::sensibleEnthalpy>]
[0] in file /home/itvcs/OpenFOAM/OpenFOAM-v2012/src/thermophysicalModels/specie/lnInclude/thermoI.H at line 57.
</details>
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2012 commit 79e353b84e3e7cace6ea35c6b7570dfd198d0135
- Operating system : Ubuntu 22.04.3 LTS
- Hardware info : Intel 13th gen
- Compiler : gcc 9.5.0 and 11.4.0
### 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/3021Error in application of parallel axis theorem in sixDoFRigidBodyMotion class2023-11-07T09:32:33ZJohan RoenbyError in application of parallel axis theorem in sixDoFRigidBodyMotion classThere is a bug in the application of the parallel axis theorem in the constructor here:
https://develop.openfoam.com/Development/openfoam/-/blob/master/src/sixDoFRigidBodyMotion/sixDoFRigidBodyMotion/sixDoFRigidBodyMotion.C?ref_type=hea...There is a bug in the application of the parallel axis theorem in the constructor here:
https://develop.openfoam.com/Development/openfoam/-/blob/master/src/sixDoFRigidBodyMotion/sixDoFRigidBodyMotion/sixDoFRigidBodyMotion.C?ref_type=heads#L148
where we do `momentOfInertia_ += mass_*diag(I*magSqr(R) - sqr(R));`
The matrix `sqr(R)` is generally not diagonal and by taking diag() of it, we omit its off-diagonal terms, which is an error.
Thus, simulations where the centre of rotation and centre of mass do not coincide must be expected to give wrong results.
The correct behaviour in such simulations should be tested and verified with a simple test case.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/3020momentOfInertia tensor should be symmTensor, not diagTensor in sixDofRigidBod...2023-11-06T20:44:24ZJohan RoenbymomentOfInertia tensor should be symmTensor, not diagTensor in sixDofRigidBodyMotion classThe moment of inertia is a symmetric tensor, not necessarily diagonal.
This should be reflected in its type in the sixDoFRigidBodyMotion class:
https://develop.openfoam.com/Development/openfoam/-/blob/master/src/sixDoFRigidBodyMotion/s...The moment of inertia is a symmetric tensor, not necessarily diagonal.
This should be reflected in its type in the sixDoFRigidBodyMotion class:
https://develop.openfoam.com/Development/openfoam/-/blob/master/src/sixDoFRigidBodyMotion/sixDoFRigidBodyMotion/sixDoFRigidBodyMotion.H#L111
and in how it is specified in the dynamicFvMeshDict in cases using it.
Indeed, for a symmetric matrix (with all eigenvalues non-zero) one can always find an orthogonal basis in which it is diagonal. This basis, however, often does not coincide with the natural coordinate system of a given simulation case.Kutalmış BerçinKutalmış Berçin