Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-07-07T11:04:20Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2030snappyHexMesh fails to detect locationInMesh on ARM64 v82021-07-07T11:04:20ZAndrassnappyHexMesh fails to detect locationInMesh on ARM64 v8<!--
*** 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
snappyHexMesh produces "FOAM FATAL ERROR" when not finding the specified point inside the mesh bounding box on ARM64 (v8) architecture for /some/ configurations of coordinates. A small change in coordinates - either locationInMesh or bounding box coordinates produces expected results, i.e. snappyHexMesh run completes without errors. This behaviour is reproducable for OpenFOAM-v1912 and OpenFOAM-v2012 on ARM64 (v8) AARCH64. Effects of compiler flags in wmake/rules and unsafe-math or fast-math optimizations for gcc have already been ruled out by testing and eliminating relevant compiler options.
### Steps to reproduce
Run the attached test case on ARM64 v8 with either OpenFOAM-v1912 or OpenFOAM-v2012. OpenFOAM-8 on ARM64 v8 is not affected.
$ blockMesh && snappyHexMesh
### Example case
Attached.
### What is the current *bug* behaviour?
--> FOAM FATAL ERROR:
Point (0 0 73) is not inside the mesh or on a face or edge.
Bounding box of the mesh:(-600 -600 -4.5588) (600 600 160)
From function static Foam::labelList Foam::refinementParameters::findCells(bool, const Foam::polyMesh&, const pointField&)
in file snappyHexMeshDriver/refinementParameters/refinementParameters.C at line 241.
FOAM exiting
### What is the expected *correct* behavior?
snappyHexMesh finds locationInMesh and completes the meshing run without errors.
### Relevant logs and/or images
See attached test case:
(/uploads/e538090b2c505ccc12ba6c4a1f260d44/OF-v2012-ARM-AARCH64-snappy-bug.zip)
### Environment information
OpenFOAM version : v1912 and v2012 are affected
Operating system : Ubuntu-20.04 LTS
Hardware info : ARM64 v8 AARCH64
Compiler : gcc system compiler [OF-v2012-ARM-AARCH64-snappy-bug.zip]bundled with Ubuntu-20.04 LTS ARM64
### Possible fixes
Unknown at the time of writing.https://develop.openfoam.com/Development/openfoam/-/issues/2061Discrepancy with phi(mass flowrate) calculation at the patch with buoyantSimp...2021-07-07T11:11:28ZAngirekula VenuDiscrepancy with phi(mass flowrate) calculation at the patch with buoyantSimpleFoam solver.<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
The problem is related to the way OpenFOAM evaluates the phi(mass flowrate) at the patch with buoyantSimpleFoam solver. In my system, I implemented a codedFixedValue BC for inlet velocity, which enters into the space with some angle from the patch normal. However, the value of phi at the patch produced by the OF is less than the Original value. Upon observation, it seems that only the velocity component perpendicular to the patch was considered to generate the phi. Which disturbs the conservation of heat in the system.
### Steps to reproduce
I have implemented the velocity profile at the inlet patch in such way that all velocity vectors are entering into the space radially with 70deg from the patch normal, as shown in the attached image.
### ![Inlet_vectors](/uploads/43c8d3b0cefea6ebdcb3eab514a070aa/Inlet_vectors.png)Theoretically mass flowrate calculations:
- Volumetric flowrate of patch = 0.02831 m3/sec
- Inlet Temperature = 13 deg C
- Corresponding Density,rho = 1.238 kg/m3
- Supply mass flowrate = 0.03485 kg/sec
But from the OF, with 'flowRatePatch' utility, Mass flowrate = 0.01194 kg/sec.
Which is in accord with direct summation of 'phi' values on the patch. Nevertheless, there is large difference between the actual supply mass flowrate and OF generated flowrate.
Upon further investigation, based on "[compressibleCreatePhi.H](https://openfoam.com/documentation/guides/latest/api/compressibleCreatePhi_8H.html)" we found the calculation of phi
` surfaceScalarField phi
(
IOobject
(
"phi",
runTime.timeName(),
mesh,
IOobject::READ_IF_PRESENT,
IOobject::AUTO_WRITE
),
linearInterpolate(rho*U) & mesh.Sf()
);`
The calculation of phi on the face :
- The surface area vector, Sf ( 0,0,4.032e-05)
- The translated velocity vector,U ( 0.93872955,-0.042532896,-0.34202014)
- Mass flowrate = (Sf.U)*rho = (0 + 0 + 1.379e-05)*1.238
##Observations & Queries:
1. Why the phi calculations does not taking the contribution of components other than patch normal velocity.
2. Based in the above calculations, there is large difference between the actual supply mass flowrate and OF generated flowrate.
3. The generated low phi values have also impacted the heat balance of the system.
<!-- 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
-->
### Relevant logs and/or images
[ExampleCase.tar.xz](/uploads/e327b5339d8b7453ab327a349a010c55/ExampleCase.tar.xz)
<!--
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 : v1906
- Operating system : Ubuntu 18.04Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2064rhoCentralDyMFoam + maxwellSlipU = Crash2021-07-07T11:11:53ZMartin HeinrichrhoCentralDyMFoam + maxwellSlipU = Crash### Summary
Using `rhoCentralDyMFoam` to simulate a case with dynamic mesh and `maxwellSlipU` boundary condition results in immediate crash at the first time step.
### Steps to reproduce
Take the movingCone tutorial case for `rhoCentr...### Summary
Using `rhoCentralDyMFoam` to simulate a case with dynamic mesh and `maxwellSlipU` boundary condition results in immediate crash at the first time step.
### Steps to reproduce
Take the movingCone tutorial case for `rhoCentralDyMFoam` and change one of the slip boundary conditions for U to `maxwellSlipU`. Start the simulation.
### Example case
Here [movingCone.zip](/uploads/6e94b61f2b2068d2f465390c794fd27f/movingCone.zip) is said movingCone tutorial case with maxwellSlipU boundary condition. Just create the mesh with `blockMesh` and use `rhoCentralDyMFoam` to start the simulation.
### 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 : v2006, v2012
- Operating system : Linux
- Compiler : GCC
### Possible fixes
The reason for the crash is as following: at the beginning of the time loop, mesh.update() is called, where the velocity boundary field is updated: U.correctBoundaryConditions(). There, the maxwellSlipU boundary condition is called looking for the volTensorField tauMC. However, this volTensorField is created inside the time loop of rhoCentralDyMFoam after (!) mesh.update() is called. Therefore, it cannot be found.
A simple fix would be to create the volTensorField tauMC in createFields.H and then update it at its current position. Therefore, it would be present when mesh.update() calls the maxwellSlipU boundary condition at the very first time step.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2102BUG: force write into a separated file instead of overwriting2021-07-07T11:14:33ZJunting ChenBUG: force write into a separated file instead of overwriting<!--
*** 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 -->
force write into a separated file named force_0.dat instead of overwriting the existing file when restarting from a time step that has started previously. Same behavior found when writing moment. This is quite annoying when the first time of running failed (due to CFL being too big or something), then restarted.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
1. Start a transient simulation with force writer.
2. You can stop the simulation once the force writer writes something in postProcessing/0/force.dat
3. Restart from the same time step.
4. You will see a force.dat and force_0.dat in postProcessing/0/
5. This behavior can be replicated not necessarily at 0 time step.
### 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
-->
### 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 : v2012
Operating system : centos (i dont think it matters)
Hardware info : any info that may help?
Compiler : gcc
-->
- OpenFOAM version : v2012
- Operating system : centos (i dont think it matters)
- Hardware info : VM
- Compiler : gcc
### 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
-->Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/782Problem in mean temperature and mean compressibility calculation in thermophy...2021-07-08T12:23:53ZAdminProblem in mean temperature and mean compressibility calculation in thermophysical library for premixed flameHello
The calculation of mean temeperature and mean compressibility i.e. T and psi, in the thermophysical library for a premixed turbulent flame has been problematic since an earlier version of OpenFOAM-v1.6. Please find the attached p...Hello
The calculation of mean temeperature and mean compressibility i.e. T and psi, in the thermophysical library for a premixed turbulent flame has been problematic since an earlier version of OpenFOAM-v1.6. Please find the attached pdf file for a detailed description. The latestest OpenFOAM-v1712 has the same problem.
The relavant code is $WM_PROJECT_DIR/src/thermophysicalModels/reactionThermo/psiuReactionThermo/heheuPsiThermo.C
in which the member function of calculation() calculates the mean temperatrue and compressibility psi.
Moreover, it is misleading to consider regress progress variable "b" in solver XiFoam as a mass fraction of some products in the premixed flame as implemented in OpenFOAM; see code $WM_PROJECT_DIR/src/thermophysicalModels/reactionThermo/mixtures/homogeneousMixture/homogeneousMixture.C.
The reason is that the regress progress variable "b" is based on the Bray-Mossy-Libby model of premixed flame in which the unburned and burned mixture is seperated by a infinitely thin flame front. The "b" has a physical meaning of probability of finding the unburned mixture, not some mass fraction.
I hope that I managed to explain the problem, otherwise please contact me if there is anything unclear.
Kind regards
Chen[ehsan_yasari_ab.pdf](/uploads/fe7807d8e465f774ff8b134d5ea0561b/ehsan_yasari_ab.pdf)
\#\# Reattaching the author to the issue ticket: @chenhu \#\#Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/1592Proposal: alphatWallBoilingWallFunctionFvPatchScalarField.C wall temperature ...2021-07-08T14:12:44ZRobin KamenickyProposal: alphatWallBoilingWallFunctionFvPatchScalarField.C wall temperature iterationHello everyone,
I have noticed that in the release OF-v1906 in the file OpenFOAM-v1906/src/phaseSystemModels/reactingEulerFoam/derivedFvPatchFields/alphatWallBoilingWallFunction/alphatWallBoilingWallFunctionFvPatchScalarField.C there wa...Hello everyone,
I have noticed that in the release OF-v1906 in the file OpenFOAM-v1906/src/phaseSystemModels/reactingEulerFoam/derivedFvPatchFields/alphatWallBoilingWallFunction/alphatWallBoilingWallFunctionFvPatchScalarField.C there was a for loop to evaluate wall temperature Tw. The for loop was, however, not executed because of lagging (line 1124 // NOTE: lagging Tw update.).
Thus, the wall temperature was not evaluated after the calculation of the thermal turbulent diffusivity. This led to zero error between TsupPrev and TsupNew and so the for loop was not executed. The fix to that would be the evaluation of the maximum error from all CPUs. Thus
`scalar maxErr(gMax(mag(TsupPrev - TsupNew)));`
instead of
`scalar maxErr(max(mag(TsupPrev - TsupNew)));`
When the original version is used then each processor might evaluate the error if condition on the line 1260
if (maxErr < 1e-1) differently, which means that some processor exits the for loop and some processor loops again. In this manner, the processors enter different parts of the code. Once they encounter a mpi function which requests information also from the other processor, it waits (forever, deadlock). This exactly happens when alphatWallBoilingWallFunctionFvPatchScalarField.C is used together with the turbulentTemperatureCoupledBaffleMixedFvPatchScalarField.C
I propose that the for loop to find wall temperature is implemented (as it was removed from OF-v1912) and the lagging to be fixed in the manner I showed above. It is generally recommended by literature to do this looping. Its absence might not be a big issue for heat transfer which uses correlations (film boiling and transitional boiling) but might be an issue for more complicated nucleate boiling.
Thank you,
Kind regards,
RobinKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1029hole value zeroing gives problems in overRhoPimpleDyMFoam since solves for rho2021-07-08T20:28:32ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhole value zeroing gives problems in overRhoPimpleDyMFoam since solves for rhoZero rho gives sigFpe when e.g. calculating nu (mu/rho).Zero rho gives sigFpe when e.g. calculating nu (mu/rho).https://develop.openfoam.com/Development/openfoam/-/issues/2008Interfacial Composition Model formulation2021-07-09T16:06:52ZHamidreza NorouziInterfacial Composition Model formulation<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
The problem is related to the phase equilibrium formulation in reactingEulerFoam...<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
The problem is related to the phase equilibrium formulation in reactingEulerFoam. The phase equilibrium for saturated and NRTL models are defined based on the mole-fraction while the solver uses mass fraction basis for its calculations.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
in file src/phaseSystemModels/reactingEulerFoam/interfacialCompositionModels/interfaceCompositionModels/NonRandomTwoLiquid/NonRandomTwoLiquid.C
Line 208 or 215, the code uses the following equation to calculate specie mass fraction in the vapor phase (Yf) :
return
this->otherThermo_.composition().Y(speciesName)
*speciesModel1_->Yf(speciesName, Tf)
*gamma1_;
the correct equilibrium based on activity model is based on the mole fraction in pahses:
gamma_i * x_i Ps = y_i * P (Eq. 1)
where both y_i and x_i are mole fraction of component i in liquid and vapor phase.
In the code, the mole fraction of the vapor phase is converted to the mass fraction (the return value of Yf method) when we use speciesModel1_->Yf(speciesName, Tf), since in that method the return value is multiplied by Wi/W. However, the conversion of liquid phase mass fraction (otherThermo_.composition().Y(speciesName)) to mole fraction dose not occur. the correct form of the return value is
return
this->otherThermo_.composition().Y(speciesName)
* otherThermo_.composition().W
/ otherThermo_.composition().Wi(species1Index_)
*speciesModel1_->Yf(speciesName, Tf)
*gamma1_;
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
### 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 : v2006 | V2012 etc
Operating system : ubuntu
Hardware info : AMD threadripper
Compiler : gcc
### Possible fixes
in file src/phaseSystemModels/reactingEulerFoam/interfacialCompositionModels/interfaceCompositionModels/NonRandomTwoLiquid/NonRandomTwoLiquid.C
Line 208 should be changed to
dimensionedScalar Wi (
"Wi",
dimMass/dimMoles,
otherThermo_.composition().Wi(species1Index_)
);
return
this->otherThermo_.composition().Y(speciesName)
* otherThermo_.composition().W /Wi
*speciesModel1_->Yf(speciesName, Tf)
*gamma1_;
Line 215 should be changed to
dimensionedScalar Wi (
"Wi",
dimMass/dimMoles,
otherThermo_.composition().Wi(species2Index_)
);
return
this->otherThermo_.composition().Y(speciesName)
* otherThermo_.W() / Wi
*speciesModel2_->Yf(speciesName, Tf)
*gamma2_;Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/606paraFoam does not always re-read faceSets/cellSets2021-07-15T19:55:44ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comparaFoam does not always re-read faceSets/cellSets- case with sets
- enable 'With Sets'
- switch off caching (though not sure if relevant)
- select some sets
All ok. But now change time (to time without sets) and change back.
- Refresh (since caching switched off)
- Update GUI -> gui sh...- case with sets
- enable 'With Sets'
- switch off caching (though not sure if relevant)
- select some sets
All ok. But now change time (to time without sets) and change back.
- Refresh (since caching switched off)
- Update GUI -> gui shows sets again
- Filters->Extract Block : does not show the sets being present
The only way to actually get the sets back is to deselect one of the sets, apply and re-select.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/576ENH: improving postChannel2021-07-31T18:02:11ZAdminENH: improving postChannelHello!
postChannel is an old small utility that allows to collapse data from a turbulent channel flow LES or DNS into a single profile by averaging along x and z, which are statistically homogeneous directions. There is, however, a sign...Hello!
postChannel is an old small utility that allows to collapse data from a turbulent channel flow LES or DNS into a single profile by averaging along x and z, which are statistically homogeneous directions. There is, however, a significant downside: it is impossible to choose what fields are to be averaged. Instead, they are hardcoded, see
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/applications/utilities/postProcessing/miscellaneous/postChannel/collapse.H
A couple of years ago I have developed my version of the utility which allows one to provide a list of fields to be averaged. Also, it allows you to specify the names of the patches corresponding to the top and bottom walls, and the outputted 1d profiles will include the data averaged on the patches. This is relevant in some situations, for instance in Wall-Modelled LES, where nu_t at the wall is an important quantity. Here is the repo with my code.
https://bitbucket.org/lesituu/postchannelflow
I would like to know if there is interest in incorporating my enhancemnts into the main code. From my side this seems like a nice small enhancemnt, which can be used to test getting through the process of contributing some code.
Kind regards,
Timofey
\## Reattaching the author to the issue ticket: @timofeymukha ##Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2180Feature: volume fraction2021-08-09T11:37:18ZPrashant SonakarFeature: volume fractionAs discussed, it would be nice to have a volume fraction of a specified species in the domain for multi-species cases.As discussed, it would be nice to have a volume fraction of a specified species in the domain for multi-species cases.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2181multi-world operation : setup2021-08-09T14:52:26ZPrashant Sonakarmulti-world operation : setup### Functionality to add/problem to solve
- Case with some BCs using database (syncObjects) and others not: hangs. Maybe add a check at startup
@mark### Functionality to add/problem to solve
- Case with some BCs using database (syncObjects) and others not: hangs. Maybe add a check at startup
@markhttps://develop.openfoam.com/Development/openfoam/-/issues/1767Particle erosion issue when injecting lagrangian particles into overset mesh.2021-08-22T19:03:50ZBrandon CoxParticle erosion issue when injecting lagrangian particles into 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 -->
Lagrangian particles fail to identify surfaces within the overset region when using overPimpleDyMFoam or overInterDyMFoam. Because surfaces are not recognized in the overset region, particle erosion cannot be recorded. The particles simply pass through the surfaces within the overset region.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Add Lagrangian particle functionality through the basicKinematicCloud library into overPimpleDyMFoam solver.
Copy the $FOAM_TUTORIAL/incompressible/overPimpleFoam/simpleRotor tutorial.
Add kinematicCloud file to constant directory.
- particles can be injected manually which requires adding another file to specify locations
Add particleErosion to the kinematicCloud file and specify the patch "hole"
Add g file to constant directory
add rhoInf variable to constant/transportProperties file
Run simulation.
### 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 overPimpleDyMFoam solver with particles built in.
[overLaPimpleDyMFoam.gz](/uploads/82edbe2949d2ae99dde95caf114f3cdb/overLaPimpleDyMFoam.gz)
Below is the simpleRotor case with a basic kinematic cloud particles added.
[simpleRotorParticleErosion.gz](/uploads/226f3b1eb716ae770af6b43b6ad73c97/simpleRotorParticleErosion.gz)
### What is the current *bug* behaviour?
<!-- What actually happens -->
As the particles approach the hole patch (the physical rotor), the particles pass through the rotor and don't register any impact with the erosion model.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The particles should rebound off the rotor and erosion should appear on the impacted cells.
### 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.
-->
This image shows a particle passing through the rotor without showing erosion. Erosion is shown on the outer walls to demonstrate that particle erosion is in place.
![simpleRotorErosion](/uploads/3c8f84e618ac7b537aa6ada503911021/simpleRotorErosion.png)
### 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 : v1912
- Operating system : ubuntu
- Hardware info :
- Compiler :
### 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/2191patchType does not survive operations2021-08-25T10:35:47ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.compatchType does not survive operations### Functionality to add/problem to solve
Override a bc on a constraint patch type (e.g. cyclicAMI) using the `patchType` override. Now do any kind of operation. E.g. run laplacianFoam (calculates&writes fvc::grad). This will e.g. write...### Functionality to add/problem to solve
Override a bc on a constraint patch type (e.g. cyclicAMI) using the `patchType` override. Now do any kind of operation. E.g. run laplacianFoam (calculates&writes fvc::grad). This will e.g. write gradTx which will have again `type cyclicAMI`. We might want the default `calculated` instead (so preserve the `patchType` override)
@andy @Prashant @mark
### Proposal
Have additional keyword like `patchType`?https://develop.openfoam.com/Development/openfoam/-/issues/2190BlockMesh fails when attempting to merge wedge blocks with mergePatchPairs2021-08-25T13:03:43ZMark YobbBlockMesh fails when attempting to merge wedge blocks with mergePatchPairs<!--
*** 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 -->
BlockMesh fails to run when attempting to merge a wedge block with a another block using mergePatchPairs. This occurs when merging a wedge to a wedge or a wedge to a quadrilateral block. This issue will not necessarily be something that comes up with wedge type mesh arrangements only.
This issue seems related to Issue #1862. Unlike issue #1862 this issue occurs when attempting to merge the three vertex end faces (patches) of a wedge (as opposed to the radial faces between outer radial wedge blocks.)
This issue goes away when including the "mergeType points;" directive in the blockMeshDict.
Before identifying the solution of mergeType I was attempting to solve this issue by using two vertices at the wedge origin located at a very small distance apart i.e. effectively at the same point so the first cells from the origin would in fact be hexahedron instead of prisms. This approach did infact allowed blockMesh to run. This suggests to me that the default merge algorithm is unable to handle the triangular cell faces of the prism cells on the patches.
Oddly enough when I run blockMesh on the rodFoamCase from Issue #1862 it runs with either the "mergeType points;" directive set or left to the default setting? Maybe there has been changes that already addressed #1862?
### Steps to reproduce
Within blockMeshDict create two wedge blocks or a wedge block and a quadrilateral block that share a common plane. If using two wedge blocks of the same included angle the wedge faces must not share all vertices on the common plane (like if one of the wedges is longer in the radial direction.) The grading on either side of the plane can be shared or different. Create patches on either side of plane associated with the blocks. blockMesh will run successfully if you do not attempt to merge the blocks. Set the patches to be merged with mergePatchPairs and run blockMesh again. It will fail and give the error shown below.
<!-- How one can reproduce the issue - this is very important -->
### Example case
I am including a couple of .tar.xz files that provide two cases of this error. One is for wedge blocks being merged together and one is for a wedge block being merged to a quadrilateral block. Just extract the cases and try running blockMesh. They will fail. Open the cases and uncomment the "mergeType points;" directive and try again. blockMesh will then successfully complete.
[PatchMergeWedgeToWedge.tar.xz](/uploads/f03dd5274b449e1ed7139325df4966c6/PatchMergeWedgeToWedge.tar.xz)
[PatchMergeWedgeToBlock.tar.xz](/uploads/9e75dca2b9a37fbdfadd92d139af3493/PatchMergeWedgeToBlock.tar.xz)
<!--
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?
BlockMesh only partially runs, outputs an error message and aborts.
<!-- What actually happens -->
### What is the expected *correct* behavior?
Ideally the default blockMesh meshing algorithm should be able to successfully mesh this geometry without requiring a directive to revert to the older meshing algorithm by using 'mergeType points;' in blockMeshDict or blockMesh -merge-points. It seems like it is something that it should be able to do without having to revert to an older meshing method via directive.
<!-- 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.
-->
The error that blockMesh outputs is:
"Adding point and face zones
Creating attachPolyTopoChanger
--> FOAM FATAL ERROR: (openfoam-2106)
Bad points:(2 0 0) (2 0 0) (3 0 0)
From void Foam::plane::calcFromEmbeddedPoints(const point&, const point&, const point&, const char*)
in file meshes/primitiveShapes/plane/plane.C at line 108.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::error::exitOrAbort(int, bool) at ??:?
#2 Foam::plane::calcFromEmbeddedPoints(Foam::Vector<double> const&, Foam::Vector<double> const&, Foam::Vector<double> const&, char const*) at ??:?
#3 Foam::slidingInterface::coupleInterface(Foam::polyTopoChange&) const at ??:?
#4 Foam::slidingInterface::setRefinement(Foam::polyTopoChange&) const at ??:?
#5 Foam::polyTopoChanger::topoChangeRequest() const at ??:?
#6 Foam::polyTopoChanger::changeMesh(bool, bool, bool, bool) at ??:?
#7 Foam::attachPolyTopoChanger::attach(bool) at ??:?
#8 ? in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Opt/bin/blockMesh
#9 __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
#10 ? in ~/OpenFOAM/OpenFOAM-v2106/platforms/linux64GccDPInt32Opt/bin/blockMesh
Aborted"
### 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 : v2106
- Operating system : Debian Bullseye (11)
- Hardware info : AMD Ryzen 9 5950X 16-Core Processor, MemTotal: 65831088 kB
- Compiler : gcc version 10.2.1 20210110 (Debian 10.2.1-6)
### 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
-->
If someone comes up with a fix I will gladly help test. I will look at the code to see if I can spot the issue. Kind regards. Mark.https://develop.openfoam.com/Development/openfoam/-/issues/2187BUG/ENH: multiWorld - blocks - multiple comms between same worlds2021-08-27T12:20:30ZPrashant SonakarBUG/ENH: multiWorld - blocks - multiple comms between same worldsAttached modified case of multiWorld2 where slab1 is extended to make 'U' connection to 'top' world. There is a slab in the middle which interacts with slab1 and top.
The `slab1` interacts with `top` via left and right side
![multiWorld...Attached modified case of multiWorld2 where slab1 is extended to make 'U' connection to 'top' world. There is a slab in the middle which interacts with slab1 and top.
The `slab1` interacts with `top` via left and right side
![multiWorld3](/uploads/a6d6e1698b22a45c94df9d6390ed02a6/multiWorld3.png)
[multiWorld3.tgz](/uploads/b5c71767477cf8b3e62cc3272a7e2407/multiWorld3.tgz)https://develop.openfoam.com/Development/openfoam/-/issues/1399Suggestion for improvement of Code development guide2021-08-27T14:40:15ZJohan RoenbySuggestion for improvement of Code development guideCommunity contributors who want to fix a bug or make an improvement to OpenFOAM will often have an older compiled version of the OpenFOAM-plus develop branch on their local computer. The proper workflow for such people would (as I unders...Community contributors who want to fix a bug or make an improvement to OpenFOAM will often have an older compiled version of the OpenFOAM-plus develop branch on their local computer. The proper workflow for such people would (as I understand it) be to git pull the latest OpenFOAM-plus, recompile it and then introduce their changes in a bug-fix/feature branch derived from there.
However, if API changes have occurred since their last git pull, the recompilation will fail due to outdated dep files etc. Having to wait for a full recompilation of everything every time I wanted to contribute has been a source of frustration for me until I discovered the -u/-update flag of the Allwmake script, which removes deprecated files and directories so the updating becomes much faster.
I therefore suggest to make contributors aware of this flag in the code development guide [here](https://develop.openfoam.com/Development/OpenFOAM-plus/wikis/page-code-development).Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2204overset patch with setFields2021-09-09T15:48:19ZMatej Formanoverset patch with setFieldsI'm not sure, whether this is bug or a feature so I am going to call it an annoyance.
Let's imagine you have an overset patch, where you are using setFields utility to set alpha.water level.
At the same time you have empty BC oversetPa...I'm not sure, whether this is bug or a feature so I am going to call it an annoyance.
Let's imagine you have an overset patch, where you are using setFields utility to set alpha.water level.
At the same time you have empty BC oversetPatch of type overset (in boundary file and fields files as well).
When you are running setFields setting values on volumetric region, everything is fine,
once you start setting alpha on faces (e.g. to set a fixed value on inlets and outlets) you will receive an error saying oversetPatch needs value entry.
so the oversetPatch in alpha.water file looks like this:
`
oversetPatch
{
type overset;
value uniform 0;
}
`
It is not great nor terrible, but it's ugly.
OF v2106, ubuntu, arm64 standard out of box compilationhttps://develop.openfoam.com/Development/openfoam/-/issues/2207uniform Field gets output in ascii2021-09-13T09:33:47ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comuniform Field gets output in ascii### Functionality to add/problem to solve
A uniform field gets output as e.g. (see OpenFOAM/fields/Fields/Field/Field.C)
`uniform 123.456;`
The value gets written in ascii in the current precision. Hence any restart is not exact.### Functionality to add/problem to solve
A uniform field gets output as e.g. (see OpenFOAM/fields/Fields/Field/Field.C)
`uniform 123.456;`
The value gets written in ascii in the current precision. Hence any restart is not exact.https://develop.openfoam.com/Development/openfoam/-/issues/2231reduce/improve library settings for paraview/vtk2021-10-07T06:51:41ZMark OLESENreduce/improve library settings for paraview/vtkMore recent paraview versions do not an explicit LD_LIBRARY_PATH to run so this setting can be removed from the config.sh/ entry.
Verified with a fresh ParaView build/install under /tmp/make-thirdparty. Used these locations when buildin...More recent paraview versions do not an explicit LD_LIBRARY_PATH to run so this setting can be removed from the config.sh/ entry.
Verified with a fresh ParaView build/install under /tmp/make-thirdparty. Used these locations when building the PV-Plugins (aka, paraFoam modules). Relocated ParaView to the usual ThirdParty/platforms locations. Plugins load correctly.
Will need an additional mechanism to specify `libpaths` for catalyst and runTimePostProcessing though.
[0001-CONFIG-newer-paraview-finds-its-own-libraries.patch](/uploads/86bae44b982821277e68fe24903f94c8/0001-CONFIG-newer-paraview-finds-its-own-libraries.patch)