Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-08-08T07:31:12Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2096manualInjection fails with sprayFoam2022-08-08T07:31:12ZJairo Andrés GutiérrezmanualInjection fails with sprayFoam<!--
*** 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
sprayFoam fails to run // runs poorly when using a manualInjection atomization.
### Steps to reproduce
Use the tutorial AachenBomb and modify the atomization to manualInjection (inject only 1 parcel)
### Example case
### What is the current *bug* behaviour?
1. Depending on the SOI, the case might either run (erroneously) or fail to run
When it runs, a particle is atomized every time step (but it also disappears). This happens for SOI > initial time.
When it does not run, (this happens for SOI = initial time) it shows the following result:
Selecting BreakupModel none
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in "/lib/x86_64-linux-gnu/libc.so.6"
#3 ? in "/opt/openfoam8/platforms/linux64GccDPInt32Opt/bin/sprayFoam"
#4 ? in "/opt/openfoam8/platforms/linux64GccDPInt32Opt/bin/sprayFoam"
#5 __libc_start_main in "/lib/x86_64-linux-gnu/libc.so.6"
#6 ? in "/opt/openfoam8/platforms/linux64GccDPInt32Opt/bin/sprayFoam"
Floating point exception (core dumped)
### What is the expected *correct* behaviour?
<!-- 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 : 2012 (also observed in OF8)
Operating system : Ubuntu 18.04 LTS
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : OpenFOAM 2012
- Operating system : Ubuntu 18.04
- Hardware info :
- Compiler :
### Possible fixes
This bug was previously reported in OpenFOAM.org (v2.2) and appears as fixed, but I also experienced it today in OFV8. https://bugs.openfoam.org/view.php?id=1241. I'm afraid I don't have time at the moment to go into the code.v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2097BUG: channel395 and turbulentInflow/PCF: wrong length scale input2021-06-09T13:48:19ZKutalmış BerçinBUG: channel395 and turbulentInflow/PCF: wrong length scale 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 -->
In the tutorials of `channel395` and `turbulentInflow/PCF`, the integral-length scale input files (i.e. `constant/boundaryData/inlet/0/L`) involve length-scale values considerably lower (i.e. at least two orders of magnitude) than those indirectly reported in Moser et al. (1999).
In Moser et al., (1999), the integral-length scale information can be computed either by partially integrating the reported x-autocorrelations or by using the relation of k^(3/2)/epsilon on the reported resolved kinetic energy balance.
Both methods yielded similar values for length scales which revealed to be considerably higher in comparison to the length-scale info being used in the aforementioned tutorials.
The content of the available L files were computed by using the `turbulenceFields` function object on a given RANS simulation. This should have yielded comparable length-scale info, yet have not. This should also need to be inspected.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Pending
### 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
-->
Pending
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
api = 2102
patch = 210414
HEAD = 18c1da05fd
version = com
compiler = Clang (system)
= clang version 9.0.1
mpi = SYSTEMOPENMPI
= mpirun (Open MPI) 1.10.7.0.5e373bf1fd
OS = Description: openSUSE Leap 15.1
opts = linux64ClangDPInt32Opt
### 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
-->
Pendingv2106Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2098Bug: MappedFile: merging of entry scopes2021-06-09T13:48:11ZKutalmış BerçinBug: MappedFile: merging of entry scopes<!--
*** 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 a boundary condition, assume there are two MappedFile-object entries: `R` and `L`.
The condition definition could look like as follows:
```
condition
{
type condition;
R
{
type mappedFile;
mapMethod nearest;
}
L
{
type mappedFile;
mapMethod nearest;
}
}
```
However, utilities invoking `MappedFile::writeData`, e.g. `decomposePar`, writes out all the subdictionaries into the same scope:
```
condition
{
type condition;
R mappedFile;
mapMethod nearest;
L mappedFile;
mapMethod nearest;
}
```
The above is problematic because we have multiple `mapMethod` entries within the same scope.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
NA
### 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
-->
NA
### What is the current *bug* behaviour?
<!-- What actually happens -->
NA
### What is the expected *correct* behavior?
<!-- What you should see instead -->
@mark's comment:
> Should probably be writing out RCoeffs { mapMethod ...; } and LCoeffs { ... }
### 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.
-->
NA
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
api = 2102
patch = 210414
HEAD = 739c1c1d61
version = com
compiler = Clang (system)
= clang version 9.0.1
mpi = SYSTEMOPENMPI
= mpirun (Open MPI) 1.10.7.0.5e373bf1fd
OS = Description: openSUSE Leap 15.1
opts = linux64ClangDPInt32Opt
### 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
-->
NA
@Mattijshttps://develop.openfoam.com/Development/openfoam/-/issues/2099multiple world coupling to support AMI2022-12-23T15:02:54ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commultiple world coupling to support AMI### Functionality to add/problem to solve
multiple world coupling to support AMI
Using -world only supports one-to-one patch mapping (nearestPatchFace). It would be nice to support AMI:
```
// What to sample:
sampleMod...### Functionality to add/problem to solve
multiple world coupling to support AMI
Using -world only supports one-to-one patch mapping (nearestPatchFace). It would be nice to support AMI:
```
// What to sample:
sampleMode nearestPatchFaceAMI;
```
### Target audience
Multi-world simulationsMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2100COMP: incGamma: factorial(int&) is ambiguous for int642021-06-09T14:37:43ZKutalmış BerçinCOMP: incGamma: factorial(int&) is ambiguous for int64### Summary
[log.linux64GccDPInt64Opt](/uploads/eaa9df454f443ec583bef0f628fe71e4/log.linux64GccDPInt64Opt)
```
primitives/functions/Math/incGamma.C:260:57: error: call of overloaded ‘factorial(int&)’ is ambiguous
```
### Possible f...### Summary
[log.linux64GccDPInt64Opt](/uploads/eaa9df454f443ec583bef0f628fe71e4/log.linux64GccDPInt64Opt)
```
primitives/functions/Math/incGamma.C:260:57: error: call of overloaded ‘factorial(int&)’ is ambiguous
```
### Possible fixes
[0001-COMP-incGamma-invIncGamma-adjustments-for-int64-2100.patch](/uploads/392ba16cd777e98a7f431245990d3dbd/0001-COMP-incGamma-invIncGamma-adjustments-for-int64-2100.patch)v2106Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2101BUG: atmBoundaryLayerInlet2021-09-16T12:21:53ZJunting ChenBUG: atmBoundaryLayerInlet<!--
*** 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 -->
Every write resets z0 value to 0 on atmBoundaryLayerInlet boundaries
It will create issue when restarting from certain time step. Found this issue in Openfoam v2012.
Junting Chen
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
1. in the 0 directory, use z0 of anything. Can be simplest cases.
2. run this simulation to a time step for example 200.
3. vim into the U file in the latest time stamp
4. You will see z0 on the inlet boundary has been reset to 0.
### 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 : v2012
Operating system : centos (i dont think it matters)
Hardware info : any info that may help?
Compiler : gcc
-->
- OpenFOAM version : v2012
- Operating system : centos (i dont think it matters)
- Hardware info : VM
- Compiler : gcc
### 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
-->v2112Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2104foamMonitor complains when viewing solverinfo.dat files and creates a STDERR ...2023-12-18T15:49:05ZMark YobbfoamMonitor complains when viewing solverinfo.dat files and creates a STDERR stream plus line colors are duplicated<!--
*** 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
foamMonitor complains when viewing solverinfo.dat files when it parses through and hits a solver name or converged column. It continues to do this as it is left running creating a continuous (periodic) STDERR stream to the terminal that you started it from. Additionally the plot generated sometimes places the y crossing coordinate of x at 1. This can result in the 'iter' data being the top line of the graph for example. Another issue is that colors are repeated in the graph so determining which line is which can be really confusing.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Use foamMonitor to view a solverinfo.dat file.
<!-- 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
-->
#foamMonitor -l solverinfo.dat
"/tmp/tmp.aQL9YjCazQ" line 29: warning: Skipping data file with no valid points
"/tmp/tmp.aQL9YjCazQ" line 29: warning: Skipping data file with no valid points
"/tmp/tmp.aQL9YjCazQ" line 29: warning: Skipping data file with no valid points
"/tmp/tmp.aQL9YjCazQ" line 29: warning: Skipping data file with no valid points
"/tmp/tmp.aQL9YjCazQ" line 29: warning: Skipping data file with no valid points
"/tmp/tmp.aQL9YjCazQ" line 29: warning: Skipping data file with no valid points
Notice the duplication of colors. Also notice that the p_rgh iter line is missing. (See the correct graph below.)
![foamMonitor_DuplicateColors](/uploads/75d5d33a2412a986e3542dbe83e50f2b/foamMonitor_DuplicateColors.png)
### What is the current *bug* behaviour?
<!-- What actually happens -->
There is no parsing to remove column data that is not relevant to gnuplot. The column data is parsed into a variable and is then used to construct a temp file that is input to gnuplot. As such bad lines are generated in the temp file that depends on gnuplot rejecting the line (and registering a complaint.) This originally created some confusion for me as I didn't know if this had to do with my results or other.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Ideally foamMonitor would not generate a STDERR stream. Additionally colors should not be repeated on the graphs as this makes it difficult to interpret results. Lastly it should not (in most cases) use the top horizontal line of the graph to place data.
### 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 : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :2012
- Operating system :Debian 10 (Buster)
- Hardware info :AMD Ryzen 9 3900X 12-Core Processor, 64 GB ddr4
- Compiler :g++ 4:8.3.0-1,g++-8 8.3.0-6
### 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
-->
I have created a modification of foamMonitor that I believe addresses these issues. Below is an example gnuplot output:
![foamMonitor_nonDuplicateColors](/uploads/333abe3c4eddba6a55c3b041781c63f6/foamMonitor_nonDuplicateColors.png)
I have changed the gnuplot text size, and line width to make things more legible which is likely a subject of taste. I have also made the default x crossing of the y axis at 10. The color palette is now 20 long so that each column of data is colored differently (at least as much as I could muster with the algorithm I found.) I have parsed out the solver and converged data with a case directive. This gets rid of the STDERR stream. Additionally I have added a startup echo that tells people what data columns are assigned to what colors. I have used the expr command which I know is not compatible with some shells but foamMonitor already was making use of expr. I am attaching a patch to the 2012 version of foamMonitor. I have only tested this with chtMultiRegionSimpleFoam and chtMultiRegionFoam. I don't know if different matrix solvers or different physics solvers structure their logs differently so I don't know if this will work for all cases. Different column headers can easily be added to the cases for parsing only good data to gnuplot. Within the code I have added comments to help identify my changes which may or may not be recommended as a diff makes it obvious but as I am new to software development this is what I thought made sense at the time. I know the comments will have to be modified and removed before any commit is completed (which I would be pleased to do.) Also I added an attribution line when it is run that I am aware is not standard OpenFOAM and I assume there is rules around any attribution.
I would be pleased to continue making any more changes required based on feedback so this is ready for a commit. (Additionally I suspect that gnuplot doesn't really like the '_' so I was contemplating parsing this out to see if this cleans things up a bit more and it seems the legend placement could potentially be optimized which I could spend a bit of time on if people see the value.)
Kind regards,
[foamMonitor.patch](/uploads/a5e67d34bd722ebd8aaf4c2e9ce67009/foamMonitor.patch)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2105Inconsistent foamToVTK -legacy with previous versions2021-05-27T14:20:47ZMatteo MontecchiaInconsistent foamToVTK -legacy with previous versions<!--
*** 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 -->
### Steps to reproduce
Convert any OpenFOAM case using openfoam/1706 first and type the following command:
foamToVTK
then use openfoam/1912 and type:
foamToVTK -legacy
you will see that, in case of a tensor with class volSymmTensorField (e.g. UPrime2Mean), the order of the different tensor components is changed,
before it was:
XX XY XZ YY YZ ZZ
in the latest -legacy version is
XX YY ZZ XY XZ YZ
since the expected correct order is the first one, please correct the .vtk generation in the new
foamToVTK -legacy version.
I haven't tried if this problem occurs also without the "-legacy" flag.
### 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 : v1806|v1812|v1906 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
-->
Thank you in advance and have a nice day,
Matteohttps://develop.openfoam.com/Development/openfoam/-/issues/2107Coded BC does not parse parameter values2021-06-08T07:02:15ZTony LaddCoded BC does not parse parameter values
### Summary
I set a parameter in a boundary condition file "omega 2;"
This is parsed by the boundary condition "cylinderBtm" and is correctly substituted in the codeStreamTemplate.C file for the internal field. However the parser th...
### Summary
I set a parameter in a boundary condition file "omega 2;"
This is parsed by the boundary condition "cylinderBtm" and is correctly substituted in the codeStreamTemplate.C file for the internal field. However the parser that creates the fixedValueFvPatchFieldTemplate.C ignores the parameter so the code $omega*x is interpreted as *x. So it will not compile.
### Steps to reproduce
blockMesh
icoFoam
### Example case
[codedTest.zip](/uploads/3b63778456e0cc89e7b8845764927a05/codedTest.zip)
### What is the current *bug* behaviour?
The coded BC does not compile because the source code has not parsed the $omega parameter. If you change $omega in line 74 to 2, it works fine.
A similar code in the codestream for the internal field works.
### What is the expected *correct* behavior?
Should compile and run
### Relevant logs and/or images
[log.icoFoam](/uploads/368aeb384aa0bccb9a8616a819fb3011/log.icoFoam)
### Environment information
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1912
Operating system : ubuntu
Hardware info : Supermicro
Compiler : gcc
### Possible fixes
The parser for the coded bc could be made to recognize parameters, as the codestream parser does.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2108refine distanceSurface proximity filter2021-07-29T13:58:15ZMark OLESENrefine distanceSurface proximity filterEP 1510
The current region-based and proximity-based filtering work adequately for many topologies. However, with a central gap (eg, for double-D pipe), neither works particularly well.
Selecting the largest region can fail spectacularl...EP 1510
The current region-based and proximity-based filtering work adequately for many topologies. However, with a central gap (eg, for double-D pipe), neither works particularly well.
Selecting the largest region can fail spectacularly (choosing the gap and the ragged outside, since they have the largest number of faces). Using face-based proximity filtering will properly handle the ragged edges, but fails to detect the inside gap at all.
As suggested by Sven-Eric, should combine region-based and proximity-based. Use regionSplit for the topological connectivity, combined with a proximity metric for the regions.
Since the region filter is expected to occur, can increase the weighting of regions with _bad_ faces by increasing the initial cell bounding boxes. This will increase the number of ragged faces even more, making an even clearer distinction.v2106Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2109UMean is not found for acousticDampingSource calculations2021-06-30T11:18:49Zzein elserfyUMean is not found for acousticDampingSource calculations
### Summary
I am currently trying to apply acoustic Damping source to a part of the computational domain surrounding aerofoil. I am using rhoPimpleFoam solver for a 3-D computational domain with cyclic boundary conditions in the span-...
### Summary
I am currently trying to apply acoustic Damping source to a part of the computational domain surrounding aerofoil. I am using rhoPimpleFoam solver for a 3-D computational domain with cyclic boundary conditions in the span-wise direction (Z-direction).
The following Lines are added in the fvOptions
```
acousticDampingSource
{
type acousticDampingSource;
active yes;
acousticDampingSourceCoeffs
{
// timeStart 0.004;
duration 1000.0;
selectionMode all;
// selectionMode cellZone;
// cellZone selectedCells;
origin (0.2 0 0);
radius1 0.5;
radius2 0.54;
frequency 1000;
U U;
URef UMean;
}
```
The error message produced is that indicating that the UMean is not found although they are present in the time history data
```
#0 Foam::error::printStack(Foam::Ostream&)[3]
[3]
[3] --> FOAM FATAL ERROR:
[3]
request for volVectorField UMean from objectRegistry region0 failed
available objects of type volVectorField are
4(wallShearStress U_0 U U_0_0)
[3]
[3] From function const Type& Foam::objectRegistry::lookupObject(const Foam::word&, bool) const [with Type = Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>]
[3] in file /data/openFOAM/OpenFOAM-v1906/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 464.
[3]
```
I do not know why the ONLY seen vectorFields are only (wallShearStress U_0 U U_0_0), although, there are other vectorFields like wallShearStressMean,UMean,vorticity,vorticityMean?https://develop.openfoam.com/Development/openfoam/-/issues/2110Custom option from shared library does not execute addsup2021-06-07T13:32:48ZThomas EnzingerCustom option from shared library does not execute addsup
### Summary
Custom coded option, placed in an shared library, is loaded and constructed from solver. But addsup are not executed in all time steps.
Exact same code as scalarCodedSource is executed as aspected.
### Steps to reproduce
...
### Summary
Custom coded option, placed in an shared library, is loaded and constructed from solver. But addsup are not executed in all time steps.
Exact same code as scalarCodedSource is executed as aspected.
### Steps to reproduce
Run the example case and take an look to the solver log file. Code for scalarCodedSource and custom coded option are identical and applied to bottomAir region.
### Example case
Minimum example: [example_1.zip](/uploads/b4ee6b26737ee92308cd6f0eaaa73e96/example_1.zip)
Directory *code* contains the wmake project to build the shared library.
Minimum example (attached file) was constructed from v2012 $FOAM_TUTORIALS/heatTransfer/chtMultiRegionFoam/snappyMultiRegionHeater .
### What is the current *bug* behaviour?
The **addSup** method of the option is not executed by the solver.
### What is the expected *correct* behavior?
The **addSup** method of the option is executed by the solver at all timesteps.
### Relevant logs and/or images
```C++
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v2012 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 308af39136-20210426 OPENFOAM=2012 patch=210414
Arch : "LSB;label=32;scalar=64"
Exec : chtMultiRegionFoam
Date : May 31 2021
Time : 23:01:05
Host : e10491f6fb91
PID : 3822
I/O : uncollated
Case : /data
nProcs : 1
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 5, maxFileModificationPolls 20)
allowSystemOperations : Allowing user-supplied system call operations
...
Adding fvOptions
Creating finite volume options from "constant/fvOptions"
Selecting finite volume options type scalarCodedSource
Source: codedSource1
- selecting all cells
- selected 3952 cell(s) with volume 0.0007786667
Selecting finite volume options type myCustomCodeOption
Source: codedSource2
- selecting all cells
- selected 3952 cell(s) with volume 0.0007786667
Constructor: myCustomCodeOption
*** Reading fluid mesh thermophysical properties for region topAir
...
Solving for fluid region bottomAir
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCGStab: Solving for Ux, Initial residual = 1, Final residual = 9.813842e-11, No Iterations 1
DILUPBiCGStab: Solving for Uy, Initial residual = 1, Final residual = 4.796629e-11, No Iterations 1
DILUPBiCGStab: Solving for Uz, Initial residual = 1, Final residual = 1.290181e-10, No Iterations 1
Using dynamicCode for fvOption::sourceTime at line 20 in "/data/constant/bottomAir/fvOptions.codedSource1"
Could not load > "/data/dynamicCode/platforms/linux64GccDPInt32Opt/lib/libsourceTime_e97fe6ced1b0ca40c9289d9da8b1add0a8482aa2.so"
/data/dynamicCode/platforms/linux64GccDPInt32Opt/lib/libsourceTime_e97fe6ced1b0ca40c9289d9da8b1add0a8482aa2.so: cannot open shared object file: No such file or directory
Creating new library in "dynamicCode/sourceTime/platforms/linux64GccDPInt32Opt/lib/libsourceTime_e97fe6ced1b0ca40c9289d9da8b1add0a8482aa2.so"
Invoking wmake libso /data/dynamicCode/sourceTime
wmake libso /data/dynamicCode/sourceTime
ln: ./lnInclude
dep: codedFvOptionTemplate.C
Ctoo: codedFvOptionTemplate.C
ld: /data/dynamicCode/sourceTime/../platforms/linux64GccDPInt32Opt/lib/libsourceTime_e97fe6ced1b0ca40c9289d9da8b1add0a8482aa2.so
Selecting finite volume options type sourceTime
Source: sourceTime
- selecting all cells
- selected 3952 cell(s) with volume 0.0007786667
Hello scalarCodedSource.
DILUPBiCGStab: Solving for h, Initial residual = 0.9999996, Final residual = 1.079829e-10, No Iterations 1
Min/max T:300 300
GAMG: Solving for p_rgh, Initial residual = 0.8519038, Final residual = 0.008084614, No Iterations 5
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors (bottomAir): sum local = 1.199034e-05, global = 2.856298e-15, cumulative = 2.856298e-15
GAMG: Solving for p_rgh, Initial residual = 0.259271, Final residual = 7.494411e-08, No Iterations 23
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors (bottomAir): sum local = 2.862262e-06, global = 1.923892e-15, cumulative = 4.78019e-15
...
Solving for fluid region bottomAir
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCGStab: Solving for Ux, Initial residual = 0.9504684, Final residual = 1.315995e-11, No Iterations 1
DILUPBiCGStab: Solving for Uy, Initial residual = 0.3615856, Final residual = 7.315234e-12, No Iterations 1
DILUPBiCGStab: Solving for Uz, Initial residual = 0.375026, Final residual = 6.384547e-12, No Iterations 1
Hello scalarCodedSource.
DILUPBiCGStab: Solving for h, Initial residual = 0.9992415, Final residual = 8.874669e-11, No Iterations 1
Min/max T:299.9998 300.6861
...
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2021
- Operating system : archlinux, centos in docker container
- Hardware info : AMD Ryzen, docker container env.
- Compiler : gcc
### Possible fixes
atm.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2111permeable AlphaWall prgTotalPressure2021-06-17T21:01:36ZSergio Ferrarispermeable AlphaWall prgTotalPressure@mark , @Mattijs :
New pair of BC for p_rgh/U for VOF. Works switching from prgTotalPressure/fixedFluxPressure following alpha.
Issue: updateSnGrad(snGradp) is called from pEq defined in constrainPressure.C. The search of BC is hard co...@mark , @Mattijs :
New pair of BC for p_rgh/U for VOF. Works switching from prgTotalPressure/fixedFluxPressure following alpha.
Issue: updateSnGrad(snGradp) is called from pEq defined in constrainPressure.C. The search of BC is hard coded if BC is fixedFluxPressureFvPatchScalarField ,then updateSnGrad(snGradp).
In order to allow permeableAlphaWallprgTotalPressure to set snGradp, a new if else is needed asking if BC is
permeableAlphaWallprgTotalPressure, then call updateSnGrad(snGradp).
[BC.tar](/uploads/6d6a6e401f87041bde6ffb7651b3c629/BC.tar)v2106Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/2112switches in turbulenceProperties should be optional2021-06-09T14:37:26ZMatej Formanswitches in turbulenceProperties should be optional### Functionality to add/problem to solve
In `turbulenceProperties ` file, two switches are mandatory:
```
turbulence on;
printCoefficients on;
```
Both of them are so rarely used they could be switched to optional with the default v...### Functionality to add/problem to solve
In `turbulenceProperties ` file, two switches are mandatory:
```
turbulence on;
printCoefficients on;
```
Both of them are so rarely used they could be switched to optional with the default value set to "on".
Turning them optional and getting rid of them, or at least the first one from the setup would still
keep the backward compatibility easily and people will not be puzzled.
### Target audience
Especially new users are puzzled by "turbulence on" switch as I can see on the courses.
### Proposal
Turning those switches optional or alternatively renaming the "turbulence on" to something less misleading.
`solveTurbulence yes/no; `
or similar.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2113cellLimited<cubic> limiter is not differentiable2021-06-09T14:36:02ZShannon LeakeycellLimited<cubic> limiter is not differentiableThe cubic polynomial in cubicGradientLimiter.H is
```math
((ar + b)r + 1)r \\
a = \frac{2}{r_t^2} - \frac{2}{r_t^3} \\
b = -\frac32 a r_t
```
but surely it should be
```math
((ar + b)r + 1)r \\
a = \frac{1}{r_t^2} - \frac{2}{r_t^3} \\
b ...The cubic polynomial in cubicGradientLimiter.H is
```math
((ar + b)r + 1)r \\
a = \frac{2}{r_t^2} - \frac{2}{r_t^3} \\
b = -\frac32 a r_t
```
but surely it should be
```math
((ar + b)r + 1)r \\
a = \frac{1}{r_t^2} - \frac{2}{r_t^3} \\
b = -\frac32 a r_t - \frac{1}{2r_t}
```
to satisfy the constraints from Michalak and Ollivier-Gooch (2008, p.5), specifically that the derivative at the transition point $`r_t`$ should be zero so it joins up smoothly with 1. This problem is illustrated in the graph below:
![cubic](/uploads/117998f26628bde772c939e92f353d3d/cubic.png)
Linking this [cfd-online thread](https://www.cfd-online.com/Forums/openfoam-programming-development/236503-polynomial-celllimited-cubic-seems-dodgy.html) here just in case someone replies to it after I create this issue.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2114additional patch expressions functions2021-07-08T07:04:32ZMark OLESENadditional patch expressions functionsas noted in EP1558 - the missing `internalField(..)` function is neededas noted in EP1558 - the missing `internalField(..)` function is neededMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2115SnappyHexMesh doesn't create layers on a not aligned surface2021-06-09T18:59:08ZPablo CaronSnappyHexMesh doesn't create layers on a not aligned surface<!--
*** 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 need to mesh a delta wing using snappyHexMesh and adding the boundary layers is a must.
I've been working on the configuration of snappyHexMeshDict to include these layers and I couldn't make SHM to add the layers over the entire surface.
I simplified the geometry to include only the sharp leading edge and the results are very interesting:
- If the geometry is perfectly aligned with the mesh and the coordinates system, SHM adds the boundary layers as I whish
- If the geometry is rotated around 5 degrees (I used surfaceTrasnformPoints -yawPithRoll...) SHM is not capable of adding the boundary layers.
In the previous cases the SHMDict is the same.
It is not clear to me if this is a bug or a misconfiguration of the SHMDict.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
1) Download case aligned
2) Run Allrun script to generate the mesh
3) See the boundary layer mesh
4) Download case notaligned
5) Run Allrun script to generate the mesh
6) See the boundary layer mesh
7) Compare the meshes
### 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
-->
[aligned.tar.gz](/uploads/fcfc6a5b3dff5942ef251d1c7597cfdc/aligned.tar.gz)
[notaligned.tar.gz](/uploads/a0ca0aecab8f4d37320dc69a7d7c2190/notaligned.tar.gz)
### What is the current *bug* behaviour?
<!-- What actually happens -->
snappyHexMesh doesn't generate boundary layers in a not aligned edge.
### What is the expected *correct* behavior?
snappyHexMesh to generate boundary layers in a not aligned edge as it can with the aligned case.
<!-- 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 : v206
Operating system : kubuntu
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2006
- Operating system : kubuntu 2004
- 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/2116reactingFoam laminar combustion solver not running for v20122022-12-23T14:47:45ZSaurav MitrareactingFoam laminar combustion solver not running for v2012<!--
*** 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
reactingFoam solver fails for Laminar Combustion
### Steps to reproduce
Run /OpenFOAM-v2012/tutorials/combustion/reactingFoam/laminar/counterFlowFlame2D
### Example case
Tutorial case :
/OpenFOAM-v2012/tutorials/combustion/reactingFoam/laminar/counterFlowFlame2D
### What is the current *bug* behaviour?
--> FOAM FATAL ERROR:
Unknown psiCombustionModel type laminar
Valid combustionModels are :
15
(
noCombustion<psiThermoCombustion>
infinitelyFastChemistry<psiThermoCombustion,gasHTh ermoPhysics>
diffusion<psiThermoCombustion,constGasEThermoPhysi cs>
infinitelyFastChemistry<psiThermoCombustion,constG asEThermoPhysics>
PaSR<psiChemistryCombustion>
laminar<psiChemistryCombustion>
FSD<psiThermoCombustion,constGasHThermoPhysics>
infinitelyFastChemistry<psiThermoCombustion,constG asHThermoPhysics>
diffusion<psiThermoCombustion,gasEThermoPhysics>
diffusion<psiThermoCombustion,constGasHThermoPhysi cs>
diffusion<psiThermoCombustion,gasHThermoPhysics>
infinitelyFastChemistry<psiThermoCombustion,gasETh ermoPhysics>
FSD<psiThermoCombustion,gasEThermoPhysics>
FSD<psiThermoCombustion,constGasEThermoPhysics>
FSD<psiThermoCombustion,gasHThermoPhysics>
)
From function static Foam::autoPtr<Foam::combustionModels:siCombustio nModel> Foam::combustionModels:siCombustionModel::New(co nst Foam::fvMesh&, const Foam::word&)
in file psiCombustionModel/psiCombustionModel/psiCombustionModelNew.C at line 60.
### What is the expected *correct* behavior?
The case should run without any errors
- OpenFOAM version :2012
- 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
-->v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2120redistributePar messes up zones2021-07-29T13:58:15ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar messes up zones<!--
*** 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 -->
redistributePar produces different zones (e.g. faceZones, cellZones) if the zones are not in alphabetical order
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
`Allrun` in attached case. Input has 0 faces in faceZone 'innerFz', after redistributePar it has 8 faces.
[redistributePar-issue.tgz](/uploads/cc64ed8fba1346d8a4a4c3552fe34ead/redistributePar-issue.tgz)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2012
### Possible fixes
Somewhere in fvMeshDistribute.C it can change the order of the zones. This might not be done consistently?
<!--
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
-->
@Prashant @markMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2121functionObject momentum doesn't write into time folders2021-07-05T13:56:46ZJani SandgrenfunctionObject momentum doesn't write into time folders<!--
*** 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 momentum function object (in OpenFOAM ESI version) does not write anything into the time folders. Only a .dat file in the postProcessing folder. However, when looking at the code it should be writing the momentum into time folders. Also, when using the cylindrical coordinate system of the momentum function object with a tutorial "cavity" it causes a segmentation fault. The simulation was done using OpenFOAM v2006.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Copy tutorial case /incompressible/pisoFoam/RAS/cavity.
Run it using ./Allrun.
Now check the time folders.
To produce the segmentation fault:
Change the option cylindrical from false to true.
(optionally the cylinder can also be defined according to https://www.openfoam.com/documentation/guides/latest/doc/guide-fos-field-momentum.html )
### 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
-->
Example definition for the momentum function object.
![example_definition_of_momentum_fO](/uploads/9f187ece1e52a23c68e5ece45f24ee23/example_definition_of_momentum_fO.png)
### What is the current *bug* behaviour?
<!-- What actually happens -->
Explained above.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Should print data to time folders.
### 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.
-->
This part does not seems to do anything because fieldPtr seems to always return false.
![momentum_write_part_fieldPtr](/uploads/44247b15bb5e1bd17906f1dfb48221ff/momentum_write_part_fieldPtr.png)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2006
- Operating system : Linux 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
-->
The problem may be related to the lines 521 - 530. For some reason the scopedNames are not found.
This has also been tested using kivaTest tutorial where using the cylindrical coordinate system (cylindrical-->true) did not cause segmentation fault. It also wrote some data into the time folders but only the cyl_r, cyl_t, cyl_z files. Not the "momentum", "angularMomentum" and "angularVelocity". (The cyl_r etc are handled in rows 532 to 585 in the momentum function object's .C file)
Link to source code:
https://develop.openfoam.com/Development/openfoam/blob/OpenFOAM-v2012/src/functionObjects/field/momentum/momentum.CKutalmış BerçinKutalmış Berçin