Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-10-05T09:45:20Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2987Silent install/uninstall for OpenFOAM2023-10-05T09:45:20ZMeta DataSilent install/uninstall for OpenFOAMI am testing OpenFOAM-v2306-windows-mingw.exe downloaded from (https://dl.openfoam.com/source/latest/OpenFOAM-windows-mingw.exe) on Windows 10 x64 VM. Command line used for silent install is below: C:\\temp\\OpenFOAM-v2306-windows-mingw....I am testing OpenFOAM-v2306-windows-mingw.exe downloaded from (https://dl.openfoam.com/source/latest/OpenFOAM-windows-mingw.exe) on Windows 10 x64 VM. Command line used for silent install is below: C:\\temp\\OpenFOAM-v2306-windows-mingw.exe /S but this prompts me whether to install Microsoft MSMPI/not. I installed Microsoft MSMPI prior installation of OpenFOAM but still there is prompt. Also silent uninstallation - "C:\\Program Files\\ESI-OpenCFD\\OpenFOAM\\v2306\\uninstall.exe" /S - is not working. There is confirmation prompt which comes up.
Can you please provide the command line to install/uninstall OpenFOAM silently?Pawan GhildiyalPawan Ghildiyalhttps://develop.openfoam.com/Development/openfoam/-/issues/2986BUG: timeActivatedFileUpdate: File state is not changed2023-09-19T16:00:52ZKutalmış BerçinBUG: timeActivatedFileUpdate: File state is not changed[2986-test.zip](/uploads/30a1159a8ff0c08f461ccafc8b4081a1/2986-test.zip) shows that [`fileHandler().getState(watchIndices_[i])`](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/OpenFOAM/db/regIOobject/regIOobjectRead....[2986-test.zip](/uploads/30a1159a8ff0c08f461ccafc8b4081a1/2986-test.zip) shows that [`fileHandler().getState(watchIndices_[i])`](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/OpenFOAM/db/regIOobject/regIOobjectRead.C#L241) returns `0` (i.e. `fileMonitor::UNMODIFIED`).
If the following is added into the `controlDict::functions`, `fileHandler().getState(watchIndices_[i])` correctly returns `1`:
```
sleep
{
type coded;
libs (utilityFunctionObjects);
name sleep;
codeExecute #{ sleep(0.00001); #};
}
```
133149a1ddKutalmış BerçinKutalmış Berçinhttps://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/2984Output format needs nl (function object mapFields)2023-11-03T16:07:50ZTobias HolzmannOutput format needs nl (function object mapFields)Hey all,
the mapFields function object requires a new line (nl or endl) at this code line:
https://develop.openfoam.com/Development/openfoam/-/blame/develop/src/functionObjects/field/mapFields/mapFieldsTemplates.C#L155
Thanks,
TobiHey all,
the mapFields function object requires a new line (nl or endl) at this code line:
https://develop.openfoam.com/Development/openfoam/-/blame/develop/src/functionObjects/field/mapFields/mapFieldsTemplates.C#L155
Thanks,
TobiKutalmış BerçinKutalmış Berçinhttps://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/2982improveMeshQuality: error in constrainedCellsSet command-line flag handling2023-09-18T09:02:28ZGerhard HolzingerimproveMeshQuality: error in constrainedCellsSet command-line flag handling<!--
*** 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 `constrainedCellSet` command line option does nothing.
Quite early in the main() method, the option for constrained cells is added to the list of options as shown below:
`argList::addOption("constrainedCellsSet", "word");`
Later, the passed arguments are checked for the option of constrained cells, as shown below:
```c
word constrainedCellSet;
if (!args.readIfPresent("constrainedCellSet", constrainedCellSet))
{
Info<< "No constraints applied on the smoothing procedure" << endl;
}
```
Unfortunately, there's a typo such that the option "constrainedCellsSet" is added to the command line options, however, later "constrainedCellSet" is checked against. Notice "constrainedCell**s**Set" vs. "constrainedCellSet".
Thus, the option to constrain cells currently does nothing, respectively can not be used.
### 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
-->
Even, when fixing the mis-matched strings, such that the option is actually checked, it still seems to do nothing.
Here's a mesh, where I created a boundary layer using snappyHexMesh, which created a cellSet named addedCells.
![before](/uploads/216bb81e58126869d7d70c0ffc7891fb/before.png)
When I run `improveMeshQuality -constrainedCellSet addedCells` the cells of the boundary layer are still part of the mesh smoothing.
Only the faces at the boundaries are unaffected.
![after](/uploads/6c294e73e29151cea59f9d8b6736c3be/after.png)
Maybe, this feature wasn't intended to protect whole cells from being smoothed.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Running `improveMeshQuality -constrainedCellsSet addedCells` does nothing
Terminal output
```
...
Default number of surface iterations is 2
Using default quality threshold 0.1
No constraints applied on the smoothing procedure
Resizing points!
Starting creating cells
...
```
Running `improveMeshQuality -constrainedCellSet addedCells` leads to an error, since it's no valid option. However, that's what would later be checked in the case as it is now.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
I would expect that the cells of the passed cellSet are not affected by the smoothing operation, which is currently the case.
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2306
- Operating system : ubuntu
- Hardware info :
- Compiler : 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
-->
Match the strings in lines 59 and 96 in improveMeshQuality.C
``argList::addOption("constrainedCellsSet", "word");``
`if (!args.readIfPresent("constrainedCellSet", constrainedCellSet))`https://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/2977solidBodyFvGeometryScheme caches moved state2023-09-13T08:04:46ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsolidBodyFvGeometryScheme caches moved state### Functionality to add/problem to solve
solidBody fvGeometryScheme caches the 'moved' state by default. This upsets e.g. `snappyHexMesh`.
### Target audience
Using solidBody for non-motion applications.
### Proposal
The current s...### Functionality to add/problem to solve
solidBody fvGeometryScheme caches the 'moved' state by default. This upsets e.g. `snappyHexMesh`.
### Target audience
Using solidBody for non-motion applications.
### Proposal
The current set-up assumes that the points that move are always the same (e.g. solid-body rotation). Thus we can eliminate the marking of the changed points. This can be disabled in the fvSchemes setting:
```
geometry
{
type solidBody;
cacheMotion false;
}
```
The marking of the changed points is very fast - it is the marking of affected faces/cells which is the slower one. Maybe this can be optimised.Andrew HeatherAndrew Heatherhttps://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/2972setExprFields with surfaceScalarFields2023-10-11T20:17:15ZGhost UsersetExprFields with surfaceScalarFieldsHi,
I have been trying to create `surfaceScalarFields` from `setExprFields`.
This utility needs a flag for the `oriented` keyword (at least I recognize the dot product with the surface area vector and include the `oriented` keyword)....Hi,
I have been trying to create `surfaceScalarFields` from `setExprFields`.
This utility needs a flag for the `oriented` keyword (at least I recognize the dot product with the surface area vector and include the `oriented` keyword).
This will cause problems in multiprocessor calculations as the values seem to be wrong when the `oriented` keyword is not present.
Tested on OpenFoam: v2212 with pitzDaily tutorial.
If more information is required, please let me know.
Best Regardshttps://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/2970changed headers in the incompressible transportModels2023-09-18T09:01:26ZHenning Scheuflerchanged headers in the incompressible transportModelsThe headers of the transportModel.H are included inconsistently compared to the rest of the library:
```
#include "incompressible/transportModel/transportModel.H"
#include "IOdictionary.H"
#include "incompressible/viscosityModels/viscos...The headers of the transportModel.H are included inconsistently compared to the rest of the library:
```
#include "incompressible/transportModel/transportModel.H"
#include "IOdictionary.H"
#include "incompressible/viscosityModels/viscosityModel/viscosityModel.H"
#include "dimensionedScalar.H"
#include "volFields.H"
```
With the patch below, the format is changed to:
```
#include "transportModel.H"
#include "IOdictionary.H"
#include "viscosityModel.H"
#include "dimensionedScalar.H"
#include "volFields.H"
```
[incompressibleTransport.patch](/uploads/78c2ec0863f5c74c9c671d7e95a2d1df/incompressibleTransport.patch)
PS This simplifies the package of Openfoam for condahttps://develop.openfoam.com/Development/openfoam/-/issues/2969attachDetach has problems2023-08-28T15:17:53ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comattachDetach has problems### Functionality to add/problem to solve
1) attachDetach performs checking on local patch sizes instead of global sizes.
2) e.g. pimpleFoam does not recalculate Uf/Uf.oldTime()
### Target audience
Topo changes.[TJunctionTopoSwitchin...### Functionality to add/problem to solve
1) attachDetach performs checking on local patch sizes instead of global sizes.
2) e.g. pimpleFoam does not recalculate Uf/Uf.oldTime()
### Target audience
Topo changes.[TJunctionTopoSwitching.tgz](/uploads/5e03c41ec9a86f11ae2fcfd3b689521c/TJunctionTopoSwitching.tgz)
potential fix (but recalculates whole flux):
[pimpleFoam.C](/uploads/88cdf41fc969f071247ef705434efb09/pimpleFoam.C)Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2968cara2023-08-22T07:51:04ZNoyan Namdarcara