Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-11-24T12:21:09Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2616AABBTree can recurse indefinitely2022-11-24T12:21:09ZMark OLESENAABBTree can recurse indefinitelySince the AABB boxes overlap, it is possible that after splitting a node there is so much excess that the left/right almost entirely overlap or that the splitting is actually ineffective. In this case need to stop there, otherwise it wil...Since the AABB boxes overlap, it is possible that after splitting a node there is so much excess that the left/right almost entirely overlap or that the splitting is actually ineffective. In this case need to stop there, otherwise it will recurse indefinitely.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2615Wrong radial velocity near the rotating wall (rotatingWallVelocity)2022-10-27T11:44:07ZJinghong SuWrong radial velocity near the rotating wall (rotatingWallVelocity)I am using the type rotatingWallVelocity to simulate taylor-couette flow. Strangely, the radial velocity of the rotating wall is equal to 0, while the cells close to the rotating wall, especially the first layer cells, show abnormal radi...I am using the type rotatingWallVelocity to simulate taylor-couette flow. Strangely, the radial velocity of the rotating wall is equal to 0, while the cells close to the rotating wall, especially the first layer cells, show abnormal radial velocities. In order to observe this phenomenon more clearly, I simulated the case where the inner and outer walls have the same angular velocity. The inlet and outlet are set to be cyclic. The front patch and back patch are set to be empty.
The magnitude of velocity
![image](/uploads/0f7078bbf688b88557c3b30965848655/image.png)
The radial velocity(ur)
![image](/uploads/6afd7c719a5c92133ad1e1fa2767e020/image.png)
The radial velocity(ur) is obtained by codes following:
`dimensionedVector zNormal("zNormal", dimless, vector(0.0, 0.0, 1.0));volVectorField C = mesh.C();
volVectorField xy = (C - zNormal * (C & zNormal));
ur = U & xy / mag(xy);`
The run file is attached below
[rotatingWallVelocity_test.zip](/uploads/e4004366ceb38fae485b6d9253610224/rotatingWallVelocity_test.zip)
OpenFOAM version : v2012
Operating system : centoshttps://develop.openfoam.com/Development/openfoam/-/issues/2614First summand is added twice in integratedNonUniformTable2022-12-21T17:34:48ZMartin BeckerFirst summand is added twice in integratedNonUniformTableIn file
/src/thermophysicalModels/thermophysicalProperties/thermophysicalFunctions/integratedNonUniformTable/integratedNonUniformTableThermophysicalFunction.C
lines 69 and 109 , and same for lines 70 and 127:
The first summand "intf_[i-...In file
/src/thermophysicalModels/thermophysicalProperties/thermophysicalFunctions/integratedNonUniformTable/integratedNonUniformTableThermophysicalFunction.C
lines 69 and 109 , and same for lines 70 and 127:
The first summand "intf_[i-1]" is added twice, once in line 58 and then again in line 87 in the member function intfdT().
Same for intfByTdT.
In OpenFOAM-dev this was just fixed:
https://bugs.openfoam.org/view.php?id=3915Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2613Reconstructing a mesh with a cyclic fixed Jump returns errors.2022-12-23T15:15:14ZNidal SaabReconstructing a mesh with a cyclic fixed Jump returns errors.Whenever I try to reconstruct a case with a fixed jump boundary condition I get the following error. running this with OpenFOAM v8, and v9 works just fine.
Here is the error:
`Create time
Reconstructing fields for mesh region0
Time...Whenever I try to reconstruct a case with a fixed jump boundary condition I get the following error. running this with OpenFOAM v8, and v9 works just fine.
Here is the error:
`Create time
Reconstructing fields for mesh region0
Time = 0.015s
Reconstructing FV fields
Reconstructing volScalarFields
nut
p
--> FOAM FATAL ERROR:
Attempt to cast type processorCyclic to type fixedJump
From function To& Foam::refCast(From&) [with To = const Foam::fixedJumpFvPatchField<double>; From = const Foam::fvPatchField<double>]
in file /home/ubuntu/OpenFOAM/OpenFOAM-10/src/OpenFOAM/lnInclude/typeInfo.H at line 114.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::error::abort() at ??:?
#2 Foam::fixedJumpFvPatchField<double> const& Foam::refCast<Foam::fixedJumpFvPatchField<double> const, Foam::fvPatchField<double> const>(Foam::fvPatchField<double> const&) at ??:?
#3 non-virtual thunk to Foam::fixedJumpFvPatchField<double>::rmap(Foam::fvPatchField<double> const&, Foam::List<int> const&) at ??:?
#4 ? in "/opt/openfoam10/platforms/linux64GccDPInt32Opt/bin/reconstructPar"
#5 ? in "/opt/openfoam10/platforms/linux64GccDPInt32Opt/bin/reconstructPar"
#6 ? in "/opt/openfoam10/platforms/linux64GccDPInt32Opt/bin/reconstructPar"
#7 ? in "/opt/openfoam10/platforms/linux64GccDPInt32Opt/bin/reconstructPar"
#8 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#9 ? in "/opt/openfoam10/platforms/linux64GccDPInt32Opt/bin/reconstructPar"
Aborted (core dumped)
`Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2612distributedTriSurfaceMesh does not like having zero triangles on a processor2022-11-24T12:21:09ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdistributedTriSurfaceMesh does not like having zero triangles on a processor<!--
*** 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 -->
If a small surface gets used as a distributedTriSurfaceMesh it can happen that zero triangles end up on a processor. This upsets the local tree searching since it assumes there is at least on node on the tree.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### 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
-->
[bug.zip](/uploads/51dced42aacaded54abda43b02e0ec4d/bug.zip)
Run decomposePar & parallel snappyHexMesh (see the ./Allrun script). Exits with a sigsegv due to accessing out-of-bounds
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2206
- 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
-->
Avoid local searching if no tree.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2611mirrorMesh not mirroring cellLevel and pointLevel fields2022-10-18T07:59:40Zfranco otaolamirrorMesh not mirroring cellLevel and pointLevel fields<!--
*** 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 mirrorMesh utility, does not mirror cellLevel and pointLevel data generated by snappyHexMesh while meshing. this breaks the possibility of using some tools such as renumberMesh or redistributePar.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Create a mesh using snappyHexMesh, mirror it using mirrorMesh and then try to use renumberMesh the last one will give an error about the size is not equal in cellLevel
### What is the current *bug* behaviour?
<!-- What actually happens -->
the cellLevel and pointLevel are not being mirrored
### What is the expected *correct* behavior?
<!-- What you should see instead -->
the cellLevel and pointLevel should be mirrored and added to each field
### 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.
-->
the error part of the log for renumberMesh for example:
```
[49]
[49]
[49] --> FOAM FATAL IO ERROR: (openfoam-2206)
[49] size 15139 is not equal to the expected length 30278
[49]
[49] file: processor49/0/cellLevel at line 19 to 88.
[49]
[49] From Foam::Field<Type>::Field(const Foam::word&, const Foam::dictionary&, Foam::label) [with Type = double; Foam::label = long int]
[49] in file /local1/openfoam/OpenFOAM-v2206/src/OpenFOAM/lnInclude/Field.C at line 218.
[49]
FOAM parallel run exiting
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2206
- Operating system :centOS
- Hardware info :
- Compiler :precompiled package for redhat
### 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
-->
right now the easy solution, in case that we dont need the cellLevel and pointLevel fields, as for the case of renumberMesh, we can simply delete this fields by for example ```rm -f processor*/0/cellLevels``` nevertheless this fields are necessary in other cases. this issue has been discussed and adressed in the fondation vr (issue 0002712)https://develop.openfoam.com/Development/openfoam/-/issues/2610windAroundBuildings tutorial leaks when used with cellZones2022-10-20T14:28:00ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comwindAroundBuildings tutorial leaks when used with cellZones### Functionality to add/problem to solve
snappyHexMesh leaks through (topologically) closed surfaces. In the `incompressible/simpleFoam/windAroundBuildings` tutorial change the snappyHexMeshDict to mesh the surface as cellZones
```
...### Functionality to add/problem to solve
snappyHexMesh leaks through (topologically) closed surfaces. In the `incompressible/simpleFoam/windAroundBuildings` tutorial change the snappyHexMeshDict to mesh the surface as cellZones
```
refinementSurfaces
{
buildings
{
level (3 3);
patchInfo { type wall; }
faceZone buildings;
cellZone buildings;
cellZoneInside inside;
}
}
```
This will leak out of the marginal triangles. There are some problems with the surface:
- zero-sized edges
- a region with inconsistent orientation (numbering of neighbouring vertices should be opposite)
but the leakage does not seem to be limited to that.
Ideally the intersection / nearest of the surfaces should not look at the disconnected triangles but look at the surface instead so rays can never shoot in between neighbouring triangles.
The current workaround is to increase the geometric tolerance on the triSurfaceMesh ('tolerance').
### Target audience
snappyHexMesh on marginal triangulations
### Proposal
Look into octree intersection/nearest classification. E.g. `treeDataPrimitivePatch<PatchType>::findIntersection`.
### What does success look like, and how can we measure that?
Above tutorial
### Links / references
### FundingMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2609filter/smooth mapped file inputs2023-02-14T14:49:49ZMark OLESENfilter/smooth mapped file inputscross-ref EP1995 !568 !573
Sampling from high resolution onto lower resolution surface adds spatial frequency aliasing.cross-ref EP1995 !568 !573
Sampling from high resolution onto lower resolution surface adds spatial frequency aliasing.v2212Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2608CyclicAMI decomposition2024-02-22T12:00:35Zfranco otaolaCyclicAMI decomposition<!--
*** 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 -->
for some cases where the mesh is highly refinned and the simulation uses cyclicAMI when decomposing the case (while using scotch decomposition), sometimes it breaks sometimes it does not. This has been discussed in cfd-online https://www.cfd-online.com/Forums/openfoam-solving/95697-problem-using-ami-15.html, and have been adressed in the lasts versions of OF to keep the cyclicAMI in same processor, neverthless the randomness of this behavior and that this is not mentionned in the manual of the cyclicAMI is problematic, especially considering that the error that we get (when it is not working) is not at all helpful, as for example, checkMesh gives an error that does not give any leads that the issue is coming from the decomposition of the mesh.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
sadly, I don't have a case where this happens, but I found myself in this case while creating complex meshes (see 15th page first post of the link of cfd-online) with highly refined mesh and that were decomposing the domain with scotch (in around 90 processors), while changing the different refinements I found myself in three different scenarios:
1. the case would run correctly, and the checkMesh will output correct and nice weights for the source and target patches.
2. the case would not run, and the checkMesh will run but will output some cells with 0 weight.
3. the case would not run, and the checkMesh neither, when it arrives to check the weights of the cyclicAMI patches it will simply give an error without any relevant information.
this happened while doing a mesh convergence with a case where sometimes more or less refined will run correctly. Furthermore, in the examples where i found myself in cases 2. and 3., when I created a set of cells using topoSet with the cells of the cyclicAMIs (source and target) and then redistribute the same region using a decomposeDict with
`constraints
{
processors
{
type singleProcessorFaceSets;
sets ((AMI -1));
}
}`
then if it was the 2. case, the weights increased (almost to 0.8 the minimum weights when they were 0) and if it was the 3. case, the checkMesh will run correctly as in case 1. and then the case will run normally.
### 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 -->
### 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 : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :
- 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
-->https://develop.openfoam.com/Development/openfoam/-/issues/2607processorMeshes removeFiles does not remove collated2023-05-30T18:30:40ZMark OLESENprocessorMeshes removeFiles does not remove collatedMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2606CylicAMI incompatible with scaling of mesh2024-01-10T11:09:06Zfranco otaolaCylicAMI incompatible with scaling of mesh<!--
*** 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 -->
Hello,
there is a bug regarding the cyclicAMI patches to be more precise regarding the separationVector (at least I think it commes from that).
if we create a mesh that we assign a pair of cyclicAMI patches source and target, and we check the mesh, where we obtain correct AMI weights, if the we scale the mesh with transformPoints(I would guess that this behavior is the same one for the other transformations) the cyclicAMI breakes completly, even in the checkMesh output we can see that the weights are 0.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
create a mesh with snappyHexMesh
use createPatch to create two cyclicAMI patches that are linked by "transform translational;"
checkMesh to be sure that the AMI weights are correct
scale the mesh using transformPoints -scale 1000
checkMesh again, the AMI weights will explode completly
### 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 -->
the source cyclicAMI patch unlinks from its cyclicAMI target patch after scaling the mesh
### What is the expected *correct* behavior?
<!-- What you should see instead -->
the source and target cyclicAMI patches should stay linked even after doing a transformation of points
### 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 : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :2206
- 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/2605uniformInterpolatedPointPatchVectorField does not work with redistributePar2022-12-23T14:56:22ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comuniformInterpolatedPointPatchVectorField does not work with redistributePar<!--
*** 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 -->
uniformInterpolatedPointPatchVectorField does not work with redistributePar. This is to do with the dictionary constructor forcing evaluation of the boundary condition.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Create a case with uniformInterpolatedPointPatchVectorField. Run redistributePar. It will fail with a FatalError.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2206
- 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
-->
Delay searching for times until they are actually needed.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2604Dynamic code not works with openfoam 2206 on wsl2 ubuntu 22.04.12022-11-03T10:30:51ZDong Huy QuangDynamic code not works with openfoam 2206 on wsl2 ubuntu 22.04.1<!--
*** 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 -->
I'm using WSL2 for running ubuntu 22.04.1 on my win 10 desktop. After the installation of openfoam2206, i've done some test and all the tutorials with Dynamic code did not work.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
By example with the tutorial "multiphase/overInterDyMFoam/twoSimpleRotors".
<!--
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 -->
When i run the tutorial, i had the following error :
Using dynamicCode for functionObject alphaVol at line 92 in "/mnt/d/twoSimpleRotors/system/controlDict.functions.alphaVol"
Could not load "/mnt/d/tCould not load "/mnt/d/twoSimpleRotorCould not load "/mnt/d/twoSimpleRotors/dynwoSimpleRotors/dynamicCode/plaamicCode/platforms/linux64GccDPInt32Opt/lib/libalphaVolumes/dynamicCode/platforms/linux64GccDPInt32Opt/lib/libatforms/linux64GccDPInt32Opt/lib/libalphaVolume_4a024lphaVolume_4a02447a6_4a02447a6 0286e990b3a446b74d59547a60286e990b3a446b74d595c431 3b0286e990b3a446b74d595c4313b159c.so"
/mnt/d/twoSimpleRotors/dynamicCode/platforms/linux64GccDPInt32Opt/lib/libalphaVolume_4a02447a60286e990b3a446b74d595c4313 b159c.so: cannot open shared object file: No such file or directory
159c.so"
/mnt/d/twoSimpleRotors/dynamicCode/platforms/linux64GccDPInt32Opt/lib/libalphaVolume_4a02447a60286e990b3a446b74d595c4313 b159c.so: cannot open shared object file: No such file or directory
c4313b159c.so"
/mnt/d/twoSimpleRotors/dynamicCode/platforms/linux64GccDPInt32Opt/lib/libalphaVolume_4a02447a60286e990b3a446b74d595c4313 b159c.so: cannot open shared object file: No such file or directory
Creating new library in "dynamicCode/alphaVolume/platforms/linux64GccDPInt32Opt/lib/libalphaVolume_4a02447a60286e990b3a446b74d595c4313 b159c.so"
Invoking wmake libso /mnt/d/twoSimpleRotors/dynamicCode/alphaVolume
wmake libso /mnt/d/twoSimpleRotors/dynamicCode/alphaVolume
[HC-2568-1:09302] 2 more processes have sent help message help-btl-vader.txt / cma-permission-denied
[HC-2568-1:09302] Set MCA parameter "orte_base_help_aggregate" to 0 to see all help / error messages
ln: ./lnInclude
dep: functionObjectTemplate.C
Ctoo: functionObjectTemplate.C
link: /mnt/d/twoSimpleRotors/dynamicCode/alphaVolume/../platforms/linux64GccDPInt32Opt/lib/libalphaVolume_4a02447a60286e990b3a446b74d595c4313 b159c.so
### 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 : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :
- 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
-->
Hello!
For some reasons, the "make" has not been done successfully. Did i miss something during the installation?
Just one thing : when i followed the instalaltion steps for ubuntu on openfoam.com, the command "curl -s https://dl.openfoam.com/add-debian-repo.sh | sudo bash" dit not work well ( i've installed the certificate with these commands :
sudo apt-get install ca-certificates
sudo apt-get update ) and i have always the error E: could not locate package after the command :
sudo apt-get install openfoam2206-default
To get over the signing, i've forced the update :
sudo apt-get --allow-unauthenticated update
the installation was then done. It might be the source of my problem. Could you please confirm that the dynamic code work with wsl2 ubuntu?
Many thanks!!!https://develop.openfoam.com/Development/openfoam/-/issues/2601Visual Studio Code (IntelliSense) Integration2022-11-07T19:20:13ZDmitrii TuryginVisual Studio Code (IntelliSense) Integration### Functionality to add/problem to solve
There are no good instructions on how to use IntelliSense in VS Code to work properly with OpenFOAM source code. By "work properly" I mean code completion and suggestions. I was able to hack som...### Functionality to add/problem to solve
There are no good instructions on how to use IntelliSense in VS Code to work properly with OpenFOAM source code. By "work properly" I mean code completion and suggestions. I was able to hack something together for OpenFOAM 2.1.1 by simply adding the src directory into include path. I have failed to do the same for OpenFOAM v1706. I get a lot of "incomplete class type is not allowed" which signals that it is probably an include path issue. From my limited understanding I get that OpenFOAM has a complicated code base and IntelliSense needs a little help making sense of it.
### Target audience
Every researcher who develops code for OpenFOAM.
### Proposal
Could you please release the instructions on how to make IntelliSense in VS code to work with OpenFOAM (c_cpp_properties.json, settings.json, etc.) by adding it to your wiki? I do not think that OpenFOAM is being developed in notepad, meaning that there is definitely a way to make this work! :-)
Maybe you are using something other than VS Code internally. That would also work.
### What does success look like, and how can we measure that?
Should be self-explanatory.
### Links / references
There are many guides like [this one](https://github.com/Rvadrabade/Debugging-OpenFOAM-with-Visual-Studio-Code) which switch IntelliSense into Tag parsing mode, which defeats the whole purpose of using IntelliSense in the first place.
### Funding
Should be self-explanatory.https://develop.openfoam.com/Development/openfoam/-/issues/2600snappyHexMesh does maintains excessive buffer layer before removing unreachab...2022-12-23T15:04:20ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh does maintains excessive buffer layer before removing unreachable part<!--
*** 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 does maintains excessive buffer layer before removing unreachable part. It first refines all up to the surface refinement level and then walks from the locations in mesh to remove the unreachable part (+ 1 layer of buffer cells). After that it does any shell refinement to avoid refining unnecessary. The 1 layer of buffer cells include all the boundary cells, even the far-away ones.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
[iglooWithFridges.tgz](/uploads/054c02bee3f26d03bb36a72bac9f3758/iglooWithFridges.tgz)
Run and check the steps. It should only maintain the half sphere + 1 layer of cells. At some point it selects all boundary cells.
### 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 -->
### 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 : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2106
- 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
-->
[meshRefinementBaffles.C](/uploads/516bab492c3f0b993d4c379bbbe88896/meshRefinementBaffles.C)
@PrashantMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2599BUG: snappyHexMesh: tutorial failures due to the minEdgeLength changes2022-09-29T13:20:58ZKutalmış BerçinBUG: snappyHexMesh: tutorial failures due to the minEdgeLength changesf276366a050 leads to failures in the following tutorials in the `Alltest` mode:
```
Application porousSimpleFoam - case incompressible/porousSimpleFoam/straightDuctImplicit: unconfirmed completion
Application snappyHexMesh - case mesh/s...f276366a050 leads to failures in the following tutorials in the `Alltest` mode:
```
Application porousSimpleFoam - case incompressible/porousSimpleFoam/straightDuctImplicit: unconfirmed completion
Application snappyHexMesh - case mesh/snappyHexMesh/addLayersToFaceZone: unconfirmed completion
```
Confirmed that removing f276366a050 fixes the issues.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2598binModels, force etc have questionable handling of coordinate systems2024-01-10T12:57:09ZMark OLESENbinModels, force etc have questionable handling of coordinate systemsThey expect either a `CofR` entry or a `coordinateSystem` entry. If neither exist, they fallback to using `coordinateSystem(const dictionary&)` construction which then requires the following:
- origin (mandatory)
- rotation (optional)
...They expect either a `CofR` entry or a `coordinateSystem` entry. If neither exist, they fallback to using `coordinateSystem(const dictionary&)` construction which then requires the following:
- origin (mandatory)
- rotation (optional)
If `rotation` is missing, it reverts to using the e3/e1 axis specifications. If these are also missing, will fail to construct.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2597snappyHexMesh gets stuck at "Setting refinement level of surface to be consis...2022-09-29T12:49:52ZNikola MajksnersnappyHexMesh gets stuck at "Setting refinement level of surface to be consistent with shells."### Summary
I have noticed an issue where snappyHexMesh can take a very long time or even get stuck on the refinement phase.
This seems to happen when parts of the geometry are highly detailed and very small relative to the overall geom...### Summary
I have noticed an issue where snappyHexMesh can take a very long time or even get stuck on the refinement phase.
This seems to happen when parts of the geometry are highly detailed and very small relative to the overall geometry.
In such cases, snappyHexMesh will spend a lot of time on the step "Setting refinement level of surface to be consistent with shells."
It's not just the matter of number of faces. I have run simulations on STL file which were 20x larger in terms of number of faces and file size compared to the attached case without any issues at all.
### Steps to reproduce
Run the attached case
### Example case
The link below is the motorBike tutorial, with the geometry replaced by a problematic one.
https://drive.google.com/file/d/1WnyoL7RfQSrFZoLoe1yfAhu7qTmQCPNP/view?usp=sharing
The geometry is a simple box of 1 m with a detailed sphere of 1 mm radius inside. The top of the box is open.
### What is the current *bug* behaviour?
snappyHexMesh gets stuck at "Setting refinement level of surface to be consistent with shells." and it can take hours to complete, if at all. I had a case where it took 16 hours, and it was not finished, I had to kill it.
### What is the expected *correct* behavior?
snappyHexMesh not getting stuck at "Setting refinement level of surface to be consistent with shells."
### Environment information
- OpenFOAM version : v2206|v2112|v2106
- Operating system : ubuntu 22.04
- Hardware info : AMD Epyc with 24 cores
- Compiler : Installed with apt-get
### Possible fixes
https://develop.openfoam.com/Development/openfoam/-/blob/master/applications/utilities/mesh/generation/snappyHexMesh/snappyHexMesh.C#L1212
Commenting line 1212 will fix the issue, but I'm not sure if there are any consequences for the quality of the mesh. After visual inspection, the mesh looked good.https://develop.openfoam.com/Development/openfoam/-/issues/2595FPE in snappyHexMesh : motorBike2024-03-19T15:07:40ZPawan GhildiyalFPE in snappyHexMesh : motorBikeHello,
OpenFOAM-v2206
Machine : AMD
Compiler : AMD
**64 bit and 32 label**
**wmake -show-cxx**
-std=c++14 -m64 -pthread -DOPENFOAM=2206 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unu...Hello,
OpenFOAM-v2206
Machine : AMD
Compiler : AMD
**64 bit and 32 label**
**wmake -show-cxx**
-std=c++14 -m64 -pthread -DOPENFOAM=2206 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter
-Wno-invalid-offsetof -Wno-undefined-var-template -Wno-unknown-warning-option -O3 -DNoRepository -ftemplate-depth-100 -march=znver3 -fPIC
_snappyHexMesh crashes with FPE error(motorBike case ). However it works if we set FOAM_SIGFPE as false. Same with streamlines FO in the tutorial (pitzDaily)_
If we remove this option -march=znver3 (AMD optimisation flag, similar to AVX in intel), then case works without issue and also no need to set FOAM_SIGFPE as false
Attaching the snappyHexMesh.log file which fail showing sig fault. [log.snappyHexMesh](/uploads/551185948652dbc412b67c21fd92062c/log.snappyHexMesh) fault.https://develop.openfoam.com/Development/openfoam/-/issues/2594useImplicit in chtMultiRegionFoam where temperature equation exists2022-09-29T13:23:23Zt RockuseImplicit in chtMultiRegionFoam where temperature equation exists### Functionality to add/problem to solve
I have ported `compressibleInterFoam` into the fluid section of `chtMultiRegionFoam` to have a two-phase VoF solver with conjugated heat transfer.
The solver will work with explicit boundary cou...### Functionality to add/problem to solve
I have ported `compressibleInterFoam` into the fluid section of `chtMultiRegionFoam` to have a two-phase VoF solver with conjugated heat transfer.
The solver will work with explicit boundary coupling. However, it would be nice to have the `useImplicit` feature available when working with `T` instead of `he`.
Is there any reason for restring the use of implicit coupling to the `he` field?
### Target audience
All people interested in using `TEqn` for conjugated heat transfer instead of `EEqn`
### Proposal
(How are we going to solve the problem?)
Since boundary conditions are specified for the temperature field, solve for T on the background and allow the direct use of TEqn in the coupled approach?