Development issueshttps://develop.openfoam.com/groups/Development/-/issues2019-12-09T22:37:28Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1270incorrect default location for project site binaries2019-12-09T22:37:28ZMark OLESENincorrect default location for project site binaries`FOAM_SITE_APPBIN` and `FOAM_SITE_LIBBIN` are still using WM_PROJECT_VERSION instead of FOAM_API`FOAM_SITE_APPBIN` and `FOAM_SITE_LIBBIN` are still using WM_PROJECT_VERSION instead of FOAM_APIMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1269possible regression in uniformFixedValuePointPatch?2019-04-08T15:04:14ZMark OLESENpossible regression in uniformFixedValuePointPatch?In tutorials/basic/overLaplacianDyMFoam/heatTransfer I'm getting some very odd output which I think could be related to this commit: 0987898f5c1678
I initially thought it might be related to the generic point patches since reconstructPa...In tutorials/basic/overLaplacianDyMFoam/heatTransfer I'm getting some very odd output which I think could be related to this commit: 0987898f5c1678
I initially thought it might be related to the generic point patches since reconstructPar was failing when fill-nan is set. The values it reconstructs for the pointDisplacement right1 boundary are scalars, not vectors.
Backtracking some more, it seems that the original decomposed fields are a bit *odd*.
In 1812:
processor0/0/pointDisplacement.right1
right1
{
type uniformFixedValue;
value nonuniform 0();
uniformValue constant (0 0 0);
}
In develop:
processor0/0/pointDisplacement.right1
right1
{
type uniformFixedValue;
uniformValue ( 0 0 0 );
}
At later times this looks different again. Eg, processor0/0.5/pointDisplacement.right1
1812:
right1
{
type uniformFixedValue;
value nonuniform 0();
uniformValue constant (0 0 0);
}
develop:
right1
{
type uniformFixedValue;
value nonuniform 0();
uniformValue nonuniform 0();
}
When this is reconstructed, the generic point patch process the entries quite badly. Even the output for `value` does not look correct.
@PrashantMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1268avoid use of gatherList (e.g. fvMeshDistribute)2019-11-08T07:11:42ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comavoid use of gatherList (e.g. fvMeshDistribute)### Functionality to add/problem to solve
Currently in the code it sometimes uses a gatherList to collect data from other processors. This becomes expensive for large numbers of processors.
### Proposal
Replace with an allToAll type ...### Functionality to add/problem to solve
Currently in the code it sometimes uses a gatherList to collect data from other processors. This becomes expensive for large numbers of processors.
### Proposal
Replace with an allToAll type wrapper.https://develop.openfoam.com/Development/openfoam/-/issues/1267The 'function object' does not write out the results of 'volFieldValue' if 's...2019-07-03T19:32:25ZAdminThe 'function object' does not write out the results of 'volFieldValue' if 'solidificationMeltingSource' is used.<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
After calculation using solidificationMeltingSource, the time change of the liquid phase (eg. sMS:alpha1 field) fails to written out by function object utility.
### Steps to reproduce
> $ buoyantPimpleFoam
>
> (after the end)
>
> $ buoyantPimpleFoma -postProcess
### Example case
After expanding this attached file, execute 'Allrun' script file!
[solidificationMeltingSourceTest.tar.gz](/uploads/556b79b4ce57806740507da6e5ce49f6/solidificationMeltingSourceTest.tar.gz)
### What is the current *bug* behaviour?
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
In case of the calculation simultaneously with solver
>volFieldValue meltingFranctions write:
>
> sum(PCM) of sMS1:alpha1 = 475.61726
>
>End
>
>(no problem)
---
When executed as post-processing
>volFieldValue meltingFranctions write:
>
> sum(PCM) of sMS1:alpha1 = 0
>
>
>End
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
OpenFOAM version :v1812
Operating system :ubuntu18.04
Compiler :gcc-7.3.0
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
-->https://develop.openfoam.com/Development/openfoam/-/issues/1266May need independent MPI initialize/finalize2019-04-11T14:39:59ZMark OLESENMay need independent MPI initialize/finalizeAs discussed with @Mattijs, but also of interest for @sbna
When Pstream initializes MPI, it checks for a previous initialization of MPI and skips if not required. It then also skips attaching transfer buffers. On finalize, it does simil...As discussed with @Mattijs, but also of interest for @sbna
When Pstream initializes MPI, it checks for a previous initialization of MPI and skips if not required. It then also skips attaching transfer buffers. On finalize, it does similar checks.
This means that MPI initialization outside of OpenFOAM will result in the buffers not being setup.
Exiting OpenFOAM will finalize MPI, even if OpenFOAM was not the one who initialized it.
Need the following:
- if an external app initialized, still initialize our buffers
- only finalize if OpenFOAM was also the one initializing, but always clean up our buffers if we created then.
Open question: when MPI was initialized elsewhere, are there any potential conflict when calling freePstreamCommunicator?Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1264Memory leak2020-06-19T20:59:31ZAdminMemory leaksuspecting a memory leak in openfoam-dev when compiled on a cluster using gcc 4.9.3 and openmpi 1.8.6
```
==39345== LEAK SUMMARY:
==39345== definitely lost: 0 bytes in 0 blocks
==39345== indirectly lost: 0 bytes in 0 blocks
==39345...suspecting a memory leak in openfoam-dev when compiled on a cluster using gcc 4.9.3 and openmpi 1.8.6
```
==39345== LEAK SUMMARY:
==39345== definitely lost: 0 bytes in 0 blocks
==39345== indirectly lost: 0 bytes in 0 blocks
==39345== possibly lost: 538 bytes in 12 blocks
==39345== still reachable: 2,056 bytes in 3 blocks
==39345== suppressed: 0 bytes in 0 blocks
==39345== Reachable blocks (those to which a pointer was found) are not shown.
==39345== To see them, rerun with: --leak-check=full --show-reachable=yes
==39345==
==39345== For counts of detected and suppressed errors, rerun with: -v
==39345== ERROR SUMMARY: 12 errors from 12 contexts (suppressed: 8 from 6)
```
\## Reattaching the author to the issue ticket: @mmahmed ##https://develop.openfoam.com/Development/openfoam/-/issues/1263Missing inline for boundBox::nDim2019-12-09T22:37:28ZMark OLESENMissing inline for boundBox::nDimMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1262Processor Boundary Conditions2019-03-30T14:43:03ZAdminProcessor Boundary ConditionsDear Developers,
Suppose we have a domain and let a cell, say owner, own a face, say facei, whose downstream cell, say neighbour, be internal cells of the domain. While running application in parallel, let facei be a processor boundary...Dear Developers,
Suppose we have a domain and let a cell, say owner, own a face, say facei, whose downstream cell, say neighbour, be internal cells of the domain. While running application in parallel, let facei be a processor boundary and let cell owner be in a subdomain, say OwnerSubdomain and neighbour be in the neighbouring subdomain, say NeighbourSubdomain. If we have a volVectorfield, say U, and run a solver like icoFOAM to solve the laplace equation or any other equation for that matter, say
fvVectorMatrix UEqn
(
fvm::ddt(U)
+ fvm::div(phi, U)
- fvm::laplacian(nu, U)
);
, when we assemble the matrix and inspect its assembly, the value of the neighbour velocity are suppose to appear as the Boundary field of facei when in ownersubdomain. Also the value of U[owner] are suppose to appear as U.boundaryField()[patchID][faceID] in the neighbourSubdomain corresponding to facei. see the code below.
forAll(mesh.C(), cellid)
{
const cell& faces = mesh.cells()[cellid];
label face;
forAll( faces, faceid)
{
face = faces[faceid];
if(mesh.isInternalFace(face))
{
continue;
}
else
{
label patchID = mesh.boundaryMesh().whichPatch(face);
label faceID = mesh.boundaryMesh()[patchID].whichFace(face);
if( mesh.boundaryMesh()[mesh.boundaryMesh().whichPatch(face)].type() == "processor" )
Pout<<"\n\nFace:\t"<<face<<"\tFace centr:\t"<<mesh.Cf()[face]<<"\tOwner:\t"<<mesh.owner()[face]<<"\tU:\t"<<U[mesh.owner()[face]]<<"\tDiagonal:\t"<<
UEqn.diag()[mesh.owner()[face]]<<"\tSourceU\t"<<UEqn.source()[mesh.owner()[face]][0]
<<"\tSourceV\t"<<UEqn.source()[mesh.owner()[face]][1]<<"\tSourceW\t"<<UEqn.source()[mesh.owner()[face]][2]
<<"\nType\t"<< mesh.boundaryMesh()[mesh.boundaryMesh().whichPatch(face)].type()
<<"\tPatchName:\t"<<mesh.boundaryMesh()[mesh.boundaryMesh().whichPatch(face)].name()<<
"\tU boundary field:\t"<<U.boundaryField()[patchID][faceID]<<"\tBoundary Coeff:\t"<<
UEqn.boundaryCoeffs()[patchID][faceID]<<"\tInternal Coeff:\t"<<
UEqn.internalCoeffs()[patchID][faceID]<<"\n";
}
}
}
However, Openfoam moves a value U*DV/Dt (where U = velocity, DV = cell volume, Dt is timestep) to the source term which I think is an error. Please correct me if am wrong and explain the meaning of the quantity moved to the source. Also, please clarify the why we need the values of UEqn.boundaryCoeffs() since the out of core updates are performed explicitly.
Best,
Kamau K
University of North Texas.https://develop.openfoam.com/Development/openfoam/-/issues/1259Discrepancy in results - Running with "laminar" turbulence model, and running...2021-07-06T15:31:23ZAdminDiscrepancy in results - Running with "laminar" turbulence model, and running with RAS + "turbulence off"<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
Results obtained by running a simulation using the turbulence model **laminar** does not match with results obtained by running with the option **RAS** coupled with **turbulence off**
### Steps to reproduce
Run the simulation case attached with:
* Allrun.lam
* Allrun.turbOff
This can be generalized to running any incompressible (tested only for incompressible cases) first with **laminar** and compare with results obtained by running with **RAS** and **turbulence off**
### Example case
[002_turbOff_Laminar_Discrepancy.tar.gz](/uploads/8902a95221088d0abf756ce80c90075b/002_turbOff_Laminar_Discrepancy.tar.gz)
### What is the current *bug* behaviour?
The result obtained by running the case with **laminar** is different from the result obtained by running the case with **RAS** + **turbulence off**
### What is the expected *correct* behavior?
The results obtained from both configurations should be the same.
### Relevant logs and/or images
-NA-
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
OpenFOAM version : 1812
Operating system : CentOS 7
Compiler : GCC 4.8.5
### Possible fixes
The problem comes from the initialization of the **nut** field.
When the case is run using **laminar**, the viscosity is taken from the transport properties. However, when the case is run using **RAS** with **turbulence off**, the **nut** field is initialised using the initial values of **k** and **omega** / **epsilon**, but not updated anymore during the simulation.
This results in a different effective viscosity being used for cases run with **turbulence off**.
Is this something intentional? Was the switch **turbulence on/off** implemented with some other intention in mind other than to give a simple method to switch between **laminar** and **turbulent** simulations?
\#\# Reattaching the author to the issue ticket: @philippose \#\#Matej FormanMatej Formanhttps://develop.openfoam.com/Development/openfoam/-/issues/1258SurfaceFeatureExtract cannot handle filenames starting with numerals.2019-03-29T07:59:34ZAdminSurfaceFeatureExtract cannot handle filenames starting with numerals.<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
When the filename of the geometry file in surfaceFeatureExtractDict starts with numerals, the applications quits with an error. However, filenames starting with numerals are legitimate filenames.
### Steps to reproduce
The issue can be reproduced by renaming the name of the geometry file to be processed to one starting with numerals, and making the corresponding change in the surfaceFeatureExtractDict.
### Example case
A simple example case has been added to this bug report.
[001_surfaceFeatureExtract_FileName_Bug.tar.gz](/uploads/a3892b7d3455cbb041dcf4ff382b2dc6/001_surfaceFeatureExtract_FileName_Bug.tar.gz)
### What is the current *bug* behaviour?
When surfaceFeatureExtract is run, and the name of the geometry file starts with numerals, surfaceFeatureExtract quits with the following error:
```
--> FOAM FATAL IO ERROR:
Expected a '(' or a '{' while reading List, found on line 17: word '_cfdValidation_8mm_15deg_001.stl'
file: /home/simuser001/OpenFOAM/simuser001-plus/run/RJ990_Issue_Testing/001_surfaceFeatureExtract_FileName_Bug/system/surfaceFeatureExtractDict at line 17.
From function char Foam::Istream::readBeginList(const char*)
in file db/IOstreams/IOstreams/Istream.C at line 134.
FOAM exiting
```
### What is the expected *correct* behavior?
The expectation is that the application surfaceFeatureExtract find the geometry file specified in the dict, extracts the edges, and quits without any error.
### Relevant logs and/or images
```
-NA-
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
OpenFOAM version : 1812
Operating system : CentOS 7
Compiler : GCC 4.8.5
### Possible fixes
None so far.https://develop.openfoam.com/Development/openfoam/-/issues/1257Error in compiling solver in OpenFOAM-v1806 on windows2020-03-13T13:36:43ZAdminError in compiling solver in OpenFOAM-v1806 on windowsDear all,
I have tried to compile a solver on a newly installed OpenFOAM-v1806 on windows without success. I have installed make, build-essentials, all to no avail. This happened on two different computers. As a test case, I decided to r...Dear all,
I have tried to compile a solver on a newly installed OpenFOAM-v1806 on windows without success. I have installed make, build-essentials, all to no avail. This happened on two different computers. As a test case, I decided to recompile the original reactingTwoPhaseEulerFoam without modifying it but alwyas gets the error below:
g++ -std=c++11 -m64 -DOPENFOAM=1806 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -Wno-unknown-pragmas -O3 -DNoRepository -ftemplate-depth-100 -ItwoPhaseSystem/lnInclude -I../phaseSystems/lnInclude -I../interfacialModels/lnInclude -I../interfacialCompositionModels/lnInclude -ItwoPhaseCompressibleTurbulenceModels/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/thermophysicalModels/basic/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/transportModels/compressible/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/TurbulenceModels/turbulenceModels/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/TurbulenceModels/compressible/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/TurbulenceModels/phaseCompressible/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/finiteVolume/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/meshTools/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/sampling/lnInclude -IlnInclude -I. -I/opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/OSspecific/POSIX/lnInclude -fPIC -c reactingTwoPhaseEulerFoam.C -o /opt/OpenFOAM/OpenFOAM-v1806/build/linux64Gcc63DPInt32Opt/applications/solvers/multiphase/reactingEulerFoam/reactingTwoPhaseEulerFoam/reactingTwoPhaseEulerFoam.o
In file included from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/scalar.H:39:0,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/IOstream.H:49,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/Ostream.H:39,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/OSstream.H:39,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/messageStream.H:244,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/error.H:51,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/UListI.H:26,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/UList.H:532,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/List.H:43,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/labelList.H:60,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/UPstream.H:42,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/Pstream.H:42,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/parRun.H:38,
from /opt/OpenFOAM/OpenFOAM-v1806/src/finiteVolume/lnInclude/fvCFD.H:4,
from reactingTwoPhaseEulerFoam.C:39:
**/opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/floatScalar.H:54:1: internal compiler error: Illegal instruction
constexpr floatScalar floatScalarGREAT = 1.0e+6;**
^~~~~~~~~
0xac5ddf crash_signal
/home/pgh/OpenFOAM/ThirdParty-1706/gcc-6.3.0/gcc/toplev.c:333
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
/opt/OpenFOAM/OpenFOAM-v1806/wmake/rules/General/transform:34: recipe for target '/opt/OpenFOAM/OpenFOAM-v1806/build/linux64Gcc63DPInt32Opt/applications/solvers/multiphase/reactingEulerFoam/reactingTwoPhaseEulerFoam/reactingTwoPhaseEulerFoam.o' failed
make: *** [/opt/OpenFOAM/OpenFOAM-v1806/build/linux64Gcc63DPInt32Opt/applications/solvers/multiphase/reactingEulerFoam/reactingTwoPhaseEulerFoam/reactingTwoPhaseEulerFoam.o] Error 1
\#\# Reattaching the author to the issue ticket: @dela \#\#
https://develop.openfoam.com/Development/openfoam/-/issues/1256Extracting used compiler flags2020-05-06T15:23:09ZAdminExtracting used compiler flags### Functionality to add/problem to solve
When compiling third-party applications that are to be used together with OpenFOAM it is reasonable to use the same compiler flags as `wmake` does. To provide a concrete example, I want to compi...### Functionality to add/problem to solve
When compiling third-party applications that are to be used together with OpenFOAM it is reasonable to use the same compiler flags as `wmake` does. To provide a concrete example, I want to compile Google Test using `wmake` flags. Sourceflux provides a tutorial on that, see refs, where they use a pretty simple python script to extract the compiler flags. The script doesn't work with OpenFOAM-plus, however, because the flags are spread across multiple files and imported using includes in the rule-file.
### Target audience
Developers looking to compile third-party applications with the same compiler flags as OpenFOAM
### Proposal
There is a $WM_CXXFLAGS variable defined, but it doesn't contain the warning flags. I could not find a variable containing all the flags. Perhaps, such a variable could be created?
### What does success look like, and how can we measure that?
An easy way to obtain all the compiler flags.
### Links / references
https://sourceflux.de/blog/google-test-and-openfoamMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1255snappyHexMesh with sloppy patch following2020-01-08T14:34:44ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh with sloppy patch following### Functionality to add/problem to solve
snappyHexMesh will try to merge co-planar faces on a single cell into a single, large face. This minimises the individual distortion and generates more layers. It will not merge faces belonging ...### Functionality to add/problem to solve
snappyHexMesh will try to merge co-planar faces on a single cell into a single, large face. This minimises the individual distortion and generates more layers. It will not merge faces belonging to different patches. Occasionally it would be nice to merge across patches (saving the effort of merging the regions in the surface)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1253missing -dict on some utilities2020-01-08T14:35:27ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commissing -dict on some utilities### Functionality to add/problem to solve
Some utilities are still missing the -dict option to specify an alternative location.
E.g. extrudeMesh.### Functionality to add/problem to solve
Some utilities are still missing the -dict option to specify an alternative location.
E.g. extrudeMesh.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1250autoPtr error for logSummary (XiEngineFoam)2019-12-09T22:37:28ZMark OLESENautoPtr error for logSummary (XiEngineFoam)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1246minor issue: pressureDifference.cfg2019-12-09T22:37:28ZAdminminor issue: pressureDifference.cfgThere is a semi colon missing after the line
writeInterval 1
in
etc/caseDicts/postProcessing/pressure/pressureDifference.cfgThere is a semi colon missing after the line
writeInterval 1
in
etc/caseDicts/postProcessing/pressure/pressureDifference.cfgMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1245ENH: add function1 support for rpm in swirl fan velocity2019-03-26T05:50:05ZPrashant SonakarENH: add function1 support for rpm in swirl fan velocity### Functionality to add/problem to solve
Function1 type for rpm (e.g. table) in swirl fan velocity
### Target audience
General capability
### Links / references
Cross ref: EP#949### Functionality to add/problem to solve
Function1 type for rpm (e.g. table) in swirl fan velocity
### Target audience
General capability
### Links / references
Cross ref: EP#949v1906Prashant SonakarPrashant Sonakarhttps://develop.openfoam.com/Development/openfoam/-/issues/1244no reconstruct script in Allrun (tut/multiphase/interIsoFoam/iobasin)2019-03-22T20:06:24ZAdminno reconstruct script in Allrun (tut/multiphase/interIsoFoam/iobasin)<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
In tut/multiphase/interIsoFoam/iobasin/Allrun, there is no script for reconstruct after mpi-run.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
tut/multiphase/interIsoFoam/iobasin
### What is the current *bug* behaviour?
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- 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 : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
OpenFOAM version :v1812
Operating system :ubuntu18.04
Compiler :gcc-7.3.0
### Possible fixes
Add the following line to the last of Allrun.
runApplication reconstructParhttps://develop.openfoam.com/Development/openfoam/-/issues/1241BUG: renumberMesh after snappyHexMesh modify behavior of DynamicRefinement2023-12-07T19:00:14ZAdminBUG: renumberMesh after snappyHexMesh modify behavior of DynamicRefinement### Summary
<!-- Summarize the bug encountered concisely -->
renumberMesh does not update properly `cellLevel`, ``Level0Edge`` and ``pointLevel`` files created by ``snappyHexMesh``
but instead delete them.
It will later cause some cells ...### Summary
<!-- Summarize the bug encountered concisely -->
renumberMesh does not update properly `cellLevel`, ``Level0Edge`` and ``pointLevel`` files created by ``snappyHexMesh``
but instead delete them.
It will later cause some cells to be protected and not refined, negating the interest of the dynamic refinement.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
To reproduce, one can call ``renumberMesh`` in a case with ``snappyHexMes`` and ``dynamicFvMesh``
after ``snappyHexMesh`` has been called.
### 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
-->
I first encountered this bug on a personnal case, but I was able to reproduce it with a tutorial.
* `cp -r $FOAM_TUTORIAL/tutorials/multiphase/interFoam/RAS/motorbike`
* Then add a renumberMesh after snappyHexMesh in Allrun.pre
or replace with [Allrun.pre](/uploads/ca333217cff63f619285d83ce155fee6/Allrun.pre)
and execute Allrun
### What is the current *bug* behaviour?
<!-- What actually happens -->
Actually, at the launch of the solver, some cells are protected from refinement, and therefore will not be
refined by dynamic refinement even if respect the criteria for the refinement.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
No cells should be proctected. So the could be refined if necessary.
### 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.
-->
from log.interFoam :
````
Selecting dynamicFvMesh dynamicRefineFvMesh
Detected 3055 cells that are protected from refinement. Writing these to cellSet protectedCells.
````
here is two pictures showing the expectation and the reality on a case with a cube, since the case with the motorbike diverges and
fails. The first gif was obtained using ``topoMesh`` but I got same results with ``snappyHexMesh`` without ``renumberMesh``.
![output_topomesh](/uploads/5fb559ad59512b44777144f9b259f5c7/output_topomesh.gif)
mesh evolution with ``renumberMesh`` :
![output_maillage](/uploads/4feda3bd1d4df6e73f09bcb3fd3e8e6b/output_maillage.gif)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
OpenFOAM version : v1806 and v18012
Operating system : debian/buster and Ubuntu bash on Windows
Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
-->
I have determined that this behavior is caused by the deletion of the
``processor*/constant/polyMesh/{cellLevel,level0Edge,pointLevel}`` files
or the incorrect (I deleted them manually without executing renumberMesh
or created them manually filling them with 0)
Thus, the file responsible is located at ``$WM_PROJECT_DIR/applications/utilities/mesh/manipulation/renumberMesh/renumberMesh.C:1327``
```
// Remove refinement data
hexRef8::removeFiles(mesh);
```
and it should be replaced with function that update the cellLevel, level0Edge and pointLevel files according to the renumbering.
After some tests, I concluded that ``rotateMesh`` and ``transformPoints`` are not affected.
The use of
````
reconstructParMesh -constant -mergeTol 1e-6
deconstructPar -force
````
also results in protectedCells.
Others mesh manipulations utilities may also lead to this behavior.
Thanks a lot, feel free to ask if you need any details.https://develop.openfoam.com/Development/openfoam/-/issues/1238add support for mingw cross-compilation2020-08-05T17:56:26ZMark OLESENadd support for mingw cross-compilationMark OLESENMark OLESEN