openfoam issueshttps://develop.openfoam.com/Development/openfoam/-/issues2019-10-29T10:59:04Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1177allow adjustment of write precision for foamDictionary2019-10-29T10:59:04ZMark OLESENallow adjustment of write precision for foamDictionary- since foamDictionary doesn't use `system/controlDict` it will use the standard default precision.
- Add -precision option to allow adjusting this value.
@amutzk @svilfaye- since foamDictionary doesn't use `system/controlDict` it will use the standard default precision.
- Add -precision option to allow adjusting this value.
@amutzk @svilfayeMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2639allow configurable field send/receive in surfaceNoise2022-11-23T08:15:47ZMark OLESENallow configurable field send/receive in surfaceNoisesimilar pattern as #2402 : cross-ref EP1788
- the ability to switch between nonBlocking and scheduled would be an advantage.
- likely makes sense to reuse the globalIndex handling and avoid PstreamBuffers.similar pattern as #2402 : cross-ref EP1788
- the ability to switch between nonBlocking and scheduled would be an advantage.
- likely makes sense to reuse the globalIndex handling and avoid PstreamBuffers.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1418allow invariant surfaces for sampling2023-12-07T19:05:02ZMark OLESENallow invariant surfaces for samplingThe invariant switch is an advanced feature to declare that the surface is
unaffected by changes in the general mesh geometry. For example, if sampling
on a static patch while some other motion occurs elsewhere. If used improperly,
ther...The invariant switch is an advanced feature to declare that the surface is
unaffected by changes in the general mesh geometry. For example, if sampling
on a static patch while some other motion occurs elsewhere. If used improperly,
there is a significant possibility for problems (caveat emptor).
cross-ref EP1125
@svilfaye @PrashantMark OLESENMark OLESENhttps://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/2106allow overset hole to be further away from the wall patch2022-02-12T14:06:00ZLouisallow overset hole to be further away from the wall patch### Functionality to add/problem to solve
The code I am attaching here allows to grow the hole and thus push back the interpolation interface from background to component mesh. Some issues in terms of stability still remain, but combine...### Functionality to add/problem to solve
The code I am attaching here allows to grow the hole and thus push back the interpolation interface from background to component mesh. Some issues in terms of stability still remain, but combined with pimple pressure under-relaxation on the final iteration I was able to obtain satisfactory results. I did not run the cases in an isolated manner so I cannot calculate the speedup that should come from the fewer calculated cells.
### Target audience
Users running CFD with fully resolved boundary layers and overset
### Proposal
That's my implementation, based on tips from @Mattijs
[cellVolumeWeightPushFront.7z](/uploads/041f6d2794792adc8add448c5ee60105/cellVolumeWeightPushFront.7z)
### What does success look like, and how can we measure that?
The influence of the "push" parameter can be seen in the following comparison of a two-blade cycloidal rotor simulation.
Here the captions refer to
- pushAndRelax: pushed a the inner interpolation interface (the hole) by 24 steps and relaxed the interpolation interface to make it approximately 4 cells thick on interfaces (hole and overset) using the `nPushFront 24;` and `layerRelax 0.25;` lines in fvSchemes oversetInterpolation dictionary
- pushNoRelax: WARNING: RAN WITHOUT PUSH pushed but not relaxation, thus `layerRelax 1;` **<-- I'll update this post when I rerun the case with proper push**
- noPush: layer relaxation but no push
- noPushNoRelax: no layer relaxation and no push
All other parameters for these 4 examples are maintained identical. The most flagrant differences are for vorticity (the wave at the interface) and for turbulent viscosity nut (the better preserved field through the interface)
![vortComp](/uploads/e45a038ac3c9fcbf33f4f8a77c961946/vortComp.jpg)
![pComp](/uploads/9821c94f9944c55c0f86d0ba600cb468/pComp.jpg)
![nutComp](/uploads/eccd9d04f591008b7c528f4a0b65bca8/nutComp.jpg)
And the following show how the calculated (blue), interpolated (white) and hole (red) cells are distributed. Both left and right airfoils have the same distribution, but I've removed the calculated cells on the right airfoil (component) mesh to show the background mesh.
![cellTypeComp](/uploads/959b50635af5c475a2fe685930c41d8f/cellTypeComp.jpg)
### Links / references
I think most overset codes do keep the interpolation far from the wall and also in a zone where the cell sizes roughly match.
### Funding
Not necessaryhttps://develop.openfoam.com/Development/openfoam/-/issues/1713allow redirect of Warnings to stderr2020-05-26T05:39:14ZMark OLESENallow redirect of Warnings to stderrIf running without banners we set infoDetailLevel to suppress stdout, or use stderr instead (cf. issues #722, #893).
However WarningInFunction etc still land on stdout!
Instead of introducing yet another message stream, hijack the infoD...If running without banners we set infoDetailLevel to suppress stdout, or use stderr instead (cf. issues #722, #893).
However WarningInFunction etc still land on stdout!
Instead of introducing yet another message stream, hijack the infoDetailLevel for redirecting warnings to stderr for these cases.v2006Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/282Allow specific restart time for field averaging.2017-01-02T12:24:43ZMark OLESENAllow specific restart time for field averaging.Can currently have a periodic restart, but for simulations with a known run-up, it can be useful to have a specific time to restart the averaging.Can currently have a periodic restart, but for simulations with a known run-up, it can be useful to have a specific time to restart the averaging.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3099Allow time-dependent diskDir in actuationDiskSource2024-02-13T20:25:51ZPete BachantAllow time-dependent diskDir in actuationDiskSourceWanted to throw this out there because I am going to start working on it, in case anyone can point me to a quick way to do this. My best guess thus far is to convert the `diskDir_` member from a `vector` to a `Function1`.Wanted to throw this out there because I am going to start working on it, in case anyone can point me to a quick way to do this. My best guess thus far is to convert the `diskDir_` member from a `vector` to a `Function1`.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/899Allrun-*2021-07-06T13:04:11ZPrashant SonakarAllrun-*We have following with Allrun-*
- ./incompressible/icoFoam/cavityMappingTest/Allrun-parallel
- ./incompressible/pimpleFoam/RAS/oscillatingInletACMI2D/Allrun-parallel
- ./multiphase/interIsoFoam/damBreak/Allrun-parallel
- ./lagrangian/coa...We have following with Allrun-*
- ./incompressible/icoFoam/cavityMappingTest/Allrun-parallel
- ./incompressible/pimpleFoam/RAS/oscillatingInletACMI2D/Allrun-parallel
- ./multiphase/interIsoFoam/damBreak/Allrun-parallel
- ./lagrangian/coalChemistryFoam/simplifiedSiwek/Allrun-parallel
- ./lagrangian/simpleReactingParcelFoam/verticalChannel/Allrun-parallel
- ./lagrangian/reactingParcelFoam/hotBoxes/Allrun-parallel
- ./mesh/foamyHexMesh/mixerVessel/Allrun-`pre`
- ./mesh/foamyHexMesh/mixerVessel/Allrun-`simulation`
- ./mesh/foamyHexMesh/blob/Allrun-parallel
- ./mesh/foamyHexMesh/flange/Allrun-parallel
- ./mesh/stitchMesh/simple-cube1/Allrun-`args`
- ./mesh/foamyQuadMesh/OpenCFD/Allrun-`rhoCentralFoam`
- ./heatTransfer/chtMultiRegionSimpleFoam/heatExchanger/Allrun-parallel
- ./heatTransfer/chtMultiRegionSimpleFoam/jouleHeatingSolid/Allrun-parallel
- ./heatTransfer/chtMultiRegionSimpleFoam/multiRegionHeaterRadiation/Allrun-parallel
- ./heatTransfer/chtMultiRegionFoam/windshieldCondensation/Allrun-parallel
- ./heatTransfer/chtMultiRegionFoam/snappyMultiRegionHeater/Allrun-`serial`
- ./heatTransfer/chtMultiRegionFoam/snappyMultiRegionHeater/Allrun-parallel
- ./heatTransfer/chtMultiRegionFoam/windshieldDefrost/Allrun-parallel
- ./heatTransfer/chtMultiRegionFoam/externalSolarLoad/Allrun-parallel
- ./finiteArea/sphereSurfactantFoam/sphereTransport/Allrun-parallel
And many formats with Allrun.*
While the foamRunTutorials contain call to
- Allrun
- Alltest
- Allrun-parallel
- Allrun-optional (no such file nor doing anything at the moment!)
Can we formalize the names and give priority to Allrun-parallel than Allrun (serial version) ?
@andy @Mattijs @mark @Sergiohttps://develop.openfoam.com/Development/openfoam/-/issues/387'Allrun' script in vofToLagrangian is not working2018-05-29T05:39:49ZAdmin'Allrun' script in vofToLagrangian is not workingThe Allrun script doesn't work for this group of folders. The error is:
Error: unable to find Lagrangian data in case ../eulerianInjection/processor0
Restore 0/ from 0.orig/
Error: unable to find Lagrangian data in case ../eulerianInje...The Allrun script doesn't work for this group of folders. The error is:
Error: unable to find Lagrangian data in case ../eulerianInjection/processor0
Restore 0/ from 0.orig/
Error: unable to find Lagrangian data in case ../eulerianInjection/processor0
I also do not understand how this solver actually works, or what it is supposed to do. Is there any better information on it? I'm running this on docker.https://develop.openfoam.com/Development/openfoam/-/issues/2515All species from phase are losing mass on interfaceCompositionPhaseChangeMult...2024-01-10T10:59:47ZCássio AzevedoAll species from phase are losing mass on interfaceCompositionPhaseChangeMultiphaseSystemAll species from biomass (particles) are "evaporated" (fibras.particles and H2O.particles into H2O.gas) simultaneusly insted of only H2O.particles.
I'm using the multiphaseEulerFoam solver in Openfoam8.
[phaseProperties](/uploads/89089...All species from biomass (particles) are "evaporated" (fibras.particles and H2O.particles into H2O.gas) simultaneusly insted of only H2O.particles.
I'm using the multiphaseEulerFoam solver in Openfoam8.
[phaseProperties](/uploads/89089d5861aa7a52029f1d704b6551ee/phaseProperties)
[thermophysicalProperties.gas](/uploads/b48930324b73cf847474e519389b6525/thermophysicalProperties.gas)
[thermophysicalProperties.particles](/uploads/cdde465e7fda4d865b522c094d93695c/thermophysicalProperties.particles)https://develop.openfoam.com/Development/openfoam/-/issues/1944alphaEqn is missing alphac term in MPPICInterFoam2021-07-07T10:46:38Zutkan CaliskanalphaEqn is missing alphac term in MPPICInterFoamalphac should be added in line 106 of alphaEqn.H in MPPICInterFoam solver.
There is another note to this solver with the usage of MULESCorr during simulations. I think alpha field is not correctly solved without MULESCorr. Without MULE...alphac should be added in line 106 of alphaEqn.H in MPPICInterFoam solver.
There is another note to this solver with the usage of MULESCorr during simulations. I think alpha field is not correctly solved without MULESCorr. Without MULESCorr, twoPhasePachuka tutorial crashes at about 0.9s. The issue can be reproduced on twoPhasePachuka case by commenting out MULESCorr in fvSolution, and changing maxCo and maxAlphaCo to 0.5.Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/684alphatJayatillekeWallFunction "k field not found" issue for the SpalartAllmar...2018-03-14T17:25:48ZAdminalphatJayatillekeWallFunction "k field not found" issue for the SpalartAllmaras turbulence modelHi, I am testing buoyantBoussinesqSimpleFoam using the tutorial case: hotRoom. I noticed that the alphatJayatillekeWallFunction (for the alphat field) implementation requires k field which is not provided in the SpalartAllmaras turbulenc...Hi, I am testing buoyantBoussinesqSimpleFoam using the tutorial case: hotRoom. I noticed that the alphatJayatillekeWallFunction (for the alphat field) implementation requires k field which is not provided in the SpalartAllmaras turbulence model.
Basically, if you run the case I uploaded, you can see warnings: "k field not found, return 0" in the flow log. I then checked the alphat wall values which were **all zeros (not right!)**.
If I run the hotRoom case with the default kEpsilon model, the alphat wall field values are right.
Could you please look up the problem? Thanks very much in advance!
[hotRoom.tar.gz](/uploads/238ca977ab5a08d3eca226def3d17852/hotRoom.tar.gz)https://develop.openfoam.com/Development/openfoam/-/issues/1941Alpha.water/particles behavior in multiple rotating frame2021-07-18T10:16:49ZRiccardo RossiAlpha.water/particles behavior in multiple rotating frameI've been working lately on the simulation of solid separation from a liquid in a rotating machine.
During some basic testing based on the mixerVessel tutorial using MPPICInteFoam, it seems that while the water volume fraction is convec...I've been working lately on the simulation of solid separation from a liquid in a rotating machine.
During some basic testing based on the mixerVessel tutorial using MPPICInteFoam, it seems that while the water volume fraction is convected by the relative velocity (left in video attached) the particles positions are updated based on the absolute velocity (right in the video).
I'm still trying to wrap my head around the proper modeling needed by the actual physics of the device, particularly concerning the MRF approach as opposed to using AMI, but It would be great to have some feedback on this.
[mixerVessel.avi](/uploads/215ce117a0537c803c57cdf1726ace03/mixerVessel.avi)https://develop.openfoam.com/Development/openfoam/-/issues/2777ambigous conversion for autoPtr<bool>2023-06-13T13:24:14ZMark OLESENambigous conversion for autoPtr<bool>The `autoPtr` currently has different casting types. Eg,
```
explicit operator bool() const noexcept;
operator const T&() const;
```
Consider the following:
```
autoPtr<bool> something;
if (something) ...
```
This may *either* imply th...The `autoPtr` currently has different casting types. Eg,
```
explicit operator bool() const noexcept;
operator const T&() const;
```
Consider the following:
```
autoPtr<bool> something;
if (something) ...
```
This may *either* imply that the `operator bool` is invoked (testing for existence of the pointer), or the `operator const T&` is invoked (returning the value of the pointer).
The casting to type is not particularly desirable, but still supported with `#define Foam_autoPtr_castOperator` in order to handle legacy code.
Current best fix is to replace with `Switch`.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/413AMI debug information does not include patch name; makes multi-AMI cases hard...2020-06-16T15:57:33ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comAMI debug information does not include patch name; makes multi-AMI cases hard to debugmoveDynamicMesh -checkAMI
checkMesh -allGeometry
write the AMI weight fields without the actual patch name so with multiple AMIs it overwrites the info.moveDynamicMesh -checkAMI
checkMesh -allGeometry
write the AMI weight fields without the actual patch name so with multiple AMIs it overwrites the info.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2275AMI inconsistent with mapped 'nearestPatchFaceAMI'2021-12-23T16:32:52ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comAMI inconsistent with mapped 'nearestPatchFaceAMI'<!--
*** 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 -->
`mapped` patch types support `AMI` type interpolation. They construct AMI from a dictionary but then don't use the AMI output - instead writing it themselves. This leads to inconsistencies.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
blockMesh with e.g.
```
type mappedWall;
inGroups 1 ( wall );
sampleMode nearestPatchFaceAMI;
requireMatch false;
```
This will not output the `requireMatch` override.
### 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
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906|v1912|v2006|v2012|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2108
### 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
-->
Use AMI to output itself.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2933AMIInterpolation::append has many list resizing2023-12-21T15:58:32ZMark OLESENAMIInterpolation::append has many list resizingIn [AMIInterpolation::append](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/meshTools/AMIInterpolation/AMIInterpolation/AMIInterpolation.C#L851) the updated maps are constructed by append/resizing two labelList entr...In [AMIInterpolation::append](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/meshTools/AMIInterpolation/AMIInterpolation/AMIInterpolation.C#L851) the updated maps are constructed by append/resizing two labelList entries.
This initial bookkeeping could be easily handled as a set of labelRanges. For example,
```
labelList mapMap, newMapMap;
{
List<labelRange> mapMapRanges(srcSubMap.size());
List<labelRange> newMapMapRanges(srcSubMap.size());
label total = 0;
label total1 = 0;
label total2 = 0;
forAll(srcSubMap, proci)
{
const label len1 = srcConstructMap[proci].size();
const label len2 = newSrcConstructMap[proci].size();
mapMapRanges[proci] = labelRange(total, len1);
total += len1;
total1 += len1;
newMapMapRanges[proci] = labelRange(total, len2);
total += len2;
total2 += len2;
}
mapMap.resize(total1);
newMapMap.resize(total2);
total = 0;
for (const labelRange& range : mapMapRanges)
{
const label beg = range.start();
const label len = range.size();
labelList::subList slice(mapMap.slice(total, len);
ListOps::identity(slice, beg);
total += len;
}
total = 0;
for (const labelRange& range : newMapMapRanges)
{
const label beg = range.start();
const label len = range.size();
labelList::subList slice(newMapMap.slice(total, len);
ListOps::identity(slice, beg);
total += len;
}
}
```https://develop.openfoam.com/Development/openfoam/-/issues/906AMIInterpolation uses non-assigned magSf in parallel2018-07-03T10:40:07ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comAMIInterpolation uses non-assigned magSf in parallelMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://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.com