Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-10-16T16:44:19Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2994Add Allwclean missing (inside some libraries to clean dependencies)2023-10-16T16:44:19ZGabriel Barajasbarajasg@unican.esAdd Allwclean missing (inside some libraries to clean dependencies)### Functionality to add/problem to solve
Add files to clean all the compiled dependencies for each library
### Target audience
OpenFOAM developers
### Proposal
Add the missing cleaning script; For example:
(1) in **transportModels*...### Functionality to add/problem to solve
Add files to clean all the compiled dependencies for each library
### Target audience
OpenFOAM developers
### Proposal
Add the missing cleaning script; For example:
(1) in **transportModels**, create a Allwclean such as:
#!/bin/sh
cd "${0%/*}" || exit # Run from this directory
wclean twoPhaseMixture
wclean interfaceProperties
wclean twoPhaseProperties
wclean incompressible
wclean compressible
wclean immiscibleIncompressibleTwoPhaseMixture
wclean geometricVoF
wcleanLnIncludeAll
#------------------------------------------------------------------------------
(2) or in **thermophysicalModels**, create a Allwclean such as:
#!/bin/sh
cd "${0%/*}" || exit # Run from this directory
wclean specie
wclean solidSpecie
wclean thermophysicalProperties
wclean basic
wclean reactionThermo
wclean laminarFlameSpeed
wclean chemistryModel
wclean barotropicCompressibilityModel
wclean SLGThermo
wclean solidThermo
wclean solidChemistryModel
wclean radiation
wcleanLnIncludeAll
#------------------------------------------------------------------------------
### What does success look like, and how can we measure that?
I am not sure how to measure success, sorry :disappointed:
Thanks,
Gabihttps://develop.openfoam.com/Development/openfoam/-/issues/2993processor agglomeration does not support non-processor coupled patches2023-12-09T18:01:19ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comprocessor agglomeration does not support non-processor coupled patches### Functionality to add/problem to solve
processor agglomeration does not support non-processor coupled patches e.g. `cyclicAMI`
### Target audience
Parallel runs that
- benefit from processor agglomeration
- use cyclicAMI/cyclicACM...### Functionality to add/problem to solve
processor agglomeration does not support non-processor coupled patches e.g. `cyclicAMI`
### Target audience
Parallel runs that
- benefit from processor agglomeration
- use cyclicAMI/cyclicACMI
### Proposal
Add general I/O for sending/receiving GAMG interfaces & fields.
### What does success look like, and how can we measure that?
Use `processorAgglomerator masterCoarsest` on cases with cyclicAMI.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2990dictionary error message missing line number2023-10-28T11:08:25ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdictionary error message missing line number### Functionality to add/problem to solve
dictionary parsing error message not printing line number/file name
With incorrect topoSetDict dictionary:
```
{
name f0;
source boxToFace
box (0.499 -100 -1...### Functionality to add/problem to solve
dictionary parsing error message not printing line number/file name
With incorrect topoSetDict dictionary:
```
{
name f0;
source boxToFace
box (0.499 -100 -100)(0.501 100 100);
}
```
it gives error message without printing file/line number. filename is not valid ('source') but line number is correct however does not get printed.
### Proposal
either
- fix filename to be fed through or
- output linenumber (even though filename is not correct)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2985cellVolumeWeight incorrect debug info2024-01-05T15:55:28ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcellVolumeWeight incorrect debug info<!--
*** 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 -->
Switching on debug information for cellVolumeWeight causes out-of-bounds on cell-type counting
### What is the current *bug* behaviour?
<!-- What actually happens -->
cellTypes are 5 possible options since v2212.
### 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
### 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
-->
Correct sizing.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2983cyclicAMI requires up-to-date neighbourPatch field2023-12-21T15:49:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcyclicAMI requires up-to-date neighbourPatch field<!--
*** 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 in non-blocking mode (#2963) produces different results
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run `incompressible/pimpleFoam/laminar/mixerVesselAMI2D/mixerVesselAMI2D` tutorial even for one time step. Initial residuals on U of 2nd pimple are different from v2306.
### Example case
See above
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
The stress term (nuEff*dev2(T(grad(U))))) is not consistent across the cyclicAMI. In the old formulation it would be calculated - in the new one it is stored/cached and updated during the evaluation. However this intermediate calculation is not evaluated.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Same as v2306.
### 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 : v2307
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
This is can be solved by
- disabling caching of neighbourValue in cyclicAMI. Note that linear-solver behaviour is ok.
- or tag neighbourValue with timestamp of internal field (using regIOobject::upToDate)
- or going to fully consistent cyclicAMI values (https://develop.openfoam.com/Development/openfoam/-/tree/feature-evaluation-check?ref_type=heads)
<!--
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
-->
@markv2312https://develop.openfoam.com/Development/openfoam/-/issues/2981snappyHexMesh : extend to allow multiple insidePoints per cellZone surface2023-12-21T17:27:34ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh : extend to allow multiple insidePoints per cellZone surface### Functionality to add/problem to solve
Being able to have multiple regions in the same cellZone by specifying multiple 'insidePoints'
### Target audience
shm users with multiple cellZones
### Proposal
Have optional `insidePoints...### Functionality to add/problem to solve
Being able to have multiple regions in the same cellZone by specifying multiple 'insidePoints'
### Target audience
shm users with multiple cellZones
### Proposal
Have optional `insidePoints` specification instead of just single `insidePoint`Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2980cyclicAMI ignores patchNeighbourField in component-coupled linear solver2023-12-21T17:28:44ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcyclicAMI ignores patchNeighbourField in component-coupled linear solver<!--
*** 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 non-blocking cyclicAMI (!623) ignores patchNeighbourField in component-coupled linear solver
2) clone-with-new internalfield also copies patchNeighbourfield. Generally a new internalfield also introduces new values (?) so the patch-neighbour field should be updated
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Visual inspection of the code.
### 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
-->
any cyclicAMI with distributed AMI, e.g. mixerVesselAMI2D tutorial
### 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 :
- 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
-->
@markMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2979Finite Area regression in 2306 leads to error in the avalanche module2024-01-01T09:22:02ZMatti RauterFinite Area regression in 2306 leads to error in the avalanche module<!--
*** 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 ran the wolfsgruben case with v2306 and experienced some artifacts that were not there in v2212.
I tried different combinations of versions of OpenFOAM and the avalanche module and came to the conclusion that the regression is in OpenFOAM-v2306.
### Steps to reproduce
<!-- 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
-->
Run the wolfsgruben tutorial of the OpenFOAM avalanche module. Note that there are some missing semicolons in the releaseArea file (I already prepared a patch for 2312 to fix that).
### What is the current *bug* behaviour?
When the flow depth becomes small, the velocity starts to look weird (see image below).
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The velocity looked smooth at this position with v2212.
### Relevant logs and/or images
[finiteArea_v2306](/uploads/fe8c11b8ec812e34b9a499456c3d6dc9/finiteArea_v2306.png)
<!--
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 : Linux Mint 21
- Hardware info : AMD Ryzen 7
- 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
-->
I expect some changes, maybe in the definition of fac::grad. Maybe some changed signs?Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2978BUG: runTimeModifiable crashes with collated in rhoPimpleFoam2023-11-23T15:51:12ZAlberto ceschinBUG: runTimeModifiable crashes with collated in rhoPimpleFoam### Summary
It is not possible to modify i.e. `endTime` during run time in tutorial `compressible/rhoPimpleFoam/RAS/aerofoilNACA0012` in parallel with `-fileHandler collated` and `runTimeModifiable true`. On the contrary, other solvers ...### Summary
It is not possible to modify i.e. `endTime` during run time in tutorial `compressible/rhoPimpleFoam/RAS/aerofoilNACA0012` in parallel with `-fileHandler collated` and `runTimeModifiable true`. On the contrary, other solvers behaeve as expected.
### Steps to reproduce
copy tutorial
`OpenFOAM-v2306/tutorials/compressible/rhoPimpleFoam/RAS/aerofoilNACA0012`
into run folder;
`foamGetDict decomposeParDict`;
Reduce number of cores to 4 and eliminate what is after scotch from the dictionary;
Increase `endTime` to `100`;
`./Allrun` but in parallel with
`runApplication decomposePar -fileHandler collated`;
`runParallel rhoPimpleFoam -fileHandler collated`;
at the end.
Change `endTime` to `101` during run time;
### What is the current *bug* behaviour?
```ExecutionTime = 13.52 s ClockTime = 13 s
From virtual bool Foam::regIOobject::readIfModified()
in file db/regIOobject/regIOobjectRead.C at line 271
Re-reading object controlDict from file "/home/username/OpenFOAM/username-v2306/run/FOAM_RUN/system/controlDict"
[0]
[0]
[0] --> FOAM FATAL IO ERROR: (openfoam-2306)
[0] Cannot find file "/home/username/OpenFOAM/username-v2306/run/FOAM_RUN/processor0/system/controlDict" fileHandler : comm:0 ioRanks:4(0 1 2 3)
[0]
[0] From static Foam::autoPtr<Foam::ISstream> Foam::fileOperations::masterUncollatedFileOperation::read(Foam::IOobject&, Foam::label, bool, const fileNameList&, const boolUList&)
[0] in file global/fileOperations/masterUncollatedFileOperation/masterUncollatedFileOperation.C at line 526.
[0]
FOAM exiting
[0]
--------------------------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code. Per user-direction, the job has been aborted.
--------------------------------------------------------------------------
--------------------------------------------------------------------------
mpirun detected that one or more processes exited with non-zero status, thus causing
the job to be terminated. The first process to do so was:
Process name: [[8529,1],0]
Exit code: 1
-------------------------------------------------------------------------
```
### Environment information
OpenFOAM version : v2306
Operating system : ubuntu 22https://develop.openfoam.com/Development/openfoam/-/issues/2976cross-compile from opensuse to windows112023-09-14T13:26:21Zfea1ncross-compile from opensuse to windows11The output after running blockMesh is as follows
`--> FOAM FATAL ERROR :`
`Could not find mandatory etc entry (mode=ugo) 'controlDict'`
how to fix this?The output after running blockMesh is as follows
`--> FOAM FATAL ERROR :`
`Could not find mandatory etc entry (mode=ugo) 'controlDict'`
how to fix this?Pawan GhildiyalPawan Ghildiyalhttps://develop.openfoam.com/Development/openfoam/-/issues/2975foamCloneCase generates unnecessary folder when no time directories present2023-10-28T11:07:37ZWojciech SadowskifoamCloneCase generates unnecessary folder when no time directories present### Summary
foamCloneCase generates unnecessary folder when no time directories present.
For example, if you create a case `basic_case` with only `constant` and `system` directories,
the results of cloning such a case with
```bash
foam...### Summary
foamCloneCase generates unnecessary folder when no time directories present.
For example, if you create a case `basic_case` with only `constant` and `system` directories,
the results of cloning such a case with
```bash
foamCloneCase basic_case test
```
will be:
```
test
├── basic_case <--- this shouldn't be here
├── constant
│ ├── transportProperties
│ └── turbulenceProperties
└── system
├── controlDict
├── fvSchemes
└── fvSolution
```
### Steps to reproduce
1. Create a case like that:
```
basic_case
├── constant
│ ├── transportProperties
│ └── turbulenceProperties
└── system
├── controlDict
├── fvSchemes
└── fvSolution
```
2. Clone with
```bash
foamCloneCase basic_case test
```
### Example case
Attached archive of `basic_case` example
### What is the current *bug* behaviour?
The shell script gets the path of the time folder to be copied at the line 74:
```bash
TIME_DIR="$(foamListTimes -withZero -case $1 | $TIME_OPTION)"
```
In the presented case `TIME_DIR` variable will simply be empty which will lead to bad copy operation at line 77
```bash
cp -r $1/system $1/constant $1/${TIME_DIR} $2
```
as `$1/${TIME_DIR}` will simply evaluate to `base_case/` in the presented example, trying to copy the case into itself.
### What is the expected *correct* behavior?
Copy only what is in the original case, without creating any unnecessary folders.
### Environment information
- OpenFOAM version : v2306
- Operating system : Ubuntu 23.04
- Hardware info : -
- Compiler : -
### Possible fixes
Test if the variable is empty, only copy if it is. Example solution:
```bash
echo "Copying case directories from $1 to $2"
cp -r $1/system $1/constant $2
TIME_DIR="$(foamListTimes -withZero -case $1 | $TIME_OPTION)"
if [ ! -z "$TIME_DIR" ]
then
cp -r $1/${TIME_DIR} $2
else
echo "No time directories to copy"
fi
```
The patch for this solution is attached as well.[foamCloneCase.patch](/uploads/fe5bce6338a7f94e950af905467e8467/foamCloneCase.patch)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2974DynamicList<char>::readList misses special handling2023-09-06T07:46:36ZMark OLESENDynamicList<char>::readList misses special handlingWhen fully implementing the `DynamicList<T>::readList`, missed out the fact that `List<char>::readList` is a specialization which temporarily toggles ASCII to BINARY before reading `char` data (since this is the only means of preserving ...When fully implementing the `DynamicList<T>::readList`, missed out the fact that `List<char>::readList` is a specialization which temporarily toggles ASCII to BINARY before reading `char` data (since this is the only means of preserving char data).
Only affects develop branch after 4-AUG-2023.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2973toggle warnings back on into functionObjectList2023-09-12T06:54:32ZPrashant Sonakartoggle warnings back on into functionObjectListWhen running with "errors warn": the first 10 warnings are written. However, when the function object goes back to a good state, any further warnings afterwards are also suppressed.
Could be good to know when the transition from good-to...When running with "errors warn": the first 10 warnings are written. However, when the function object goes back to a good state, any further warnings afterwards are also suppressed.
Could be good to know when the transition from good-to-bad happens each time.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2971snappyHexMesh interfaceRefine does not work as expected2023-09-07T15:18:08ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh interfaceRefine does not work as expected<!--
*** 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 interfaceRefine should 'fill in' refinement such that islands of coarse cells surrounded by fine cells get refined. This avoid excessive changes in refinement level. In the picture below the cells-to-be-refined are in red
![MicrosoftTeams-image](/uploads/6555e3e38ad7b4b8089a8c5ef6799b1f/MicrosoftTeams-image.png)
### 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
-->
E.g. https://exchange.openfoam.com/node/2248 (cylinder with some refinement)
### What is the current *bug* behaviour?
<!-- What actually happens -->
It picks too many cells since it did not check for neighbouring refinement level, only for 'oppositeness'.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
In picture above correctly identify the red cells and refine them
### 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
### 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
-->
in snappyRefineDriver::refinementInterfaceRefine make sure to test the neighbouring refinement level.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2968cara2023-08-22T07:51:04ZNoyan Namdarcarahttps://develop.openfoam.com/Development/openfoam/-/issues/2967patches error2023-08-22T06:52:37ZCesar Cpatches errorHello, I'm trying to run an openFOAM case and I'm getting this error:
Is it related to patches? Not sure about it. Any help will be appreciated.
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ?...Hello, I'm trying to run an openFOAM case and I'm getting this error:
Is it related to patches? Not sure about it. Any help will be appreciated.
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in "/lib64/libc.so.6"
#3 Foam::cyclicFvPatch::makeWeights(Foam::Field<double>&) const at ??:?
#4 Foam::surfaceInterpolation::makeWeights() const at ??:?
#5 Foam::surfaceInterpolation::weights() const at ??:?
#6 Foam::fvPatch::weights() const at ??:?
#7 Foam::coupledFvPatchField<double>::evaluate(Foam::UPstream::commsTypes) at ??:?
#8 Foam::cyclicFvPatchField<double>::cyclicFvPatchField(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#9 Foam::fvPatchField<double>::adddictionaryConstructorToTable<Foam::cyclicFvPatchField<double> >::New(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#10 Foam::fvPatchField<double>::New(Foam::fvPatch const&, Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#11 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::Boundary::readField(Foam::DimensionedField<double, Foam::volMesh> const&, Foam::dictionary const&) at ??:?
#12 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::readFields(Foam::dictionary const&) at ??:?
#13 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::readFields() at ??:?
#14 Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>::GeometricField(Foam::IOobject const&, Foam::fvMesh const&) at ??:?
#15 ? at ??:?
#16 ? at ??:?
#17 __libc_start_main in "/lib64/libc.so.6"
#18 ? at ??:?
Floating point exception (core dumped)https://develop.openfoam.com/Development/openfoam/-/issues/2966more graceful handling of empty surfaces in surfaceFieldValue2024-01-19T19:56:46ZMark OLESENmore graceful handling of empty surfaces in surfaceFieldValueIn some workflows, surfaceFieldValue is used to obtain patch values but the patches themselves may appear or disappear during the course of the simulation. At the moment, any surface with zero faces is treated as an error (which is usual...In some workflows, surfaceFieldValue is used to obtain patch values but the patches themselves may appear or disappear during the course of the simulation. At the moment, any surface with zero faces is treated as an error (which is usually is), but this could/should be extended to emit a warning, ignore or whatever. This would allow support for these particular workflows.
The `functionObjectList::errorHandlingType` (currently private) provides the necessary options (default, warn, ignore, strict). These should be exposed as public and be reused for surfaceFieldValue. This would allow user-defined remedial actions. These error handling and error-codes may also be desirable for sampled surfaces etc (TDB).
cross-ref: 2243v2312Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2965xcrun support for darwin (MacOS)2023-08-19T06:44:26ZMark OLESENxcrun support for darwin (MacOS)Issue has been touched on before, but never handled since it would add even more complexity into the already mess wmake rules. However, since the introduction of `WM_COMPILE_CONTROL` we actually do have a fair bit more flexibility, which...Issue has been touched on before, but never handled since it would add even more complexity into the already mess wmake rules. However, since the introduction of `WM_COMPILE_CONTROL` we actually do have a fair bit more flexibility, which lets us add in `xcrun` support.
cross-ref: EP2234Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2964No base point for face... produces a valid tet decomposition.2023-08-18T07:28:42ZCesar CNo base point for face... produces a valid tet decomposition.I've been trying to run a case by using picFOAM and I'm getting this warning:
--> FOAM Warning :
From function Foam::triFace Foam::tetIndices::faceTriIs(const Foam::polyMesh&) const
in file /apps/easybuild/software/tinkercliff...I've been trying to run a case by using picFOAM and I'm getting this warning:
--> FOAM Warning :
From function Foam::triFace Foam::tetIndices::faceTriIs(const Foam::polyMesh&) const
in file /apps/easybuild/software/tinkercliffs-rome/OpenFOAM/9-foss-2021a/OpenFOAM-9/src/OpenFOAM/lnInclude/tetIndicesI.H at line 76
No base point for face 7468, 3(16 40 200), produces a valid tet decomposition.
When I run the solver it does not show me errors but it seems that it can not solve anything and no results are obtained. Any help will be appreciated. Thankshttps://develop.openfoam.com/Development/openfoam/-/issues/2963add non-blocking communication for cyclic AMI2023-12-21T15:56:08ZMark OLESENadd non-blocking communication for cyclic AMIcross-ref: EP2240cross-ref: EP2240