Development issueshttps://develop.openfoam.com/groups/Development/-/issues2019-09-12T13:52:23Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1416MergeMeshes overset cell vertex messing2019-09-12T13:52:23ZMatej FormanMergeMeshes overset cell vertex messingBackground overset mesh created with SHM is nice and castellated.
Overset mesh is created with SHM. Mesh is nice cylinder and rather OK quality.
After the mergeMeshes the following happens
![Screenshot_2019-08-29_at_14.21.41](/uploads/...Background overset mesh created with SHM is nice and castellated.
Overset mesh is created with SHM. Mesh is nice cylinder and rather OK quality.
After the mergeMeshes the following happens
![Screenshot_2019-08-29_at_14.21.41](/uploads/96a08c28645462afa4811ea7fe385938/Screenshot_2019-08-29_at_14.21.41.png)
MergeMesh is NOT run in parallel. When renumbering meshes before merging, only one pierced cell is created, when not renumbering, more are created. Mesh has 8 mil. cells
@Mattijs @Sergiohttps://develop.openfoam.com/Development/openfoam/-/issues/314mergeOrSplitBaffles cannot operate on selected set of patches2018-05-29T05:39:49ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commergeOrSplitBaffles cannot operate on selected set of patchesmergeOrSplitBaffles can only operate on all boundary faces.mergeOrSplitBaffles can only operate on all boundary faces.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1759mergeOrSplitBaffles : not identiying -dict arguments2020-07-28T15:15:56ZPawan GhildiyalmergeOrSplitBaffles : not identiying -dict argumentsHello ,
when i am running mergeOrSplitBaffles, with -dict argument , it throw error with latest
v2006.
i.e
> mergeOrSplitBaffles -dict system/mergeOrSplitBafflesDict_boundary
>
> Expected 0 arguments but found 1
Regard...Hello ,
when i am running mergeOrSplitBaffles, with -dict argument , it throw error with latest
v2006.
i.e
> mergeOrSplitBaffles -dict system/mergeOrSplitBafflesDict_boundary
>
> Expected 0 arguments but found 1
Regards
PawanMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/381mergePatchFaces in multiphase/interDyMFoam/RAS/motorBike2018-05-29T05:39:49ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commergePatchFaces in multiphase/interDyMFoam/RAS/motorBikeMerging patch faces is switched on in the tutorial. It makes more sense to switch it on.Merging patch faces is switched on in the tutorial. It makes more sense to switch it on.https://develop.openfoam.com/Development/openfoam/-/issues/250Merge points with indirect list.2019-12-09T22:04:13ZMark OLESENMerge points with indirect list.Should be able to merge a subset of points (e.g. only those on boundaries). Adjust merge points parameters list to handle this.
@MattijsShould be able to merge a subset of points (e.g. only those on boundaries). Adjust merge points parameters list to handle this.
@MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1936Merge Request: Better C++ language server and Visual Studio Code support.2023-06-16T23:10:39ZVolker WeißmannMerge Request: Better C++ language server and Visual Studio Code support.Hello,
the OpenFOAM C++ source code is large and complicated. Code navigation tools like ccls can make it easier by providing a working "Go to Definition" function.
Therefore, I am suggesting applying the patch below to help setting up...Hello,
the OpenFOAM C++ source code is large and complicated. Code navigation tools like ccls can make it easier by providing a working "Go to Definition" function.
Therefore, I am suggesting applying the patch below to help setting up ccls with vscode and openfoam.
[mypatch8.patch](/uploads/192ba8dfb1a4212f797ee381f0c710aa/mypatch8.patch)
See https://openfoamwiki.net/index.php/HowTo_Use_OpenFOAM_with_Visual_Studio_Code for more information
(Yes I know, this should be a merge request, not an issue, but I cannot create merge requests)
For other OpenFOAM versions:
[bearOpenFOAM8.patch](/uploads/3501dca35d4a7fcac7a87575a2ae35ab/bearOpenFOAM8.patch)
[bearOpenFOAM7or6.patch](/uploads/5af73f59106cca0641402d3da450fa04/bearOpenFOAM7.patch)
Older version:
[mypatch7.patch](/uploads/682fd4076b0a95c8e4e618c0cccbea1d/mypatch7.patch)
[mypatch6.patch](/uploads/436492f72ca828ecefa35144352a43bf/mypatch6.patch)
[mypatch5.patch](/uploads/d7378dacddcbebb3f06074175048f42e/mypatch5.patch)
[mypatch4.patch](/uploads/294ee4158a7edb3b8642c85f4d778fd4/mypatch4.patch)
[mypatch3.patch](/uploads/40c2edc78aaf15bd07978324c01307b1/mypatch3.patch)
[mypatch2.patch](/uploads/fd3c3314ae7389852759f9d45f0e3f85/mypatch2.patch)
[mypatch.patch](/uploads/93664b4baf717d185f1e6fb4d64441a0/mypatch.patch)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/511mesa build failure in Ubuntu162017-06-29T08:14:56ZPawan Ghildiyalmesa build failure in Ubuntu16Hi Mark
I am compiling mesa in bash in Windows.
It has Ubuntu bash with following specification.
It fail at one point . See attached log .
Dstributor ID: Ubuntu.
Description: Ubuntu 16.04.2 LTS.
Release: 16.04 .
C...Hi Mark
I am compiling mesa in bash in Windows.
It has Ubuntu bash with following specification.
It fail at one point . See attached log .
Dstributor ID: Ubuntu.
Description: Ubuntu 16.04.2 LTS.
Release: 16.04 .
Codename: xenial
Some one too faced similar issue and provided work around ,
however I could not understand where to put it
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=528169Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1641Mesh Conversion - maximum mesh size for ccmToFoam and ccm26ToFoam2024-01-11T17:23:32Znolan gothMesh Conversion - maximum mesh size for ccmToFoam and ccm26ToFoamHello,
There appears to be a limit to the mesh size that can be successfully converted using the mesh conversion utilities, 'ccmToFoam' and 'ccm26ToFoam'.
I can provide both working and failing test cases.
Would you be interested in c...Hello,
There appears to be a limit to the mesh size that can be successfully converted using the mesh conversion utilities, 'ccmToFoam' and 'ccm26ToFoam'.
I can provide both working and failing test cases.
Would you be interested in collaborating to improve and update the utility?
Thank you for your time,
Nolan
gothne@ornl.govMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1071MeshObject uses objectRegistry foundObject followed by lookupObject2018-11-20T14:12:38ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMeshObject uses objectRegistry foundObject followed by lookupObjectSmall optimisation.Small optimisation.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/466mesh quality visualisation2017-06-29T20:38:04ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commesh quality visualisationTicket to output mesh quality parameters using checkMesh.Ticket to output mesh quality parameters using checkMesh.Version v1706Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/287mesh reader does not preserve physicalType2016-12-23T12:39:43ZMark OLESENmesh reader does not preserve physicalTypeThis is a very long-standing bug (Oct 2010), but obviously rarely noticed.This is a very long-standing bug (Oct 2010), but obviously rarely noticed.Version v1612Mark OLESENMark OLESEN2016-11-04https://develop.openfoam.com/Development/openfoam/-/issues/732meshStructure returns indices into local addressing2018-07-02T09:37:46ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commeshStructure returns indices into local addressingmeshStructure returns a cellToPatchFaceAddressing() which are indices into local addressing so will not be correct.meshStructure returns a cellToPatchFaceAddressing() which are indices into local addressing so will not be correct.https://develop.openfoam.com/Development/openfoam/-/issues/1935meshToMesh field mapping incorrect when mapping from tgt to src2020-11-26T01:16:19ZAndrew HeathermeshToMesh field mapping incorrect when mapping from tgt to srcThe `mapInternalTgtToSrc` incorrectly divert to `*SrcToTgt` routines instead of `*TgtToSrc`The `mapInternalTgtToSrc` incorrectly divert to `*SrcToTgt` routines instead of `*TgtToSrc`v2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/376meshToMesh - incorrect cutting patch addressing2019-12-09T22:04:15ZAdminmeshToMesh - incorrect cutting patch addressingcutting patches indices are derived by finding the patch name on the tgtRegion - this should be performed on the srcRegion. Also, there is no protection for the case that the patch is not found, where the patch index is set to -1.cutting patches indices are derived by finding the patch name on the tgtRegion - this should be performed on the srcRegion. Also, there is no protection for the case that the patch is not found, where the patch index is set to -1.Version v1706https://develop.openfoam.com/Development/openfoam/-/issues/2814mesh waves fail with processor + processorCyclc2023-06-26T13:32:03ZMark OLESENmesh waves fail with processor + processorCyclcWith processor + processorCyclic there are multiple patch connections between two processors: failsWith processor + processorCyclic there are multiple patch connections between two processors: failsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1159META: How does the Developer upgrade guide get filled?2019-06-28T09:46:15ZAdminMETA: How does the Developer upgrade guide get filled?Hello!
So, the developer upgrade guide is currently lagging behind, with the guide for 1806 "coming soon". My guess is that the guide is being composed after the release, which needs going through the introduced changes after the fact. ...Hello!
So, the developer upgrade guide is currently lagging behind, with the guide for 1806 "coming soon". My guess is that the guide is being composed after the release, which needs going through the introduced changes after the fact. A more efficient system, also leading to a better and more complete guide, would be to make it a live document where breaking API changes are registered upon commit. For each braking change one could add something like
ClassName Short description of the breaking change <Link to commit>
This would *really* make things easy for people writing stand-alone libraries since they can immediately see if their code is affected and how to address it. Hopefully, the overhead for the devs is not that large since breaking changes should not happen too often. Releasing the guide would amount to freezing the document upon the release of a new version of the software, sorting the list after the class name and adding a more detailed discussion of the most important changes.AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/232metisDecomp compile error2019-12-09T22:04:12ZAdminmetisDecomp compile errorWhen compiling OpenFOAM v1606, the following compilation error appears:
`metisDecomp.C:211:9: error: cannot convert ‘Foam::UList<float>::iterator {aka float*}’ to ‘real_t* {aka double*}’ for argument ‘9’ to ‘int METIS_PartGraphRecursi...When compiling OpenFOAM v1606, the following compilation error appears:
`metisDecomp.C:211:9: error: cannot convert ‘Foam::UList<float>::iterator {aka float*}’ to ‘real_t* {aka double*}’ for argument ‘9’ to ‘int METIS_PartGraphRecursive(idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, real_t*, real_t*, idx_t*, idx_t*, idx_t*)’`
`metisDecomp.C:230:9: error: cannot convert ‘Foam::UList<float>::iterator {aka float*}’ to ‘real_t* {aka double*}’ for argument ‘9’ to ‘int METIS_PartGraphKway(idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, idx_t*, real_t*, real_t*, idx_t*, idx_t*, idx_t*)’`
It seems that `REALTYPEWIDTH 64` in metis.h should correspond to `Field<scalar> processorWeights` in metisDecomp.C, while `REALTYPEWIDTH 32` corresponds to `Field<floatScalar> processorWeights`. So, in order to compile metisDecomp, I changed metisDecomp.C to have `Field<scalar>` instead of `Field<floatScalar>`(see below).
`$WM_THIRD_PARTY_DIR/platforms/linux64Gcc/metis-5.1.0/include/metis.h`
`#define REALTYPEWIDTH 64`
`$WM_PROJECT_DIR/src/parallel/decompose/metisDecomp/metisDecomp.C`
`Field<scalar> processorWeights`
For reference: this problem appears to be related to the bug report on the OpenFOAM fork's website: http://bugs.openfoam.org/view.php?id=2085.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1354Metis decomposition is not working using OpenFOAM-v19062019-07-08T18:49:33ZAdminMetis decomposition is not working using OpenFOAM-v1906Metis decomposition is not working using OpenFOAM-v1906
Steps to reproduce:
* compile metis
```
cd $WM_THIRD_PARTY_DIR
wget http://glaros.dtc.umn.edu/gkhome/fetch/sw/metis/metis-5.1.0.tar.gz
tar -xzf metis-5.1.0.tar.gz
rm metis-5.1.0.t...Metis decomposition is not working using OpenFOAM-v1906
Steps to reproduce:
* compile metis
```
cd $WM_THIRD_PARTY_DIR
wget http://glaros.dtc.umn.edu/gkhome/fetch/sw/metis/metis-5.1.0.tar.gz
tar -xzf metis-5.1.0.tar.gz
rm metis-5.1.0.tar.gz
cd $WM_PROJECT_DIR
./Allwmake -j -l
```
* modify decomposeParDict in twoSimpleRotors tutorial (OpenFOAM-v1906/tutorials/multiphase/overInterDyMFoam/twoSimpleRotors)
```
method metis;
```
* output
```
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v1906 |
| \\ / A nd | Web: www.OpenFOAM.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : v1906 OPENFOAM=1906
Arch : "LSB;label=32;scalar=64"
Exec : decomposePar -cellDist
Date : Jul 04 2019
Time : 09:16:22
Host : coastal2
PID : 118852
I/O : uncollated
Case : /home/u0109460/OpenFOAM/u0109460-v1906/run/twoSimpleRotors
nProcs : 1
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Overriding DebugSwitches according to controlDict
overset 0;
dynamicOversetFvMesh 0;
cellVolumeWeight 0;
Decomposing mesh region0
Create mesh
Calculating distribution of cells
Selecting decompositionMethod metis [3]
--> FOAM FATAL ERROR:
Attempted non-const reference to const object from a tmpNrc<N4Foam4ListIiEE>
From function T& Foam::tmpNrc<T>::ref() const [with T = Foam::List<int>]
in file /home/u0109460/OpenFOAM/OpenFOAM-v1906/src/OpenFOAM/lnInclude/tmpNrcI.H at line 234.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::error::abort() at ??:?
#2 Foam::metisDecomp::decomposeSerial(Foam::UList<int> const&, Foam::UList<int> const&, Foam::UList<double> const&, Foam::List<int>&) const at ??:?
#3 Foam::metisLikeDecomp::decomposeGeneral(Foam::UList<int> const&, Foam::UList<int> const&, Foam::UList<double> const&, Foam::List<int>&) const at ??:?
#4 Foam::metisLikeDecomp::decompose(Foam::polyMesh const&, Foam::Field<Foam::Vector<double> > const&, Foam::Field<double> const&) const at ??:?
#5 Foam::decompositionMethod::decompose(Foam::polyMesh const&, Foam::Field<Foam::Vector<double> > const&) const at ??:?
#6 Foam::decompositionMethod::decompose(Foam::polyMesh const&, Foam::Field<double> const&, Foam::List<bool> const&, Foam::PtrList<Foam::List<int> > const&, Foam::List<int> const&, Foam::List<Foam::Pair<int> > const&) const at ??:?
#7 Foam::decompositionMethod::decompose(Foam::polyMesh const&, Foam::Field<double> const&) const at ??:?
#8 ? in ~/OpenFOAM/OpenFOAM-v1906/platforms/linux64GccDPInt32Opt/bin/decomposePar
#9 ? in ~/OpenFOAM/OpenFOAM-v1906/platforms/linux64GccDPInt32Opt/bin/decomposePar
#10 ? in ~/OpenFOAM/OpenFOAM-v1906/platforms/linux64GccDPInt32Opt/bin/decomposePar
#11 __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
#12 ? in ~/OpenFOAM/OpenFOAM-v1906/platforms/linux64GccDPInt32Opt/bin/decomposePar
Aborted (core dumped)
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2795MGridGenGAMGAgglomeration does not build anymore2023-06-26T10:31:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMGridGenGAMGAgglomeration does not build anymore<!--
*** 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 -->
MGridGen agglomeration method does not build anymore
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Download&unpack MGridGen into `$WM_THIRDPARTY_DIR/`
move/softlink unpacked directory to the expected location (e.g. `ln -s ParMGridGen-master ParMGridGen-1.0`)
`./makeMGridGen`
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2212|v2206|v2112|v2106|v2012 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2212
- Operating system :
- Hardware info :
- Compiler :Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/834Micro change in nutUBlendedWallFunction?2020-06-12T17:34:59ZKutalmış BerçinMicro change in nutUBlendedWallFunction?Hi,
Please consider `Foam::nutTestUBlendedWallFunctionFvPatchScalarField::calcUTau`:
```c
tmp<scalarField> tuTaup(new scalarField(patch().size(), 0.0));
scalarField& uTaup = tuTaup.ref();
const scalarField& nutw = *this;
...Hi,
Please consider `Foam::nutTestUBlendedWallFunctionFvPatchScalarField::calcUTau`:
```c
tmp<scalarField> tuTaup(new scalarField(patch().size(), 0.0));
scalarField& uTaup = tuTaup.ref();
const scalarField& nutw = *this;
forAll(uTaup, facei)
{
scalar ut = sqrt((nutw[facei] + nuw[facei])*magGradU[facei]);
if (mag(ut) > ROOTVSMALL)
{
scalar error = GREAT;
label iter = 0;
while (iter++ < 10 && error > 0.001)
{
scalar yPlus = y[facei]*ut/nuw[facei];
scalar uTauVis = magUp[facei]/yPlus;
scalar uTauLog = kappa_*magUp[facei]/log(E_*yPlus);
scalar utNew = pow(pow(uTauVis, n_) + pow(uTauLog, n_), 1.0/n_);
error = mag(ut - utNew)/(ut + ROOTVSMALL);
ut = 0.5*(ut + utNew);
}
}
uTaup[facei] = ut;
}
return tuTaup;
```
Without sacrificing readability, wouldn't be possible to remove `new scalarField(patch().size(), 0.0)` and simplify the rest accordingly?
```c
const scalarField& nutw = *this;
tmp<scalarField> tuTaup = sqrt((nutw + nuw)*magGradU);
scalarField& uTaup = tuTaup.ref();
forAll(uTaup, facei)
{
if (mag(uTaup[facei]) > ROOTVSMALL)
{
scalar error = GREAT;
label iter = 0;
while (error > 0.001 && iter++ < 10)
{
scalar yPlus = y[facei]*uTaup[facei]/nuw[facei];
scalar uTauVis = magUp[facei]/yPlus;
scalar uTauLog = kappa_*magUp[facei]/log(E_*yPlus);
scalar utNew = pow(pow(uTauVis, n_) + pow(uTauLog, n_), 1.0/n_);
error = mag(uTaup[facei] - utNew)/(uTaup[facei] + ROOTVSMALL);
uTaup[facei] = 0.5*(uTaup[facei] + utNew);
}
}
}
return tuTaup;
```
Also, in `while (iter++ < 10 && error > 0.001)`, I observed for a typical channel case I run that `error > 0.001` becomes `False` quicker than `iter++ < 10`. Might be wiser to swap `error` and `iter`, so that `while` exits without testing `iter` redundantly when `error < 0.001`?v2006Kutalmış BerçinKutalmış Berçin