Development issueshttps://develop.openfoam.com/groups/Development/-/issues2022-06-28T11:08:56Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2345snappyHexMesh blockLevel uses excessive memory2022-06-28T11:08:56ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh blockLevel uses excessive memory<!--
*** 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 can automatically 'block' a small gap by specifying an optional `blockLevel`. This does a wall-distance like calculation and decides per cell if there is an 'opposite' surface as well. If the gap is too small (according to the blockLevel) the cell is marked for deletion.
The problem with the algorithm is that it walks from all surfaces over all of the mesh before in pass 2 deciding whether there is a combination of nearest surfaces that triggers cell deletion. This causes for large meshes and large numbers of surfaces there to be an excessive amount of wall-distance state being generated and compared.
<!-- 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
-->
Tutorial mesh/snappyHexMesh/opposite_walls
It is hard to measure the memory usage though since there are only 3 surfaces and they are tiny.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Memory usage scales with the number of surfaces. For e.g. a case with 100 stls it would store per cell and face 100 structures containing each a vector and some labels. This would cause the memory to run out.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Memory usage should be limited.
### 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 : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112
### 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
-->
Currently : walk all surfaces out over the whole mesh. Pass 2: decide which combinations form a valid small gap.
Fix : do not walk beyond the size given by the originating surface (= 1/2<<blockLevel). This drastically limits the amount of information that needs to be stored.
See https://exchange.openfoam.com/node/1798Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2346Website only consists of the letter x2022-02-01T17:06:34ZVolker WeißmannWebsite only consists of the letter x[Here](https://www.openfoam.com/documentation/guides/latest/doc/openfoam-guide-mesh-motion.html) you link to [this](https://www.openfoam.com/documentation/guides/latest/doc/guide-mesh-motion-dynamicRefineFvMesh.html) and [this](https://w...[Here](https://www.openfoam.com/documentation/guides/latest/doc/openfoam-guide-mesh-motion.html) you link to [this](https://www.openfoam.com/documentation/guides/latest/doc/guide-mesh-motion-dynamicRefineFvMesh.html) and [this](https://www.openfoam.com/documentation/guides/latest/doc/guide-mesh-motion-dynamicMotionSolverFvMesh.html) website. Both of them are clearly unfinished: Quote from the site:
Properties
XXX Usage
XXX Details
XXX Further information
Source code:
-XXX
This bug is quite old: https://develop.openfoam.com/Development/openfoam/-/issues/1481https://develop.openfoam.com/Development/openfoam/-/issues/2347refactor coordSet writers2022-03-12T09:18:31ZMark OLESENrefactor coordSet writerscross-ref EP1772
- this is a particularly older section of OpenFOAM code. Will restructure to more closely resemble the surface writers with internal time-state, etc.cross-ref EP1772
- this is a particularly older section of OpenFOAM code. Will restructure to more closely resemble the surface writers with internal time-state, etc.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2348type aliasing for geometric fields2022-03-31T19:21:44ZMark OLESENtype aliasing for geometric fieldsIn several places we have a fair bit of templating _cruft_ dealing with GeometricFields where it would be convenient to have [C++11 type aliases](https://en.cppreference.com/w/cpp/language/type_alias) instead.
Eg,
```
// Alias
template<...In several places we have a fair bit of templating _cruft_ dealing with GeometricFields where it would be convenient to have [C++11 type aliases](https://en.cppreference.com/w/cpp/language/type_alias) instead.
Eg,
```
// Alias
template<class Type>
using VolumeField = GeometricField<Type, fvPatchField, volMesh>;
```
Later on:
```
const auto* vfield = cfindObject<VolumeField<Type>>(fieldName_);
if (vfield)
{
return calcComponents(*vfield);
}
const auto* sfield = cfindObject<SurfaceField<Type>>(fieldName_);
if (vfield)
{
return calcComponents(*sfield);
}
```
Compared to many places where we have an intermediate typedef:
```
typedef GeometricField<Type, fvPatchField, volMesh> VolFieldType;
typedef GeometricField<Type, fvsPatchField, surfaceMesh> SurfaceFieldType;
if (foundObject<VolFieldType>(fieldName_))
{
...
}
// which is still better than this...
const auto* sfield =
cfindObject<GeometricField<Type, fvsPatchField, surfaceMesh>>(fieldName_);
if (sfield)
{
...
}
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2349untriggered bug with vtk write uniform field in parallel2022-02-11T19:02:55ZMark OLESENuntriggered bug with vtk write uniform field in parallelThe VTK writers writeUniform method uses writeValueParallel (in parallel), which includes
a low-level MPI gather. However the wrapping routine contains an
additional safety check for is_contiguous which is not defined for
various `std::p...The VTK writers writeUniform method uses writeValueParallel (in parallel), which includes
a low-level MPI gather. However the wrapping routine contains an
additional safety check for is_contiguous which is not defined for
various `std::pair<..>` combinations.
Bug is not triggered with current code use, but should be eliminated.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2350Extending the buoyantPimpleFoam solver for LTS support2024-01-11T18:54:54ZTobias HolzmannExtending the buoyantPimpleFoam solver for LTS support### Functionality to add/problem to solve
Implementing the LTS support for buoyantPimpleFoam. I would like to make some test analysis in the HVAC analysis and check, if I can reach a better convergence rather than using SIMPLE(C). In my...### Functionality to add/problem to solve
Implementing the LTS support for buoyantPimpleFoam. I would like to make some test analysis in the HVAC analysis and check, if I can reach a better convergence rather than using SIMPLE(C). In my former company, I used the pseudo-transient method almost all the time for the HVAC analysis. Would be interesting to test as I do have a test case which seems to be quite instable for steady-state algorithms.
### Target audience
Mainly HVAC analysis in terms of convergence optimisation and stability. Some cases seems to behave badly by using the steady-state approach (small convective and larger buoyancy forces).
### Proposal
Simply implement LTS support for buoyantPimpleFoam.
### What does success look like, and how can we measure that?
I would do some HVAC analysis with buoyantSimpleFoam and buoyantPimpleFoam + LTS and compare the results.
### Links / references
See implementation in pimpleFoam
### Funding
Feature exist in pimpleFoamhttps://develop.openfoam.com/Development/openfoam/-/issues/2351FixedList/Pair writeEntry is not opposite of primitiveEntry reading2022-03-04T17:49:31ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comFixedList/Pair writeEntry is not opposite of primitiveEntry reading<!--
*** 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 -->
Write a Pair or FixedList to a binary stream using 'writeEntry' and the result cannot be read as a dictionary.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run attached test app (bit of hack) and it fails with some stream error on the worker processor. Run on e.g. cavity decomposed into two.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112
### 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
-->
Have specialised writeEntry for FixedList which does not use the << operator (or the write routine) to maintain backwards compatibility but instead outputs 'like a List'.[Test-parallel-communicators.C](/uploads/af137f4bf2e969ad2355ae1f8f3ae353/Test-parallel-communicators.C)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2352BUG: redistributePar -reconstruct does not reconstruct processorCyclic2022-02-04T16:51:15ZKutalmış BerçinBUG: redistributePar -reconstruct does not reconstruct processorCyclic### Summary
`redistributePar -reconstruct` fails in a simple case with cyclics that end up on different processsors.
### Steps to reproduce
In the attached case, run `./Allrun-parallel-redistributePar` and inspect `log.redistributePar...### Summary
`redistributePar -reconstruct` fails in a simple case with cyclics that end up on different processsors.
### Steps to reproduce
In the attached case, run `./Allrun-parallel-redistributePar` and inspect `log.redistributePar.reconstruct`: [test-case-redistributePar-reconstruct-03Feb22.zip](/uploads/54819af0c6c6b6ccc608d36cc8e6e559/test-case-redistributePar-reconstruct-03Feb22.zip)
For comparisons, `./Allrun` and `./Allrun-parallel-reconstructPar` can be executed without any error.
### What is the current *bug* behaviour?
Attached logs produced by `FOAM_ABORT=true mpirunDebug -np 4 redistributePar -reconstruct -parallel` where `redistributePar` was compiled with `wmake -debug`: [logs.zip](/uploads/9ea3f34b434abcf3054164466ad437fa/logs.zip)
### Environment information
HEAD = 88b64ab054
opts = linux64ClangDPInt32Opt
The same test case has also failed for versions between v2112-v2006.
FYI: @Mattijs @markhttps://develop.openfoam.com/Development/openfoam/-/issues/2353ThirdParty documentation inconsistency2022-02-11T19:02:44ZDarrin StephensThirdParty documentation inconsistency
### Summary
The ThirdParty SOURCES.md says that the ADIOS2 version for OpenFOAM-v2112 is 2.7.1. However the version set in
etc/config.sh/adios2 and etc/config.csh/adios2 is still 2.6.0.
### Possible fixes
Update the etc/config.sh/adio...
### Summary
The ThirdParty SOURCES.md says that the ADIOS2 version for OpenFOAM-v2112 is 2.7.1. However the version set in
etc/config.sh/adios2 and etc/config.csh/adios2 is still 2.6.0.
### Possible fixes
Update the etc/config.sh/adios2 and etc/config.sh/adios2 files to use version 2.7.1.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2355Enhancement to chtMultiRegion*Foam with residual controls2022-05-06T11:20:20ZTobias HolzmannEnhancement to chtMultiRegion*Foam with residual controls### Functionality to add/problem to solve
During updating my tutorials on my website, I found that the chtMultiRegionFoam does not support:
- Under-relaxation when we want to make more outer corrections
- And hence, I guess a residual co...### Functionality to add/problem to solve
During updating my tutorials on my website, I found that the chtMultiRegionFoam does not support:
- Under-relaxation when we want to make more outer corrections
- And hence, I guess a residual control for outer-correction loop is not possible either
- Furthermore, the steady-state solver does not has an residual control implemented to leave the SIMPLE loop after all convergence criteria are fulfilled
### Target audience
CHT cases with high stiffness in terms of the fluid-region which might need under-relaxation and outer corrections
### Proposal
Extending the solver to work with outer-loops (fluid-region).
Stuff was already implemented in v8.
### What does success look like, and how can we measure that?
Testing on my gin-tonic case should be sufficient in terms of functionality implementations.
Residual-Control can be checked easily using FOAM tutorials
### Links / references
- chtMultiRegionSimpleFoam residual control
- https://github.com/OpenFOAM/OpenFOAM-dev/commit/f04f5b1563d1bc8d0260674d7582a4c961c407fe#diff-04dd65cb42b8ba9960ffb19da381647e574d20def128fc6a0de50f7e88d04ce2
- https://github.com/OpenFOAM/OpenFOAM-dev/commit/53f0c26cf0212cdd0eeaed58bcfa294b063045b1#diff-04dd65cb42b8ba9960ffb19da381647e574d20def128fc6a0de50f7e88d04ce2
- https://github.com/OpenFOAM/OpenFOAM-dev/commit/50bedbb217fbc4c7a278838f53615e5136e0e5bd#diff-04dd65cb42b8ba9960ffb19da381647e574d20def128fc6a0de50f7e88d04ce2
- https://github.com/OpenFOAM/OpenFOAM-dev/commit/fcb142d64d25e6d643dd08a0f8b5ed8178338989#diff-04dd65cb42b8ba9960ffb19da381647e574d20def128fc6a0de50f7e88d04ce2
- chtMultiRegionFoam convergence implementation; Source-Code v9
### Funding
If you want, I can provide the patch.https://develop.openfoam.com/Development/openfoam/-/issues/2356checkMesh report AMI coverage on mapped patches2022-06-28T11:03:55ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh report AMI coverage on mapped patches### Functionality to add/problem to solve
When doing explicit coupling (e.g. chtMultiRegionFoam) it uses the 'mappedPatch', 'mappedWall' type patches to store the coupling information. For `AMI` coupling it might be good to know the act...### Functionality to add/problem to solve
When doing explicit coupling (e.g. chtMultiRegionFoam) it uses the 'mappedPatch', 'mappedWall' type patches to store the coupling information. For `AMI` coupling it might be good to know the actual coverage, similar to cyclicAMI. This can be added to checkMesh (which already outputs the weights for cyclicAMI).
### Target audience
Explicit coupling using AMI.
### Proposal
When run with `-allGeometry` also output the weights on the AMI for the mapped patch.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2357impossible code in particleDistribution2022-02-08T15:32:13ZMark OLESENimpossible code in particleDistributionby inspection - around line 140 of particleDistribution.C
```
if
(
tagFieldName_ != "none"
&& cloudObr.foundObject<IOField<scalar>>(tagFieldName_)
)
{
// Tag field present - generate distribution per...by inspection - around line 140 of particleDistribution.C
```
if
(
tagFieldName_ != "none"
&& cloudObr.foundObject<IOField<scalar>>(tagFieldName_)
)
{
// Tag field present - generate distribution per tag
const IOField<label>& tag =
cloudObr.lookupObject<IOField<label>>(tagFieldName_);
...
```
It is either ignored by the `if` when the tagFieldName_ is actually a labelField, or runtime error if it was found as a scalarField, but followed by a lookup as a labelField.
Unless I missed something here.https://develop.openfoam.com/Development/openfoam/-/issues/2358add min/max/average/size results for probes2022-05-11T09:48:38ZMark OLESENadd min/max/average/size results for probesMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2359singleProcessorFaceSets not working in parallel2022-06-28T11:01:41ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsingleProcessorFaceSets not working in parallel<!--
*** 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 decomposition constraint 'singleProcessorFaceSets' does not work in combination with `redistributePar`. It works with `decomposePar`. The setup collects all cyclicAMI faces into a faceSet and then uses the constraint to keep all of them on the same processor.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
decomposePar a case. Make sure that e.g. cyclicAMI is distributed (check that multiple processors have faces for the patch e.g. by looking at processorDDD/constant/polyMesh/boundary). Use `topoSet` in parallel to collect the patch faces into a faceSet, e.g. a sample `topoSetDict` to collect the faces in patches `fan*`:
```
actions
(
// Left fan
{
name fanLeftFaceSet;
type faceSet;
action new;
source patchToFace;
patches (fanLeft_master fanLeft_slave);
}
// Right fan
....
}
```
Then add a constraint to the `decomposeParDict`:
```
method ptscotch;
constraints
{
keepCyclicAtOnePatch
{
type singleProcessorFaceSets;
sets
(
(fanLeftFaceSet -1)
(fanRightFaceSet -1)
);
enabled true;
}
}
```
Run
```
mpirun -np DDD redistributePar -parallel
```
and check where the cyclicAMI faces have ended up.
### Example case
Unfortunately a bit too big to attach. Take any case with multiple cyclicAMI and e.g. random decomposition and follow above receipe.
<!--
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 -->
Faces are not on a single processor
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Faces/cells point-connected to the faceSet should be on a single processor.
### 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 : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2112
### 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
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2360Bug in activePressureForceBaffleVelocity boundary condition2022-05-06T10:02:50ZTobias HolzmannBug in activePressureForceBaffleVelocity boundary condition<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
The activePressureForceBaffleVelocity boundary condition calculates the pressure difference between the two blocked cyclic patches in a wrong matter if we use a NONE forced-based approach because the weighting area is wrong. The set-up for such a boundary condition is as follows:
- two cyclic patches
- duplicate the two cyclic patches and merged them together to get one patch -> blocking wall
In the updateCoeffs function of the activePressureForceBaffleVelocity condition, we first calculate the force at the cyclic (master) patch and subtract the force at the cyclic (slave) patch. This force difference gets divided by the patch area which is the wall-patch (the wall patch has the master and slave area; so it's double as large as a single cyclic patch). The result is, the BC condition does not open at the user-defined threshold but rather when we reached the doubled delta value.
I found this issue a while ago while creating this case: https://holzmann-cfd.com/community/training-cases/tank-with-safety-valve
; same behavior for the OpenFOAM tutorial: $FOAM_TUTORIALS/combustion/PDRFoam/flamePropagationWithObstacles
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Download either the case I provided on my website or use the tutorial case and check the output of the log -> activation is not given within the specified threshold.
<!-- How one can reproduce the issue - this is very important -->
### Example case
https://holzmann-cfd.com/community/training-cases/tank-with-safety-valve
$FOAM_TUTORIALS/combustion/PDRFoam/flamePropagationWithObstacles
<!--
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?
Wrong area (division) is used in the calculation of the dp calculation and hence, the BC condition does not switch its behavior when we reach the user-defined threshold.
<!-- What actually happens -->
### What is the expected *correct* behavior?
The condition should switch its behavior after the user-defined threshold is reached.
<!-- 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 : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2106 and v2112
- Operating system : Ubuntu 21.04
- Hardware info : Not relevant
- Compiler : Not relevant
### Possible fixes
Correct the used area for NONE forced-based calculations.
Patch attached - additionally I added some more information to the output (for transparency reasons)
Code line which is wrong: https://develop.openfoam.com/Development/openfoam/-/blob/master/src/finiteVolume/fields/fvPatchFields/derived/activePressureForceBaffleVelocity/activePressureForceBaffleVelocityFvPatchVectorField.C#L278
<!--
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
-->
[0001-BUG-activePressureForceBaffleVelocity-wrong-area-in-.patch](/uploads/68fae4aa17583ff777cd90fb8e46cc73/0001-BUG-activePressureForceBaffleVelocity-wrong-area-in-.patch)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2361sample/store fields may cause dimension check error2022-06-24T15:14:55ZMark OLESENsample/store fields may cause dimension check errorIssue raised as EP1826 with surface sampling. The stored fields are dimensioned.
However, it is perhaps possible that the named field changes dimensions (@Chiara?)
In which case,
```
//OLD dimfield->dimensions() = dims;
//NEW
dimfield-...Issue raised as EP1826 with surface sampling. The stored fields are dimensioned.
However, it is perhaps possible that the named field changes dimensions (@Chiara?)
In which case,
```
//OLD dimfield->dimensions() = dims;
//NEW
dimfield->dimensions().reset(dims);
```
in polySurfacesTemplates.CMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2362writeDictionary function object with too many disk accesses2022-02-11T19:01:50ZMark OLESENwriteDictionary function object with too many disk accessesNoted in EP1794 when monitoring "controlDict"
Since the writeDictionary is attached to a regionFunctionObject, it will not see objects registered on time. For items that are not registered at all, it needs some improved logic.
@chiaraNoted in EP1794 when monitoring "controlDict"
Since the writeDictionary is attached to a regionFunctionObject, it will not see objects registered on time. For items that are not registered at all, it needs some improved logic.
@chiaraMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2363AMIMethod not restartable2022-02-24T16:31:22ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comAMIMethod not restartable<!--
*** 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 -->
Various AMIMethods do not output their optional inputs.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
E.g. create a blockMeshDict a cyclicAMI
AMIMethod nearestFaceAMI;
maxDistance2 1e-10; // optional max search distance (squared)
run blockMesh and look at the boundary file.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112
@andyMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2364allow overset HOLE cells to be marked to arbitrary shape of fringe, but Cd cu...2023-01-25T09:36:01ZChen Jingleallow overset HOLE cells to be marked to arbitrary shape of fringe, but Cd curve is rougher### Functionality to add/problem to solve
This implemtation is inspire by [louis](https://develop.openfoam.com/Development/openfoam/-/issues/2106), who put the HOLE cells further by n layers (n is set by user). However, this is subjecte...### Functionality to add/problem to solve
This implemtation is inspire by [louis](https://develop.openfoam.com/Development/openfoam/-/issues/2106), who put the HOLE cells further by n layers (n is set by user). However, this is subjected to only the shape of the wall patches. As a better way utilizing the overset features, HOLE cells should be near to the fringe.
### Target audience
To who wants HOLE cells to be perfectly matched the fringe like me.
### Proposal
The code is uploaded to [my github](https://github.com/chancesFOAM/inverseDistanceFringe). Just downald it and test!
### What does success look like, and how can we measure that?
The original results of v2006 marking HOLE cells is like:
![问题图](/uploads/51eb4faf2e7658424fc7717fc2fee47e/问题图.PNG)
In my implementation, the HOLE cells could be marked to arbitrary shape of fringe:
ciecle:
![toTheFringe](/uploads/df92629f512985bd8261ebf0dd9f1a1c/toTheFringe.PNG)
rectangle:
![nPushBack_square](/uploads/304c4ec59a32cc0606d22562ecfebe51/nPushBack_square.PNG)
### Problems at present
When I test it with a cylinder case, the force coefficient result is very rough:
![largeCd](/uploads/0a4434f37002e49be20d570d6dced320/largeCd.PNG)
The same phenomenon occours applying louis's pushFront. However, applying the original version of inverseDistance, the Cd curve is also rough but finer:
![origin](/uploads/08370bed1dae00a5fd822f424acf8caa/origin.PNG)
I don't know why. Any ideas?https://develop.openfoam.com/Development/openfoam/-/issues/2365thermoCoupleProbes tutorial crash2022-06-28T11:01:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comthermoCoupleProbes tutorial crash<!--
*** 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 -->
Tutorial heatTransfer/buoyantPimpleFoam/thermocoupleTestCase crashes
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
foamRunTutorials
### 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 -->
```
-> FOAM FATAL ERROR: (openfoam-2112)
T not found in table. Valid entries: 0()
```
### Relevant logs and/or images
see above
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2112|v2106|v2012|v2006|v1912|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : >v2112Mark OLESENMark OLESEN