Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-04-14T19:40:05Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2028AABBTree addressing is incorrect2021-04-14T19:40:05ZAndrew HeatherAABBTree addressing is incorrectThe AABBTree correctly creates a set of bounding boxes for, e.g. faces and cells - but the object addressing associated to each box is incorrect.The AABBTree correctly creates a set of bounding boxes for, e.g. faces and cells - but the object addressing associated to each box is incorrect.v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2616AABBTree can recurse indefinitely2022-11-24T12:21:09ZMark OLESENAABBTree can recurse indefinitelySince the AABB boxes overlap, it is possible that after splitting a node there is so much excess that the left/right almost entirely overlap or that the splitting is actually ineffective. In this case need to stop there, otherwise it wil...Since the AABB boxes overlap, it is possible that after splitting a node there is so much excess that the left/right almost entirely overlap or that the splitting is actually ineffective. In this case need to stop there, otherwise it will recurse indefinitely.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2197aarch64/debian package/docker image OF21062021-09-10T12:00:23ZGiuseppe Giaquintoaarch64/debian package/docker image OF2106### Functionality to add/problem to solve
Some day ago I build a docker image for linux/arm64 for my M1 mac, but it was a real pain because there are no debian packages with precompiled binaries so I would ask if it was possible to add ...### Functionality to add/problem to solve
Some day ago I build a docker image for linux/arm64 for my M1 mac, but it was a real pain because there are no debian packages with precompiled binaries so I would ask if it was possible to add such debian package and make an official docker image for arm64.
### Links / references
[my docker images](https://hub.docker.com/repository/docker/giuseppegq20/openfoam2106)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2939Abnormal interface produced by snappyHexMesh2023-08-14T11:13:29ZKai WangAbnormal interface produced by snappyHexMesh<!--
*** 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
As shown in the attached example, for multi-region mesh, gap and not conformal interface is generated by the first 2 steps of snappyHexMesh at one edge of the solid.
### Steps to reproduce
Running the attached example will reproduce the issue. Both serial or parallel run gives the same result.
<!-- How one can reproduce the issue - this is very important -->
### Example case
[learnSHM501-report.zip](/uploads/d5eb8d061db6f41775150e95a2863099/learnSHM501-report.zip) As a multi-region case, a solid is embedded in a fluid. They are both cylinders and have the same axis while the fluid is larger and encompasses the solid completely. Their stl files only contains their respective outer surfaces, i.e. the stl file of the fluid does not include the interface between the solid and fluid. Only the stl of solid contains the interface between fluid and solid.
[learnSHM501-single.zip](/uploads/3440c014ae105a06176f7e0fde1f364a/learnSHM501-single.zip) Another trial by following the workflow of cpuCabinet in tutorial of v2212 is performed, i.e. enclose both the fluid and solid in a single stl file and modify the snappyHexMeshDict correspondingly. However, the same issue is generated.
<!--
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?
Small gap and not conformal interface is generated around one edge of the solid, while the other edge is good. In paraview, there is a patch named /fluid/patch/solid with abnormal shape, i.e. very thin and has redundant element at the abnormal edge. For the current example, this issue only occurs when the background element size equals to special value, i.e. background element size = 4 m reproduces this issue, while 2, 2.5, 3, 5, 6, 10 m gives perfect interface at both edges. nCellZoneErodeIter=-1 leads snappyHexMesh crash while with nCellZoneErodeIter=1 and 2 the issue remains.
### What is the expected *correct* behavior?
Hope the mesh around interface perfect for arbitrary background element size.
### Relevant logs and/or images
A log file is attached[log.snappyHexMesh](/uploads/a634db3594f114c291f71f03e8a7c6fd/log.snappyHexMesh).
The following image shows the small gap and interface with not conformal mesh.
![notConformalInterface](/uploads/6e089e3c5469bd7cd5832aab98d333e7/notConformalInterface.png)
The following image shows the shape of abnormal patch and its name.
![abnormalPatch](/uploads/b2eeb2a33daf39dcdead52c5b13f9a28/abnormalPatch.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
- OpenFOAM version :v2212 and v2206
- Operating system :ubuntu 22.04 via Windows WSL. Windows version: 10 Ver 21H2. WSL: v1.2.5.0
- Hardware info :2x AMD EPYC 7302
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/2550Abnormal velocity near the wall on overset mesh2022-08-13T08:45:54Zgrace wAbnormal velocity near the wall on overset mesh<!--
*** 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 tried to use the developed version(feature-overset-couplepatch) to simlulate a wall-contact problem for piston-like flow. The object in this case has no motion (it is set by zero amplitude of periodic motion) so that the pressure should be constant and velocity is zero on both sides of the object. However, a false velocity near the wall contact area is computed. Similar phenomena occurs when the amplitude is set non-zero(e.g. 0.2) for periodic motion.
The abnormal velocity is next to the porous cell. The velocity from the donor may be ill-calculated in this region.
### 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
-->
Here is the case file.
[wallcontact-zeromotion.zip](/uploads/6b49113b64c0d2142f1d67d8076a66bb/wallcontact-zeromotion.zip)
### What is the current *bug* behaviour?
<!-- What actually happens -->
The abnormity of the velocity near the wall corner occurs at the very first timestep and it is increased with the time step.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The velocity near the wall corner should be zero.
### Relevant logs and/or images
Attach here is the results from the first timestep.
![celltype](/uploads/fe135b065002206a77ffa07c59c21661/celltype.png)
![U](/uploads/998363489f88d339f6ca676d84c629f2/U.png)
![p](/uploads/cd0f25cff44a8162ad8223352c2ea321/p.png)
![U-threshold](/uploads/504854ea8e675cab7d2cb25ee436f1aa/U-threshold.png)
![p-threshold](/uploads/90f4a928b64dfc775fb8574787fe6c10/p-threshold.png)
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
Courant Number mean: 0.671294 max: 0.75
Time = 0.01
inverseDistance : detected 2 mesh regions
zone:0 nCells:1875 voxels:(400 400 1) bb:(-0.5 -0.5 0) (0.5 0.5 0.05)
zone:1 nCells:501 voxels:(400 400 1) bb:(-0.5 -0.5 0) (0.5 0.5 0.05)
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Starting hole flood filling
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Starting hole cells : 97
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Marked internal hole boundaries : 143
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Marked all hole boundaries : 143
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Determined regions : 12
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Done local analysis
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Converted stencil into compact form
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Gathered region type
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Interpolated region type
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Determined regions changed : 0
void Foam::cellCellStencils::inverseDistance::findHoles(const Foam::globalIndex&, const Foam::fvMesh&, const labelList&, const labelListList&, Foam::labelList&) const : Finished hole flood filling : 0
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2112 feature-overset
- Operating system :ubuntu 20.04
- Hardware info :
- Compiler :gcc 9
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
In stencilWeights function, the inverse distance is used to calculate the weights of donor. It may need to consider the potential contribution from porous cell, e.g., the interpolate cell next to the porous cell in this case.
void Foam::cellCellStencils::inverseDistance::stencilWeights
(
const point& sample,
const pointList& donorCcs,
scalarList& weights
) const
{
// Inverse-distance weighting
weights.setSize(donorCcs.size());
scalar sum = 0.0;
forAll(donorCcs, i)
{
scalar d = mag(sample-donorCcs[i]);
if (d > ROOTVSMALL)
{
weights[i] = 1.0/d;
sum += weights[i];
}
else
{
// Short circuit
weights = 0.0;
weights[i] = 1.0;
return;
}
}
forAll(weights, i)
{
weights[i] /= sum;
}
}
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/944aborted sourcing of etc/bashrc causes problems2018-07-20T13:15:11ZMark OLESENaborted sourcing of etc/bashrc causes problemsIf the sourcing of the etc/bashrc is somehow aborted part way through, the `WM_SHELL_FUNCTIONS` can be left set.
This causes subsequent sourcing to fail, since it undefines the functions prior to use!If the sourcing of the etc/bashrc is somehow aborted part way through, the `WM_SHELL_FUNCTIONS` can be left set.
This causes subsequent sourcing to fail, since it undefines the functions prior to use!Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/472about the implementations of mass transfer induced momentum transfer in react...2019-01-08T14:43:16ZAdminabout the implementations of mass transfer induced momentum transfer in reactingEulerFoamHello,
I am trying to understand the Openfoam 3.0.1 implementations of momentum transfer caused by the mass transfer. The source file is:
HeatAndMassTransferPhaseSystem.C and HeatAndMassTransferPhaseSystem.H.
There are following lines...Hello,
I am trying to understand the Openfoam 3.0.1 implementations of momentum transfer caused by the mass transfer. The source file is:
HeatAndMassTransferPhaseSystem.C and HeatAndMassTransferPhaseSystem.H.
There are following lines in the function Foam::HeatAndMassTransferPhaseSystem<BasePhaseSystem>::momentumTransfer() const:
` const volScalarField dmdt(this->dmdt(pair));
const volScalarField dmdt21(posPart(dmdt));
const volScalarField dmdt12(negPart(dmdt));
*eqns[pair.phase1().name()] += dmdt21*U2 - fvm::Sp(dmdt21, U1); // gas
*eqns[pair.phase2().name()] -= dmdt12*U1 - fvm::Sp(dmdt12, U2); // coal
`
In my case, it is pulverized coal combustion. So coal particle (phase 2 here, dispersed phase) is dispersed in the flow (phase 1 here, continuous phase). I have the questions about the source terms for the momentum equations for phases 1 and 2.
I think mathematically, the source term for phase 1 (gas phase) can be written as: dmdt21*U21 - dmdt12*U12. For phase 2(coal phase ), it is dmdt12*U12 - dmdt21*U21. The sum of them is zero.
So now let us look at the the implementation in OpenFOAM 3.0.1 and the codes are given above. So dmdt21 is positive, while dmdt 12 is always negative. Here I think dmdt21 means that the mass is from phase 2 (coal particle) to phase 1 (gas phase). dmdt12 means that the mass is from phase 1 (gas phase) to phase 2 (coal particle phase). Why not write the 4th and 5th lines of the above codes in the following way?
`
*eqns[pair.phase1().name()] += dmdt21*U2 - fvm::Sp(dmdt12, U1); // gas
*eqns[pair.phase2().name()] -= dmdt12*U1 - fvm::Sp(dmdt21, U2); // coal
`
I am confused about this issue. Can you give me some explanations about it? Please help to point out if I am making some mistakes about the above understanding. Thanks.
NB: physically, the net mass transfer is always from coal particle to gas phase, through devolatilization and char combustion processes.
best regards,
huangweihttps://develop.openfoam.com/Development/openfoam/-/issues/262Absolute third-party paths in wmkdep, possible false positive on sed2016-11-07T06:27:23ZMark OLESENAbsolute third-party paths in wmkdep, possible false positive on sedAlso reported as http://bugs.openfoam.org/view.php?id=2283
In the wmake rules 'transform', the sed expression is missing a beginning anchor and a trailing slash , which makes it slightly susceptible to a false substitutions.
Additional...Also reported as http://bugs.openfoam.org/view.php?id=2283
In the wmake rules 'transform', the sed expression is missing a beginning anchor and a trailing slash , which makes it slightly susceptible to a false substitutions.
Additionally, any dependencies within ThirdParty retain their absolute path and are not resolved to `$WM_THIRD_PARTY_DIR`.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/476Absorptivity in constant/boundaryRadiationProperties (e.g. hotRadiationRoom)2017-05-18T16:12:16ZAdminAbsorptivity in constant/boundaryRadiationProperties (e.g. hotRadiationRoom)I guess the absorptivity in constant/boundaryRadiationProperties not to be used in this case.
I invalidated it and then executed this case, but no problems occurred.
Is this parameter really necessary to execute this case?
--
...I guess the absorptivity in constant/boundaryRadiationProperties not to be used in this case.
I invalidated it and then executed this case, but no problems occurred.
Is this parameter really necessary to execute this case?
--
Build: plus- e 6 c b e 0 b 1 1 9 2 3, v1606+https://develop.openfoam.com/Development/openfoam/-/issues/1943Accessing field in codedSource with codeCorrect2020-12-14T14:40:37ZCarlos Peña-MonferrerAccessing field in codedSource with codeCorrectHi,
The documentation for [`codedSource`](https://www.openfoam.com/documentation/guides/latest/api/classFoam_1_1fv_1_1codedSource.html#details) mentions the following arguments:
- codeCorrect: field
- codeAddSup: eqn, fieldi
- codeCons...Hi,
The documentation for [`codedSource`](https://www.openfoam.com/documentation/guides/latest/api/classFoam_1_1fv_1_1codedSource.html#details) mentions the following arguments:
- codeCorrect: field
- codeAddSup: eqn, fieldi
- codeConstrain: eqn, fieldi
I can use `eqn` and `fieldi` from codeAddSup, however when trying to use `field` from `codeCorrect` it complains about not being declared. Is there something missing in the following code?
```
codedSource
{
type vectorCodedSource;
selectionMode all;
fields (U);
name testing;
codeCorrect
#{
vectorField& testField = field;
#};
codeAddSup
#{
vectorField& fieldSource = eqn.source();
label fieldLabel = fieldi;
#};
codeConstrain
#{
#};
}
```
Thanks.https://develop.openfoam.com/Development/openfoam/-/issues/884access to invalid coordinateRotation after move assignment2018-06-26T05:56:09ZMark OLESENaccess to invalid coordinateRotation after move assignmentThe coordinateSystem move assignment leaves the coordinateRotation undefined. This is OK, and consistent with various move semantics, but the transfer also forces a clear() on the old object. This causes an invalid access to the autoPtr.The coordinateSystem move assignment leaves the coordinateRotation undefined. This is OK, and consistent with various move semantics, but the transfer also forces a clear() on the old object. This causes an invalid access to the autoPtr.v1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/411acmi does not report number of fully covered/uncovered faces2018-05-29T05:39:48ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comacmi does not report number of fully covered/uncovered facesWould be nice to see how many faces are being blended.Would be nice to see how many faces are being blended.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2380ACMI in combination with highAspectRatio crash2022-02-24T17:38:31ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comACMI in combination with highAspectRatio 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
ACMI with highAspectRatio fvGeometryScheme crashes
### Steps to reproduce
<!-- Summarize the bug encountered concisely -->
Tutorial incompressible/pimpleFoam/RAS/oscillatingInletACMI2D. Enable `highAspectRatio` geometry scheme (see attached). Run
`checkMesh`:
```
Checking basic cellZone addressing...
CellZone Cells Points VolumeBoundingBox
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigSegv::sigHandler(int) at ??:?
#2 ? in /lib64/libpthread.so.0
#3 ? at ??:?
#4 ? at ??:?
#5 __libc_start_main in /lib64/libc.so.6
#6 ? at /home/abuild/rpmbuild/BUILD/glibc-2.31/csu/../sysdeps/x86_64/start.S:122
```
### 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 (or develop)
<!--
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
-->
[fvSchemes](/uploads/16d7a2758794efa7a067aa54d538ce82/fvSchemes)Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/3125ACMI - unallocated autoPtr error when redistributing the mesh2024-03-28T14:52:58ZPrashant SonakarACMI - unallocated autoPtr error when redistributing the meshAttached case reproducing error in 2312 as well as develop line.
The case works when adding `AMIMethod nearestFaceAMI;` within blockMeshDict for ACMI definition.
[oscillatingInletACMI2D.tgz](/uploads/d484dd4e2a967211fb99cb2eac3b6...Attached case reproducing error in 2312 as well as develop line.
The case works when adding `AMIMethod nearestFaceAMI;` within blockMeshDict for ACMI definition.
[oscillatingInletACMI2D.tgz](/uploads/d484dd4e2a967211fb99cb2eac3b6f49/oscillatingInletACMI2D.tgz)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1819actuationDiskSource: a missing tab2020-09-07T16:28:39ZHassan KassemactuationDiskSource: a missing tabHello,
There is a missing ``tab`` in the output stream of ``actuationDiskSource`` after ``Ct``.
Please check [Line 241](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/fvOptions/sources/derived/actuationDiskSource/ac...Hello,
There is a missing ``tab`` in the output stream of ``actuationDiskSource`` after ``Ct``.
Please check [Line 241](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/fvOptions/sources/derived/actuationDiskSource/actuationDiskSourceTemplates.C#L241) in `actuationDiskSourceTemplates.C`.
It should be
```C++
os << Uref << tab << Cp << tab << Ct << tab
<< Udisk << tab << CpStar << tab << CtStar << tab << T << tab << P
<< endl;
```
Also, I'm not sure if last `tab` in [line 130](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/fvOptions/sources/derived/actuationDiskSource/actuationDiskSourceTemplates.C#L130) is necessary according to OF-style.
Sorry for reporting such small issue.v2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1828actuationDiskSource: Usage and description2020-11-13T09:23:41ZHassan KassemactuationDiskSource: Usage and descriptionHello,
According to the usage description of the ``actuationDiskSource``, ``diskDir`` is Surface-normal vector of the actuator disk pointing upstream. This contradicts the ``turbineSiting`` tutorial where ``diskDir`` is pointing ``(1 0 ...Hello,
According to the usage description of the ``actuationDiskSource``, ``diskDir`` is Surface-normal vector of the actuator disk pointing upstream. This contradicts the ``turbineSiting`` tutorial where ``diskDir`` is pointing ``(1 0 0)`` which the same direction as the flow (downstream). In order to double check, I ran the tutorial four times using the two available force models with ``diskDir (1 0 0)`` (downstream) and ``diskDir (-1 0 0)`` (upstream). The attached figure shows the results along horizontal line through the centre of the ``disk1``. It clear from the pressure that downstream is the right direction. This has been done using ``OpenFOAM-v2006``.
![compare_disks](/uploads/124c335c5864f36ffe0aef5b660c9441/compare_disks.png)
Anther point which sounds confusing is this comment
```cpp
//- Flag for body forces to act as a source (true) or a sink (false)
label sink_;
```
From what I see in the code and OF sign convention as far as I understand, true ``sink_`` leads to positive term which acts as sink (momentum extraction) and vice versa. Hence, the comment isn't accurate unless I'm missing something here.
Thanks for your effort and continues support,
Best wishes,
Hassanv2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1961adapt/integrate PDRfitMesh2020-12-21T08:22:52ZMark OLESENadapt/integrate PDRfitMesh- serves as a pre-processor for PDRblockMesh. Scans the obstacles and helps determine an initial cell distribution for creating a PDRblockMeshDict
cross-ref: EP1247
@Pratap- serves as a pre-processor for PDRblockMesh. Scans the obstacles and helps determine an initial cell distribution for creating a PDRblockMeshDict
cross-ref: EP1247
@PratapMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1348Adaptive mesh refinement fails when field relaxation is applied2019-12-09T22:37:29ZAdminAdaptive mesh refinement fails when field relaxation is applied<!--
*** 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 ...<!--
*** 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 -->
If field relaxation combined with adaptive mesh refinement are used together, a simulation will fail. The following error is produced:
```
GAMGPCG: Solving for p_rgh, Initial residual = 9.32957e-07, Final residual = 5.87573e-11, No Iterations 3
[1]
[1]
[1] --> FOAM FATAL ERROR:
[1] Field<scalar> f1(15738), Field<scalar> f2(15738) and Field<scalar> f3(8906)
for operation f1 = f2 - f3
[1]
[1] From function void Foam::checkFields(const Foam::UList<T>&, const Foam::UList<Key>&, const Foam::UList<Type3>&, const char*) [with Type1 = double; Type2 = double; Type3 = double]
[1] in file /home/gavin/code/OpenFOAM-plus/src/OpenFOAM/lnInclude/FieldM.H at line 76.
```
My code is on commit d9cbe69c81c9382a8f55d11673ea7260f5907a5c.
This can be easily reproduced. Just go to tutorials/multiphase/interFoam/RAS/motorBike, set nOuterCorrectors to 2, and add relaxation to any field.AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1621Add a "cellZoneAndDirection" mode to surfaceFieldValue FO (like fluxSummary)2020-05-07T22:02:48ZJustin GraupmanAdd a "cellZoneAndDirection" mode to surfaceFieldValue FO (like fluxSummary)### Functionality to add/problem to solve
The fluxSummary function object has a really useful mode called cellZoneAndDirection which takes a cellZone and a direction. This mode finds the interior faces of the faceZone associated with th...### Functionality to add/problem to solve
The fluxSummary function object has a really useful mode called cellZoneAndDirection which takes a cellZone and a direction. This mode finds the interior faces of the faceZone associated with the cellZone and then splits the faces by connected regions. It would be super useful to have a similar mode in the surfaceFieldValue function object so that we can auto split and monitor other fields across cellZone faces (like pressure drop for a porous zone).
### Target audience
Anyone with disconnected cellZone faces that want to monitor the disconnected regions separately. This is common for a porous zone that is surrounded by walls and only has an "inlet" and "outlet" to the zone. Right now pressure drop is difficult to monitor since snappyHexMesh by default puts the "inlet" and "outlet" faces of a cellZone into a single faceZone. TopoSet can be used to split the faceZone after the fact, but we could eliminate that step with this option.
### Proposal
Something like this is what I'd propose (i'm not even sure the direction is needed)...
```
fieldValue
{
type surfaceFieldValue;
libs ("libfieldFunctionObjects.so");
writeControl timeStep;
writeInterval 1;
regionType cellZoneAndDirection;
cellZoneAndDirection
(
(porous (0 0 -1))
);
operation weightedAverage;
weightField U;
fields
(
p
);
}
```
### What does success look like, and how can we measure that?
Being able to do what fluxSummary does with cellZones and splitting the faceZones by connected region, but instead of monitoring flux, have the ability to monitor pressure (or any other field) on each faceZone.
### Funding
Functionality technically already exists, just needs to be applied to surfaceFieldValue. I am not prepared to directly fund this feature request.https://develop.openfoam.com/Development/openfoam/-/issues/692add additional information in header of decomposedBlockData2024-01-10T16:23:36ZMark OLESENadd additional information in header of decomposedBlockDataWe already have a `blocks` entry, but it would be quite convenient for downstream users (eg, paraview) if we also could pass along the underlying data-type in an easy to find place.
Eg,
FoamFile
{
version 2.0;
...We already have a `blocks` entry, but it would be quite convenient for downstream users (eg, paraview) if we also could pass along the underlying data-type in an easy to find place.
Eg,
FoamFile
{
version 2.0;
format binary;
class decomposedBlockData;
blocks 4;
object U;
dataClass volVectorField;
}
At the moment it is a bit of a pain to get at this information.
Would it be useful to have this dataClass information present as `IOobject::headerDataClassName()` with it being identical to `IOobject::headerClassName()` when `dataClass` isn't present?Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com