openfoam issueshttps://develop.openfoam.com/Development/openfoam/-/issues2021-07-06T11:03:49Zhttps://develop.openfoam.com/Development/openfoam/-/issues/468ENH: mergeOrSplitBaffles - remove boundaries with zero faces after merging2021-07-06T11:03:49ZAdminENH: mergeOrSplitBaffles - remove boundaries with zero faces after mergingAdd an option (or do automatically) in mergeOrSplitBaffles to remove boundaries with zero faces from the boundary file after merging. Prevents the need to run createPatch after merging.
Also, as an aside, mergeOrSplitBaffles.C says in i...Add an option (or do automatically) in mergeOrSplitBaffles to remove boundaries with zero faces from the boundary file after merging. Prevents the need to run createPatch after merging.
Also, as an aside, mergeOrSplitBaffles.C says in its header that there is a -merge command line option, but it does not exist. However, there is a -split option. Can this be made consistent?
\## Reattaching the author to the issue ticket: @graups ##https://develop.openfoam.com/Development/openfoam/-/issues/461BUG: Comparison of Darcy's law with porousSimpleFoam2022-03-10T20:24:38ZAdminBUG: Comparison of Darcy's law with porousSimpleFoamI guess there is a problem with solving flow through a porous medium. A comparison of porousSimpleFoam with Darcy's law fails and the computed pressure drop is too low in comparison to theory. It seems that there is always one discretiza...I guess there is a problem with solving flow through a porous medium. A comparison of porousSimpleFoam with Darcy's law fails and the computed pressure drop is too low in comparison to theory. It seems that there is always one discretization cell missing. I have attached a report to show the issue [openFoam_bugReport.pdf](/uploads/85d200669c1f4db1d27ce72be062454d/openFoam_bugReport.pdf)
The problem was already reported here: https://www.cfd-online.com/Forums/openfoam-solving/183947-poroussimplefoam-comparison-darcys-law.html
The test case is attached [Darcy_test.zip](/uploads/7537bed6f996ec75b9e36e0e5dd6ea18/Darcy_test.zip)
I am using version v1606+ with a virtual machine on Windows 7.
\## Reattaching the author to the issue ticket: @sepp.zell ##Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/477BUG: polyMesh construction from IOobject does not use instance. (it uses the ...2024-01-10T16:22:02ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comBUG: polyMesh construction from IOobject does not use instance. (it uses the Time::timeName() instead)Finds mesh files using findInstance which starts from timeName()Finds mesh files using findInstance which starts from timeName()Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/506ENH: provide warning / error message when field is not read!2021-07-06T11:05:31ZPrashant SonakarENH: provide warning / error message when field is not read!Attached case with fields declared as dictionary [pitzDaily-EP412.tgz](/uploads/73052f1b040d0e091e935fc0364e2e2f/pitzDaily-EP412.tgz)
decomposePar shows success, however there is no field decomposed in processors.
It would be good to a...Attached case with fields declared as dictionary [pitzDaily-EP412.tgz](/uploads/73052f1b040d0e091e935fc0364e2e2f/pitzDaily-EP412.tgz)
decomposePar shows success, however there is no field decomposed in processors.
It would be good to add a warning or error!
@Mattijs @andyVersion v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/528directionalPressureGradientExplicitSource hard to use2020-01-03T09:39:06ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdirectionalPressureGradientExplicitSource hard to useA mesh generator might generate a faceZone (possibly incorrectly oriented) or a cellZone. The faceZone has to be oriented correctly (e.g. orientFaceZone, topoSet with setsToFaceZone and 'flip' option) and the cellZone constructed (topoSe...A mesh generator might generate a faceZone (possibly incorrectly oriented) or a cellZone. The faceZone has to be oriented correctly (e.g. orientFaceZone, topoSet with setsToFaceZone and 'flip' option) and the cellZone constructed (topoSet with faceToCell, setToCellZone). Maybe it could be made such that we only start from a cellZone and the 'faceZone' (i.e. measuring plane) gets derived from velocity and outside faces of the cellZone?Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/562simulation stop at reaching a preset wall time2021-07-06T11:19:34ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsimulation stop at reaching a preset wall timeFeature to stop the simulation at a prescribed wall time (and write the results?). This is for running under batch queueing systems to avoid them killing the job. (or can the queueing system 'warn' us when it wants us to stop (and give s...Feature to stop the simulation at a prescribed wall time (and write the results?). This is for running under batch queueing systems to avoid them killing the job. (or can the queueing system 'warn' us when it wants us to stop (and give some time for writing)?)https://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/407BUG: volume sampling output location2020-01-03T11:15:54ZPrashant SonakarBUG: volume sampling output location[pitzDaily_sample_surfaceAndVol.tgz](/uploads/9b26e07b30ae20acd358fa402c72fb31/pitzDaily_sample_surfaceAndVol.tgz)
Case attached replicating issue.
- contains sampling for surface and volume type with writeFields=true
surface-> outputs...[pitzDaily_sample_surfaceAndVol.tgz](/uploads/9b26e07b30ae20acd358fa402c72fb31/pitzDaily_sample_surfaceAndVol.tgz)
Case attached replicating issue.
- contains sampling for surface and volume type with writeFields=true
surface-> outputs field in postProcessing directory
volume-> outputs field (!) in processor0 (for parallel) or case directory (serial)
@andy @MattijsVersion v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/165setSet writing unreconstructed VTK files2020-01-03T12:05:35ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsetSet writing unreconstructed VTK filessetSet could use the same mechanism as checkMesh for writing vtk files on master only.
Attached a hack which uses vtkSurfaceWriter and the checkTools*[CH] from checkMesh to enable this. What it doesn't do:
- output field with origina...setSet could use the same mechanism as checkMesh for writing vtk files on master only.
Attached a hack which uses vtkSurfaceWriter and the checkTools*[CH] from checkMesh to enable this. What it doesn't do:
- output field with original face/cell ID (in parallel also e.g. processorID ?)
- reconstruct point fields
[setSet.C](/uploads/ce5595b7068316f020b1bc8552768ec4/setSet.C)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/326ENH: wmake for file with future timestamp2021-07-06T11:04:27ZPrashant SonakarENH: wmake for file with future timestampPlaceholder for check for files with future time stamp (when transferred between different systems)Placeholder for check for files with future time stamp (when transferred between different systems)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/276BUG: triangle intersection problem with rays in plane of triangle2021-07-06T10:46:34ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comBUG: triangle intersection problem with rays in plane of triangletriangle: (0.00084175 -0.0104928 -0.0555556) (0.00252526 -0.0104928 -0.0555556) (0.00084175 8.97416e-19 -0.0625)
ray:
start: (0.0143097 8.73202e-19 -0.0625)
end: (0.0126263 8.76229e-19 -0.0625)
finds intersection at
(0.00084175 1.7...triangle: (0.00084175 -0.0104928 -0.0555556) (0.00252526 -0.0104928 -0.0555556) (0.00084175 8.97416e-19 -0.0625)
ray:
start: (0.0143097 8.73202e-19 -0.0625)
end: (0.0126263 8.76229e-19 -0.0625)
finds intersection at
(0.00084175 1.73472e-18 -0.0625)
since the determinant (volume) of the intersection is -3.53881e-26 which is below the cutoff point (ROOTVSMALL) but still too small to accurately determine the intersection.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/90BUG: refineMesh is not parallel aware in certain scenarios2019-01-09T20:26:21ZPrashant SonakarBUG: refineMesh is not parallel aware in certain scenariosAttached case fails when run in parallel [refineBlock.tgz](/uploads/e9e0e85ebb94c041c2813ff806640f80/refineBlock.tgz)
But the serial execution is successful.
@andy Attached case fails when run in parallel [refineBlock.tgz](/uploads/e9e0e85ebb94c041c2813ff806640f80/refineBlock.tgz)
But the serial execution is successful.
@andy Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/84timeVaryingMappedFixedValue uses linear extrapolation if outside triangulation2019-12-11T16:52:37ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comtimeVaryingMappedFixedValue uses linear extrapolation if outside triangulationtimevaryingMappedFixedValue creates a triangulation 'under the hood'. It then uses bilinear interpolation for all sample points inside a triangle. For sample points outside all triangles it uses a bilinear interpolation using the nearest...timevaryingMappedFixedValue creates a triangulation 'under the hood'. It then uses bilinear interpolation for all sample points inside a triangle. For sample points outside all triangles it uses a bilinear interpolation using the nearest triangle. This is generally not ideal and especially very high aspect ratio triangles it gives problems (e.g. interpolation weights (23937.3 -48293 24356.7)
I think we should use zero-gradient outside triangles.
https://develop.openfoam.com/Development/openfoam/-/issues/80ENH: Add a warning/error message for 2D case for solidBodyMotion in thickness...2021-07-06T10:32:56ZPrashant SonakarENH: Add a warning/error message for 2D case for solidBodyMotion in thickness directionPlaceholder for development:
If the case has non-aligned edges (or develop such situation through motion), user must be warned.
@andyPlaceholder for development:
If the case has non-aligned edges (or develop such situation through motion), user must be warned.
@andyMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/602redistributePar -reconstruct produces different phi field w.r.t. reconstructPar2024-01-10T16:22:29ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar -reconstruct produces different phi field w.r.t. reconstructPar- take parallel/filter tutorial
- reconstruct time 0.8 (using ascii, 16 digits writeprecision) with both
```
reconstructPar -time 0.8
mpirun -np 3 redistributePar -reconstruct -time 0.8
```
The phi field differs in the last digits on som...- take parallel/filter tutorial
- reconstruct time 0.8 (using ascii, 16 digits writeprecision) with both
```
reconstructPar -time 0.8
mpirun -np 3 redistributePar -reconstruct -time 0.8
```
The phi field differs in the last digits on some faces.https://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/610BUG: kinematicSingleLayer::CourantNumber() decides on local number of faces2021-07-06T11:19:15ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comBUG: kinematicSingleLayer::CourantNumber() decides on local number of facesCourantNumber() calls surfaceSum (which requires parallel comms) under condition of local number of internal faces.CourantNumber() calls surfaceSum (which requires parallel comms) under condition of local number of internal faces.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/621foamToEnsight looks at last time directory to find all fields2020-01-03T11:18:40ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamToEnsight looks at last time directory to find all fieldsBit of an extreme case: when debugging meshing we sometimes write a field but since this is not in the last time dir it doesn't get converted. Workaround with e.g. -time.Bit of an extreme case: when debugging meshing we sometimes write a field but since this is not in the last time dir it doesn't get converted. Workaround with e.g. -time.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/622BUG: potentialFoam writes individual fields instead of runTime2022-04-26T16:11:08ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comBUG: potentialFoam writes individual fields instead of runTime(over)potentialFoam explicitly writes selected fields instead of runTime.write(). This means e.g. overPotentialFoam does not write the cellTypes.(over)potentialFoam explicitly writes selected fields instead of runTime.write(). This means e.g. overPotentialFoam does not write the cellTypes.v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/649movingWallVelocity allows non-zero input in case of static mesh2020-01-03T12:00:36ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commovingWallVelocity allows non-zero input in case of static meshIn case of non-moving the only value that makes sense is (0 0 0). Can we enforce this as per noSlip? Or do we re-interpret the value as a relative, additional motion in which case the moving() functionality should account for that.In case of non-moving the only value that makes sense is (0 0 0). Can we enforce this as per noSlip? Or do we re-interpret the value as a relative, additional motion in which case the moving() functionality should account for that.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://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.comhttps://develop.openfoam.com/Development/openfoam/-/issues/720add toc-style functionality to clouds/parcels2018-02-02T17:27:24ZMark OLESENadd toc-style functionality to clouds/parcelsCan currently write to an objectRegistry, but cannot otherwise ascertain which fields a cloud would normally write.
Add a classes() method similar to what objectRegistry and IOobjectList have. However, it is probably inconvenient to hav...Can currently write to an objectRegistry, but cannot otherwise ascertain which fields a cloud would normally write.
Add a classes() method similar to what objectRegistry and IOobjectList have. However, it is probably inconvenient to have the matcher predicate.
In the cloud:
template<class CloudType>
void queryClasses(const CloudType&, HashTable<wordHashSet>& classes) const
{
classes(IOField<label>::typeName).insert
({
"active",
"typeId",
});
classes(IOField<scalar>::typeName).insert
({
"nParticle",
"d",
"dTarget",
"rho",
"age",
"tTurb",
});
...
}
@andyv1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/768redistributePar does not do DimensionedFields2021-07-06T12:29:16ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comredistributePar does not do DimensionedFieldsMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/770sampledSets do not operate if there are no fields2020-01-03T12:06:04ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsampledSets do not operate if there are no fieldsThey specifically test for no applicable fields and write
```No fields to sample```
For some sets it might be nice though to still have an output.They specifically test for no applicable fields and write
```No fields to sample```
For some sets it might be nice though to still have an output.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/771sampledSets output points, not lines2020-01-03T12:07:46ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsampledSets output points, not linesFor some applications, some formats (e.g. vtk) it would be nice to see lines connecting the points instead of just the points.
Could be option, could be new set format ('vtkLines') or could be the default.For some applications, some formats (e.g. vtk) it would be nice to see lines connecting the points instead of just the points.
Could be option, could be new set format ('vtkLines') or could be the default.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://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/787forceCoeff writeFields option producing strange values: areaIntegrate of forc...2020-11-07T16:15:14ZAdminforceCoeff writeFields option producing strange values: areaIntegrate of forceCoeff field != forceCoeffI have been using the forceCoeffs function object for a long time, and am trying the writeFields option in v1712. However, it produces very strange values. I have a test case with one wall patch, and from the solving log, I can see that ...I have been using the forceCoeffs function object for a long time, and am trying the writeFields option in v1712. However, it produces very strange values. I have a test case with one wall patch, and from the solving log, I can see that the forceCoeff for that patch is quite different from the areaIntegrate of forcesAll:forceCoeff on that patch. I would expect the integral to give a value close to Cd pressure+viscous.
When I plot contours of forcesAll:forceCoeff in paraview, I see very low max values (~0.0002), when I should see surface normal*Cp, and Cp is roughly between -2 and 1.
I can supply a solved test case, and the relevant /system files and log files are attached.
```
forceCoeffs forcesAll execute:
Coefficients
Cm : -239.9753 (pressure: 176.0671 viscous: 0.6762368 porous: -416.7187)
Cd : 2.021964 (pressure: 1.242636 viscous: 0.005935802 porous: 0.7733919)
Cl : 2.230875 (pressure: 0.2968915 viscous: 0.001180773 porous: 1.932802)
Cl(f) : -238.8599
Cl(r) : 241.0908
surfaceFieldValue surfaceFieldValue1 write:
total area = 2.59955
areaNormalIntegrate(wall_l_body) of forcesAll:forceCoeff = (-0.0001750436 0 0)
surfaceFieldValue surfaceFieldValue2 write:
total area = 2.59955
areaIntegrate(wall_l_body) of forcesAll:forceCoeff = (9.107523e-05 -9.712166e-06 2.222456e-05)
```
[forcesAll](/uploads/3e40a39f7e41c19ceb9658ac4428ec60/forcesAll)
[controlDict](/uploads/bba6ee01fbd6897c829fa71d341de1e7/controlDict)[log.solve_OF.log](/uploads/19fd0116aeba1926522729982229ff92/log.solve_OF.log)
\#\# Reattaching the author to the issue ticket: @aerogt3 \#\#Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/789BUG: distributedTriSurfaceMesh written to processor*/0/triSurface/2021-07-06T12:34:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comBUG: distributedTriSurfaceMesh written to processor*/0/triSurface/Runnning with distributedTriSurfaceMesh:
- runParallel surfaceRedistributePar independent
- rmpirun -np 6 snappyHexMesh -overwrite -parallel
and at end of run I discovered triSurface/ inside the 0/ folders. Don't know which one did it.Runnning with distributedTriSurfaceMesh:
- runParallel surfaceRedistributePar independent
- rmpirun -np 6 snappyHexMesh -overwrite -parallel
and at end of run I discovered triSurface/ inside the 0/ folders. Don't know which one did it.https://develop.openfoam.com/Development/openfoam/-/issues/790BUG: singleCellFvMesh does not support disconnected regions (i.e. only does o...2021-07-06T12:34:35ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comBUG: singleCellFvMesh does not support disconnected regions (i.e. only does one cell)Not tested.Not tested.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/817use of '%' (modulo) where we just want foldaround2020-01-06T10:13:55ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comuse of '%' (modulo) where we just want foldarounde.g. rotateList in ListOpsTemplates, processorPolyPatch.C
This might be faster with just an 'if' and subtraction/addition.e.g. rotateList in ListOpsTemplates, processorPolyPatch.C
This might be faster with just an 'if' and subtraction/addition.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/841mergeMeshes with overset issue2018-05-24T10:43:43ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commergeMeshes with overset issue- mergeMeshes uses built-in topology changes
- which uses geometric matching for processor faces
- which can go wrong if multiple faces have exactly the same face centre
- which can happen for overset cases (if e.g. same cell sizes used ...- mergeMeshes uses built-in topology changes
- which uses geometric matching for processor faces
- which can go wrong if multiple faces have exactly the same face centre
- which can happen for overset cases (if e.g. same cell sizes used in background and foreground meshes)
workaround: slightly perturb one of the meshes, e.g. `mpirun -np 12 transformPoints -scale 1.000171`https://develop.openfoam.com/Development/openfoam/-/issues/849overlay mesh does not appear to support scrapers (moving a wall across a sta...2021-07-07T10:42:04ZAdminoverlay mesh does not appear to support scrapers (moving a wall across a stationary wall witth zero gap)[overDriftFluxDyMFoam.tar.gz](/uploads/567afa8fa4fc989663a0122d298a0f99/overDriftFluxDyMFoam.tar.gz)[scraperDahl3D.tar.gz](/uploads/3cba3cd18fff616cded4023448e6973a/scraperDahl3D.tar.gz)
I have created a application from driftFluxFoam ex...[overDriftFluxDyMFoam.tar.gz](/uploads/567afa8fa4fc989663a0122d298a0f99/overDriftFluxDyMFoam.tar.gz)[scraperDahl3D.tar.gz](/uploads/3cba3cd18fff616cded4023448e6973a/scraperDahl3D.tar.gz)
I have created a application from driftFluxFoam extending its capability to include overlay dynamic meshes. It compiles and runs, although I can't claim to be expert enough in the basic physics to say if the .H file modifications, or the Solver options I chose are correct/good. By runs I mean the solutions don't immediately crash or give error messages, and the scraper mesh rotates as requested. However, it gives very high values, visible in paraFoam, for the alpha.sludge concentrations between the base of the rotating scraper and the floor of the tank. These concentrations should be zero as there should be a zero gap.
Might be a bug, might be my poor implementation of overDriftFluxDyMFoam, might be a limitation in the meshing that it doesn't support a moving wall scraping a stationary wall without a gap.
The overDriftFluxDyMFoam.tar.gz file includes a couple of extra rheologies (Casson, Herschel Bulkley). The scraperDahl3D.tar.gz file is a 3D version of the Dahl tutorial with a centred scraper added at the base of the box. A version without the scraper had no issues out to 3600 sim-seconds.
Running the scraper at lower speed caused much higher maximum values for alpha.sludge and the solution went to very short time intervals and then crashed after about 60 sim-seconds.
\## Reattaching the author to the issue ticket: @DenysW ##https://develop.openfoam.com/Development/openfoam/-/issues/915paraFoam starts up with 'Skip 0/ time' enabled2020-03-13T14:42:41ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comparaFoam starts up with 'Skip 0/ time' enabled1) Do we still need this?
2) Why do we only select p,U,T and not all fields?1) Do we still need this?
2) Why do we only select p,U,T and not all fields?https://develop.openfoam.com/Development/openfoam/-/issues/962BUG: user specified field not taken into account : vorticity2021-07-06T13:11:43ZPrashant SonakarBUG: user specified field not taken into account : vorticityUser specified velocity field is override by default "U"
can we use following instead?
```
fieldExpression(name, runTime, dict, dict.lookupOrDefault<word>("U","U"))
```
@andy @mark
cross ref : EP#761User specified velocity field is override by default "U"
can we use following instead?
```
fieldExpression(name, runTime, dict, dict.lookupOrDefault<word>("U","U"))
```
@andy @mark
cross ref : EP#761Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/969decomposePar -verbose only works in combination with -dry-run2018-08-09T13:53:06ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdecomposePar -verbose only works in combination with -dry-runhttps://develop.openfoam.com/Development/openfoam/-/issues/993cannot have Function1<spatialVector>2018-09-03T12:18:55ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcannot have Function1<spatialVector>Complains about `pTraits .. nComponents`Complains about `pTraits .. nComponents`https://develop.openfoam.com/Development/openfoam/-/issues/997dynamicMultiMotionSolverFvMesh discussion2018-09-06T09:16:17ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdynamicMultiMotionSolverFvMesh discussion1. only provision is for motion on cellZone, not on cellSet
2. cellZone specification might easily be inconsistent with sub-motion solver (e.g. solidBodyMotionSolver) which looks for a cellZone or cellSet specification itself. (as long a...1. only provision is for motion on cellZone, not on cellSet
2. cellZone specification might easily be inconsistent with sub-motion solver (e.g. solidBodyMotionSolver) which looks for a cellZone or cellSet specification itself. (as long as this selection includes the multimotion cell selection it is ok)
3. output of solidBodyMotion might be confusing: e.g. `applying solid body motion to entire mesh` which then gets truncated by the dynamicMultiMotionSolverhttps://develop.openfoam.com/Development/openfoam/-/issues/999unavailable "timeExample" V&V testcase2023-05-17T15:57:13ZAdminunavailable "timeExample" V&V testcaseThe documentation describes an example of various time schemes (ref. 1) with a link to a V&V testcase, timeExample (ref. 2).
The specific case seem to be unavailable in the repository (when following the link I get error 404: The page c...The documentation describes an example of various time schemes (ref. 1) with a link to a V&V testcase, timeExample (ref. 2).
The specific case seem to be unavailable in the repository (when following the link I get error 404: The page could not be found or you don't have permission to view it.).
References:
1) https://openfoam.com/documentation/cpp-guide/html/guide-schemes-time-example.html
2) https://develop.openfoam.com/development/OpenFOAM-plus/tree/master/tutorials/verificationAndValidation/schemes/timeExample
\## Reattaching the author to the issue ticket: @michele ##v2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1005snappyHexMesh cannot refine existing patches2023-06-15T15:57:39ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh cannot refine existing patchessnappyHexMesh can only refine geometry, not existing patches. Would be nice if this was possible. Maybe have a searchableSurface which does the actual intersections on an existing patch?snappyHexMesh can only refine geometry, not existing patches. Would be nice if this was possible. Maybe have a searchableSurface which does the actual intersections on an existing patch?https://develop.openfoam.com/Development/openfoam/-/issues/1014intertia of triangle returns full tensor (instead of symmetric one)2022-04-26T16:11:09ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comintertia of triangle returns full tensor (instead of symmetric one)v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1016Paraview only reading cases with constant2019-12-11T12:31:11ZRoger AlmenarParaview only reading cases with constantHello,
I just came across an interesting case:
1) I create a blockMesh based on latestTime, hence mesh is located under results folder (like in 0.2/polyMesh).
2) I decompose that case. It creates the processorX folders, which contained 0...Hello,
I just came across an interesting case:
1) I create a blockMesh based on latestTime, hence mesh is located under results folder (like in 0.2/polyMesh).
2) I decompose that case. It creates the processorX folders, which contained 0.2/polyMesh but no constant/folders, as there is nothing there.
3) Paraview cannot read the case based on a "decomposed" input, because there are no processorX/constant folders.
The case is actually valid, just that it cannot be opened in Paraview.Mark OLESENMark OLESENhttps://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/1063reference cell issues2018-11-05T12:18:47ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comreference cell issues1) the getRefCellValue does a global distribution even when the reference value is only used on a single processor (or not used at all).
2) For certain bcs (e.g. fixedValue) the needReference() is always the same so this reduction could...1) the getRefCellValue does a global distribution even when the reference value is only used on a single processor (or not used at all).
2) For certain bcs (e.g. fixedValue) the needReference() is always the same so this reduction could be moved out of the simulation loop altogether.
3) in dynamic mesh simulations do we want to recalculate the reference cell? For some moving mesh cases we don't, for some e.g. refinement/unrefinement cases we might want to.https://develop.openfoam.com/Development/openfoam/-/issues/1067Problem with wave boundary conditions2024-03-08T22:57:31ZJohan RoenbyProblem with wave boundary conditionsThe wave boundary conditions are introducing a small fraction of air in the water phase. This is illustrated in the attached video:
![streamFunWaveProblem](/uploads/e4972a4f225032115a5583500e15852c/streamFunWaveProblem.mp4)
which shows...The wave boundary conditions are introducing a small fraction of air in the water phase. This is illustrated in the attached video:
![streamFunWaveProblem](/uploads/e4972a4f225032115a5583500e15852c/streamFunWaveProblem.mp4)
which shows the 0.99 and 0.9999 alpha contours of the $FOAM_TUTORIALS/multiphase/interFoam/laminar/waveExampleStreamFunction case.
The case was run as is.
If run with interIsoFoam instead of interFoam, isoAdvector collects the small amount of air in the water phase into bubbles that rise to the surface. A work around is to run interIsoFoam with surfCellTol = 1e-2 in fvSolution.solvers."alpha.water.*". But really this seems to be a problem with the wave BC's and not with isoAdvector.
A Paraview state file used to generate the movie is attached here: [state2.pvsm](/uploads/0ae150172498bbf215446260ada7e1e5/state2.pvsm)v1812Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1089primitiveMesh::cells needed only from wall functions2018-11-21T15:38:46ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comprimitiveMesh::cells needed only from wall functionsin simpleFoam only fvMatrix<Type>::setValuesFromList gets the cellList. Could this be rewritten to use face-based addressing and save memory? (but more runtime?)
But postprocessing/tracking needs cells so probably little effect for real...in simpleFoam only fvMatrix<Type>::setValuesFromList gets the cellList. Could this be rewritten to use face-based addressing and save memory? (but more runtime?)
But postprocessing/tracking needs cells so probably little effect for real cases.https://develop.openfoam.com/Development/openfoam/-/issues/1122snappyHexMesh automatic gap level refinement : 'small feature' phase should i...2020-09-10T14:39:28ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh automatic gap level refinement : 'small feature' phase should ignore min levelThe `Small surface feature refinement iteration` only works if minimum gap level is triggered. So if
- the specified min level is > 0
- and the geometry is inside a single cell
it will not do anything (since the initial cell level is zer...The `Small surface feature refinement iteration` only works if minimum gap level is triggered. So if
- the specified min level is > 0
- and the geometry is inside a single cell
it will not do anything (since the initial cell level is zero and never increases).
If we leave this behaviour the problem is that the behaviour depends on whether the geometry is fully inside a cell or does intersect. Which is illogical.
Or we fix and then ideally have a switch to bypass this behaviour (since it can be very slow on large cases). Maybe supply a 'maxIter' parameter for the snappyRefineDriver::smallFeatureRefine.
Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1126function object properties can only handle a single output2018-12-14T18:18:56ZMark OLESENfunction object properties can only handle a single outputthe sampled surfaces function object can contain several surfaces, but when it only has a single property to save the information. Eg,
Input:
```
plane0
{
type surfaces;
...
surfaces
(
planeA { ... }
...the sampled surfaces function object can contain several surfaces, but when it only has a single property to save the information. Eg,
Input:
```
plane0
{
type surfaces;
...
surfaces
(
planeA { ... }
planeB { ... }
);
```
uniform/functionObjects/functionObjectProperties
```
plane0
{
U
{
file "<case>/postProcessing/plane0/0.03/U_planeB.vtk";
}
}
```
possibly relevant for #1091 @andyv1906https://develop.openfoam.com/Development/openfoam/-/issues/1133cyclic pathes converted into processorCyclic not handled in patch name lookups2018-12-20T14:33:03ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcyclic pathes converted into processorCyclic not handled in patch name lookupsdecomposePar can split a cyclic into processorCyclics. These then will not be picked up by user patch-selection (e.g. through `polyBoundaryMesh::patchSet`).
Add functionality to e.g. patchSet to support this transparently.decomposePar can split a cyclic into processorCyclics. These then will not be picked up by user patch-selection (e.g. through `polyBoundaryMesh::patchSet`).
Add functionality to e.g. patchSet to support this transparently.https://develop.openfoam.com/Development/openfoam/-/issues/1134sampledSets that sampled mesh points/faces/cells (e.g. reads pointSet, faceSe...2018-12-19T11:46:45ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsampledSets that sampled mesh points/faces/cells (e.g. reads pointSet, faceSet, cellSet)Would be quite nice to sample selected mesh elements. We've got cellCentreSet but that samples all cells. There are probes but they only sample a single location.Would be quite nice to sample selected mesh elements. We've got cellCentreSet but that samples all cells. There are probes but they only sample a single location.https://develop.openfoam.com/Development/openfoam/-/issues/1140wmRefresh clears WM_NCOMPPROCS2024-01-15T10:07:55ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comwmRefresh clears WM_NCOMPPROCSIf I do a wmRefresh (as advised by ./makeParaview) it resets the WM_NCOMPPROCS so it doesn't build in parallel anymore.If I do a wmRefresh (as advised by ./makeParaview) it resets the WM_NCOMPPROCS so it doesn't build in parallel anymore.https://develop.openfoam.com/Development/openfoam/-/issues/1161BUG: Memory leak when using runtime fieldExpression::grad(U) with cached grad(U)2022-04-26T16:11:08ZAdminBUG: Memory leak when using runtime fieldExpression::grad(U) with cached grad(U)This issue can be reproduced by running any tutorial where grad(U) is both cached in system/fvSolution (for example interFoam/RAS/DTChull) and computed using the fieldExpression:
test
{
functionObjectLibs ("libfieldFunctionObjec...This issue can be reproduced by running any tutorial where grad(U) is both cached in system/fvSolution (for example interFoam/RAS/DTChull) and computed using the fieldExpression:
test
{
functionObjectLibs ("libfieldFunctionObjects.so");
type grad;
field U;
outputControl writeTime;
}
The issue is likely related to line 42 and 51 in src/functionObjects/field/grad/gradTemplates.C
\## Reattaching the author to the issue ticket: @peltonp1 ##v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1168injectionModels: inconsistent keyword: UMag/Umag2022-04-26T16:11:08ZPrashant SonakarinjectionModels: inconsistent keyword: UMag/UmagconeNozzle injection seem to require UMag, while rest models need Umag.coneNozzle injection seem to require UMag, while rest models need Umag.v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1187DOCU/ENH: lagrangian utilities2024-01-16T06:05:40ZPrashant SonakarDOCU/ENH: lagrangian utilities- [ ] particleTrack writes to processor0/VTK when run in parallel
- [x] $FOAM_APP/utilities/postProcessing/lagrangian/particleTracks/particleTrackProperties please correct cloudName->cloud
- [ ] ~~$FOAM_APP/utilities/postProcessing/lagra...- [ ] particleTrack writes to processor0/VTK when run in parallel
- [x] $FOAM_APP/utilities/postProcessing/lagrangian/particleTracks/particleTrackProperties please correct cloudName->cloud
- [ ] ~~$FOAM_APP/utilities/postProcessing/lagrangian/steadyParticleTracks/particleTrackDict please correct cloudName->cloud~~
- [ ] change alphaName->alpha in ParticleTrap.H
@andyv2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1188ENH: foamFormat convert : lagrangian data2020-01-06T08:46:49ZPrashant SonakarENH: foamFormat convert : lagrangian dataAttached a simple case illustrating incorrect conversion of binary data.
[column.tgz](/uploads/e6cebf0e112f53b7da18ec2eb3531aad/column.tgz)
@andy @markAttached a simple case illustrating incorrect conversion of binary data.
[column.tgz](/uploads/e6cebf0e112f53b7da18ec2eb3531aad/column.tgz)
@andy @markhttps://develop.openfoam.com/Development/openfoam/-/issues/1191flattenMesh has to have flattish starting mesh2019-02-04T18:02:39ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comflattenMesh has to have flattish starting meshIt would be nice to be able to supply the plane normal instead of having twoDPointCorrector try to find it. This quite often fails due to the tight tolerance. Also maybe use the patch information?It would be nice to be able to supply the plane normal instead of having twoDPointCorrector try to find it. This quite often fails due to the tight tolerance. Also maybe use the patch information?https://develop.openfoam.com/Development/openfoam/-/issues/1210exact wall distance uses existing decomposition method2019-02-22T09:23:31ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comexact wall distance uses existing decomposition method<!--
*** 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
'exact' wall distance in parallel uses the decomposition method in system/decomposeParDict. If this is set to a topological method it might behave very badly if the processors cannot be represented by bounding boxes.
### Steps to reproduce
Swithc on the debug flag for distributedTriSurfacMesh and look out for the individual bounding boxes of the processors. You want to avoid that any processor encapsulates all of the global bounding box (since it would cause all queries to be sent to it)
### 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 : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
OpenFOAM version : 1906
Operating system :
Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
-->
The solution is to use hierarchical. The problem is how to automatically set it up if the user e.g. is running with scotch:
- what should be the individual splits (nx ny nz)?
- what if the number of processors cannot be decomposed into factors (e.g. it is a prime)https://develop.openfoam.com/Development/openfoam/-/issues/1213compressibleInterfoam + twoPhaseTransport2024-02-09T21:57:04ZAdmincompressibleInterfoam + twoPhaseTransport<!--
*** 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
Per compressibleInterPhaseTransportModel.H by setting switch to twoPhaseTransport should allow separate turbulence models for each phase (RAS, laminar, LES). Test case ...OpenFOAM-v1812/tutorials/multiphase/compressibleInterFoam/laminar/climbingRod provides further explanation but uses laminar turbulence models only. When the stress model is set to e.g. RAS the solver crashes.
### Steps to reproduce
Change the climbingRod test case to RAS and e.g. kOmegaSST, add omega.air, liquid.air, k.air, k.liquid, alphat.air, alphat.liquid to the 0 folder, update the fvSchemes and fvSolution files and run the case.
### 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
-->
[climbingRod.tar.gz](/uploads/03f55cb8fe6922114873583e5c64d8de/climbingRod.tar.gz)
### What is the current *bug* behaviour?
Solver crashes if the turbulence model is set to anything except laminar.
### What is the expected *correct* behavior?
Case should run, or the error messages should provide indication of how to fix the issues (i.e., the "bananas" approach should guide the user in what is missing).
### 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.
-->
![Selection_001](/uploads/f53d7990a742e1be3297a7cf6bda7228/Selection_001.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 : v1812
Operating system : Ubuntu 16.04
Compiler : GCC
### Possible fixes
Perhaps use the switch (twoPhaseTransport) should direct the solver to use the turbulence models employed by reactingTwoPhaseEulerFoam, e.g. continuousGasKE?
\## Reattaching the author to the issue ticket: @GXA_William ##v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1216Improvements for PDRFoam (solver and utilities)2019-12-17T10:04:01ZMark OLESENImprovements for PDRFoam (solver and utilities)@Sergio @pratap@Sergio @pratapMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1219writeDictionary FO only prints after first iteration2022-12-23T14:56:42ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comwriteDictionary FO only prints after first iterationIt should print before the first iteration.It should print before the first iteration.v2306Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1239paraFoam needs 0/ directory2020-03-13T14:42:41ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comparaFoam needs 0/ directory### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
lid driven cavity
mv 0 0.orig
ln -s 0.001 0.orig
paraFoam now complains about no mesh.### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
lid driven cavity
mv 0 0.orig
ln -s 0.001 0.orig
paraFoam now complains about no mesh.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1279fieldToCell does not use lookup; always reads from disk2022-12-23T14:55:17ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfieldToCell does not use lookup; always reads from disk### Functionality to add/problem to solve
fieldToCell currently always reads from disk. Hence it cannot be used in e.g. a functionObject to select some cells during the run (). Would be nice if it would try lookup first instead.
### Pr...### Functionality to add/problem to solve
fieldToCell currently always reads from disk. Hence it cannot be used in e.g. a functionObject to select some cells during the run (). Would be nice if it would try lookup first instead.
### Proposal
- add database lookup first and loading from disk only if that fails
- move fieldToCell to finiteVolume and use proper fields
Example of desired use: plot all cells where the pressure is between 5 and 1000.
```
vtkWrite1
{
type vtkWrite;
libs ("libutilityFunctionObjects.so");
timeStart 10;
writeControl timeStep;
writeInterval 1;
format binary;
legacy false;
decompose false;
fields (p U);
selection
{
threshold
{
action use;
source fieldToCell;
field p;
min 5;
max 1000;
}
}
}
```
There is currently also a bug in that it searches for the last valid p,U instead of loading them from the current time (and failing).v2306Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1285keepParticle is ignored by postPatch2022-12-23T14:56:06ZAdminkeepParticle is ignored by postPatchI'm not sure if this is an actual issue or if I missed something in the code, but consider the following:
The cloudFunctionObjects have a hook "postPatch" to allow users to run code if a particle hits a patch:
https://develop.openfoam....I'm not sure if this is an actual issue or if I missed something in the code, but consider the following:
The cloudFunctionObjects have a hook "postPatch" to allow users to run code if a particle hits a patch:
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/lagrangian/intermediate/submodels/CloudFunctionObjects/CloudFunctionObject/CloudFunctionObject.H#L160
This hook has a parameter "keepParticle" if the user wants to remove the particle due to e.g. some custom model.
The hook is called here:
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/lagrangian/intermediate/parcels/Templates/KinematicParcel/KinematicParcel.C#L385
The value of "keepParticle" is not used. Right after the hook, the standard patch interaction code is called. Let's say the user chose "rebound". Then the following code is called:
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/lagrangian/intermediate/submodels/Kinematic/PatchInteractionModel/LocalInteraction/LocalInteraction.C#L260
Here, the value of keepParticle is uconditionally set to "true", ignoring the previous value.
To summarize: postPatch may set "keepParticle" to false, but this value is not used until the patch interaction models overwrite this value. Therefore postPatch has no effect on removing particles and the parameter "keepParticle" in postPatch seems to be ignored.
\## Reattaching the author to the issue ticket: @g3 ##v2306Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1288Incorrect behaviour of overset and cellVolumeWeight2020-04-16T12:11:25ZAdminIncorrect behaviour of overset and cellVolumeWeight### Summary
I’ve identified three possible problems with overset and specifically cellVolumeWeight interpolation method. I’ve attached three patches that attempts to resolve the three problems. There is also a small test case to illust...### Summary
I’ve identified three possible problems with overset and specifically cellVolumeWeight interpolation method. I’ve attached three patches that attempts to resolve the three problems. There is also a small test case to illustrate the problems. The test case is explained in a little bit more detail in the README file.
1) First of cellVolumeWeight is a bit chatty. I’ve enclosed all Pouts into a if(debug). This is the first patch.
2) "Cell: X at:(x y z) zone: 0 changed from hole to calculated but there is no donor"
I think there could be several reasons why this error is thrown. A less fatal approach would be to revert cells with no donors to HOLE. Although it has to be done before findHoles and walkFront. The second patch does this.
3) Of course a better approach would be to find where the error is made. The cells shouldn’t have been set to CALCULATED in the first place. I attempt to fix this in patch 3.
### Steps to reproduce
Run the attached test case with overPimpleDyMFoam. The fatal error is thrown during the first iteration. Now change the number of cells in the x-direction in the background mesh from 36 to 37 and the case runs for a little longer until the overset grid again linest up with the background mesh.
Please see the README for instructions on how to run the case. Basically compile rangeLimitedLinearSpring and then run Allrun in the checkvalve folder.
### Example case
A very crude test case of a check valve closing during reverse flow is attached.
[testcase.tgz](/uploads/a8d1bad8d29b7156c61559f8e1c4c27c/testcase.tgz)
### What is the current *bug* behaviour?
I believe a mistake is made in the function combineCellTypes. There, allCellTypes is set to HOLE if interpolatedPatchTypes is a patch and if there is insufficient overlap. Now if the patch from the overset grid cuts the background mesh exactly between cells (or close enough) both cells on both sides will have good overlap and they aren’t set to HOLEs. This will cause findHoles to fail when it “walks” and sets faces to isBlocked. Later when the mesh is split there will be leaks and the entire region might not be found where there should be holes. Theses cells are instead set to CALCULATED. The third attached patch overcomes this problem by simply not checking if there is sufficient overlap and just sets the cells to HOLE when they are cut by a patch from another region. I think it’s a safe assumption that all cells cut by patches from other regions should be HOLE. Before commit 16fb52d42bb5eff4d59910c99410e6f524ef25cc where the tolerance is adjusted, it was also possilbe that the error wasn't thrown, instead regions in the background mesh where set to CALCULATED where they should have been HOLE.This could be seen as high velocites in the background mesh where there should be no solution.
### What is the expected *correct* behavior?
There should be no fatal error, at least not this particular one. The field cellTypes should be correctly calcualted.
### Relevant logs and/or images
Please see attached case.
### Environment information
OpenFOAM version : plus/v1812
Operating system : ubuntu, redhat 6.4
Compiler : gcc
This bug report is based of commit 4569a8b3c5636ae30122ac570cbbca697fc1e07f from 12th of april.
### Possible fixes
blamed file:
[src/overset/cellCellStencil/cellVolumeWeight/cellVolumeWeightCellCellStencil.C](https://develop.openfoam.com/Development/OpenFOAM-plus/blob/4569a8b3c5636ae30122ac570cbbca697fc1e07f/src/overset/cellCellStencil/cellVolumeWeight/cellVolumeWeightCellCellStencil.C)
In the attached tar-file there is a folder called patches, either apply them or use the file in the "foldermodified_files_after_patch3" which conatins all three patches.
This is a version where all three patches have been applied.
[cellVolumeWeightCellCellStencil.C](/uploads/a19d46b73eb6b0c30ae41c30bdcd9997/cellVolumeWeightCellCellStencil.C)
I've tested with the attached case and twoSimpleRotors. They run fine. I havn't tested other overset solvers.
Also please note that the pressure field is stil calculated in HOLE regions. I haven't found a reason for this. But at least no the velocity field is zero in these regions.
\## Reattaching the author to the issue ticket: @nicolasedh ##https://develop.openfoam.com/Development/openfoam/-/issues/1340low limit of cut-off frequency ignored in surfaceNoise2020-03-09T06:15:06ZAdminlow limit of cut-off frequency ignored in surfaceNoisesurfaceNoise ignores the fl when writting the 1/3-data of SPL and PSD. That means the data of 1/3 SPL and PSDlower than fl are still written to files. The problem can be reproduced using the vortexShed tutorials.
Link to EP:
https://...surfaceNoise ignores the fl when writting the 1/3-data of SPL and PSD. That means the data of 1/3 SPL and PSDlower than fl are still written to files. The problem can be reproduced using the vortexShed tutorials.
Link to EP:
https://exchange.openfoam.com/node/1038
Son.
\## Reattaching the author to the issue ticket: @SonVo ##v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1347rhoMax/rhoMin defined but not used in buoyantSimpleFoam2022-04-26T16:10:40ZAdminrhoMax/rhoMin defined but not used in buoyantSimpleFoamIn the solver `applications/solvers/heatTransfer/buoyantSimpleFoam`, the `rhoMax` and `rhoMin` variables are defined in `createFields.H`, but never used in this solver.
I noticed this today with v1806, but have checked and this also occu...In the solver `applications/solvers/heatTransfer/buoyantSimpleFoam`, the `rhoMax` and `rhoMin` variables are defined in `createFields.H`, but never used in this solver.
I noticed this today with v1806, but have checked and this also occurs in v1812 and v1906-rc1.
According to `git blame`, the commit 1a701d9eac55a49f22b983683826d3ead8a8c85b is when this was added, but the min-max restriction was not imposed into this solver, the same way it was in chtMultiRegionSimpleFoam: https://develop.openfoam.com/Development/OpenFOAM-plus/blob/1a701d9eac55a49f22b983683826d3ead8a8c85b/applications/solvers/heatTransfer/chtMultiRegionFoam/chtMultiRegionSimpleFoam/fluid/pEqn.H#L91
\## Reattaching the author to the issue ticket: @wyldckat ##v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1353topoSet: No warning when using inconsistent setup2019-07-03T04:56:26ZPrashant SonakartopoSet: No warning when using inconsistent setup### Functionality to add/problem to solve
When setup is inconsistent, e.g. type cellSet, while source e.g. boxToFace, there is no warning/ error.
The cellSet is created with faces as labels. This should be checked for consistency.
@mark### Functionality to add/problem to solve
When setup is inconsistent, e.g. type cellSet, while source e.g. boxToFace, there is no warning/ error.
The cellSet is created with faces as labels. This should be checked for consistency.
@markhttps://develop.openfoam.com/Development/openfoam/-/issues/1361createPatch does not update fields in v19062022-04-26T16:10:39ZAdmincreatePatch does not update fields in v1906when using createPatch to merge patches, the mesh is updated but the accompanying mesh fields are not. This causes crashes with running other utilities, which complain that patches are missing or that number of faces on patches do not ma...when using createPatch to merge patches, the mesh is updated but the accompanying mesh fields are not. This causes crashes with running other utilities, which complain that patches are missing or that number of faces on patches do not match. The field data also cannot be plotted, as it's missing/incomplete on the patches in question.
This is easy and quick to reproduce on the motorbike tutorial. Just put the attached createPatchDict in /system, and run the attached Allrun. snappyHexMesh write the layers fields, which createPatch doesn't update, and then redistributePar fails due to a missing patch.
[Allrun](/uploads/caae2587d08e5ceb8f99c3deacfbe3e1/Allrun)[createPatchDict](/uploads/acb1c63a321d3da71d448d90dcc0a216/createPatchDict)
EDIT: mapFields does not handle this either. command:
**mapFields -noFunctionObjects -parallelSource -parallelTarget -consistent .**
\#\# Reattaching the author to the issue ticket: @aerogt3 \#\#v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1370occasional crash in region reduction in regionSpit2019-12-09T22:37:29ZMark OLESENoccasional crash in region reduction in regionSpitAs noted by @Prashant and now experienced myself, inconsistent blockedFace information (not properly sync'd) leads to regionSplit crashing.
Now at least catch these and emit a warning. Still need to trace the root cause.As noted by @Prashant and now experienced myself, inconsistent blockedFace information (not properly sync'd) leads to regionSplit crashing.
Now at least catch these and emit a warning. Still need to trace the root cause.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1380Simplify output of the forces functionObject2020-11-07T16:14:52ZAdminSimplify output of the forces functionObject### Functionality to add/problem to solve
The output produced by the `forces` function object is much more complex than what it could be.
For each time step the output line is as
`0.65004 \t(4.966426e-01 1.252274e+00 -3.007485e-0...### Functionality to add/problem to solve
The output produced by the `forces` function object is much more complex than what it could be.
For each time step the output line is as
`0.65004 \t(4.966426e-01 1.252274e+00 -3.007485e-04)\t(4.246068e-01 1.273820e+00 2.141011e-17)\t(7.203576e-02 -2.154636e-02 -3.007485e-04)`
Here `\t` is a tab.
Also, two separate files are created, one for the forces and one for the moments.
### Proposal
Simply having 10 values separated by spaces or tabs (consistently!) would make it much easier to open the text file with e.g. numpy or pandas, without sacrificing much.
Combining both forces and moments into single file is also reasonable.
A switch could be added to allow falling back to the old output format.
\## Reattaching the author to the issue ticket: @timofeymukha ##v2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1387Iso surface truncated by new "topo" method2020-12-20T14:06:24ZAdminIso surface truncated by new "topo" methodDuring the same run in an external aerodynamics application, I have tried to use the new isoSurfaceTopo method to extract and visualize turbulent structures via Lambda2, which resulted in a troncated iso-surface near the object, as shown...During the same run in an external aerodynamics application, I have tried to use the new isoSurfaceTopo method to extract and visualize turbulent structures via Lambda2, which resulted in a troncated iso-surface near the object, as shown in the picture attached (orange is Lambda2 via standard isoSurface and blue Lambda2 via isoSurfaceTopo).
![isoSurfaceTopoComparison](/uploads/332d5bd542ea4b4ce71eba275065dfe9/isoSurfaceTopoComparison.png)
\## Reattaching the author to the issue ticket: @Ricky-11 ##
\## Reattached image ##Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1392Capillary Courant Number for reducing spurious velocities2022-12-23T14:57:10ZAdminCapillary Courant Number for reducing spurious velocities### Functionality to add/problem to solve
Spurious (unphysical) velocities are often a problem in volume of fluid simulations. Dozens of papers are written about techniques to reduce them.
As surface tension is implemented explicitly i...### Functionality to add/problem to solve
Spurious (unphysical) velocities are often a problem in volume of fluid simulations. Dozens of papers are written about techniques to reduce them.
As surface tension is implemented explicitly in interFoam, the time step needs to be limited. It should be limited by the capillary Courant number.
### Target audience
A Capillary Courant number will be useful for everyone who uses interFoam or multiphaseInterFoam, and is working with surface tension. It will be especially usefull when simulating instabilities, because before the instability appears there should usually not be any flow in the fluid.
### Proposal
A Capillary Courant Number should be added to interFoam and multiphaseInterFoam.
### What does success look like, and how can we measure that?
The simplest test case would consist of two fluids, one over another. There should not be any flow. Of course, spurious velocities will appear - however, they will be much smaller when using a Capillary Courant number.
### Links / references
Personnettaz, P.; Beckstein, P.; Landgraf, S.; Köllner, T.; Nimtz, M.; Weber, N.; Weier, T.: Thermally driven convection in Li||Bi liquid metal batteries, Journal of Power Sources 401(2018) 362-374
The capillary time step is provided at [page 36, equation A.1 of the arXiv version.](https://arxiv.org/pdf/1805.11521.pdf)
### Funding
I can provide the source code for interFoam and multiphaseInterFoam.
\## Reattaching the author to the issue ticket: @dl6tud ##v2306Kutalmış BerçinKutalmış Berçinhttps://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/1417average printed in e.g. 'Average Courant Number' differs between parallel and...2022-03-10T20:13:05ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comaverage printed in e.g. 'Average Courant Number' differs between parallel and non-parallel<!--
*** 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
average printed in e.g. 'Average Courant Number' differs between parallel and non-parallel
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
run e.g. pimpleFoam with
- binary writing so we don't have any write precision issues
- non-uniform 0/U
- no 0/phi
It will now calculate the initial phi and the Courant number from that (finiteVolume/cfdTools/incompressible/CourantNo.H). I would expect it to be the same for parallel and non-parallelKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1456sampledSet 'uniform' does not produce same output in parallel2022-04-27T10:28:01ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsampledSet 'uniform' does not produce same output in parallel<!--
*** 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 -->
different number of samples when run in parallel.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Take pitzDaily tutorial. Use decomposeParDict with
```
//- The total number of domains (mandatory)
numberOfSubdomains 2;
////- The decomposition method (mandatory)
method random;
```
There will be 10 tracks when running in parallel but only 1 when running in parallel.
### 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 : develop (but probably also v1906)
- Operating system : openSUSE
- 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
-->v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1458nearWallFields does not run with #includeFunc since "field" and "fields" keyw...2022-04-26T16:10:38ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comnearWallFields does not run with #includeFunc since "field" and "fields" keyword are reservedfunctionObject reading in functionObjectList::readFunctionObject assumes that 'field' and 'fields' entries are straight wordlists.
nearWallFields uses 'field' for a List of word tuple. The workaround is to use it in a #include file (so ...functionObject reading in functionObjectList::readFunctionObject assumes that 'field' and 'fields' entries are straight wordlists.
nearWallFields uses 'field' for a List of word tuple. The workaround is to use it in a #include file (so the nearWallFields dictionary is a subdictionary) and not in a #includeFunc context.v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1471Potentially redundant set of computations for G object within eddy-viscosity ...2022-04-26T16:10:39ZKutalmış BerçinPotentially redundant set of computations for G object within eddy-viscosity turbulence modelsSome of the eddy-viscosity-based turbulence models compute G (the turbulent kinetic energy production rate due to the anisotropic part of the stress tensor). For example, in kEpsilon:
```
volScalarField::Internal G
(
thi...Some of the eddy-viscosity-based turbulence models compute G (the turbulent kinetic energy production rate due to the anisotropic part of the stress tensor). For example, in kEpsilon:
```
volScalarField::Internal G
(
this->GName(),
nut.v()*(dev(twoSymm(tgradU().v())) && tgradU().v())
);
tgradU.clear();
```
Here, we compute a deviatoric-symmetric tensor (`(dev(twoSymm(tgradU().v()))`) with a full tensor `tgradU().v()`.
**Any tensor** can be divided into its symmetric and anti-symmetric parts. And any double-inner product of a symmetric tensor and an anti-symmetric tensor is zero.
Therefore, the above double-inner product can be reduced between two symmetric tensors without losing any level of accuracy in the final outcome.
Such reduction seems to be carried out in the more recently implemented turbulence models, e.g. v2f.
The simpler, cheaper-to-run alternative can be:
```
tmp<volTensorField> tgradU = fvc::grad(U);
const volScalarField::Internal G
(
this->GName(),
nut.v()*2*magSqr(dev(symm(tgradU.cref().v())))
);
tgradU.clear();
```
PS: Asked the question in CFD-Online: [here](https://www.cfd-online.com/Forums/openfoam-solving/229596-potentially-redundant-set-computations-g-object-within-turbulence-models.html).v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1486surfaceFeatureExtract trims all features on a brick when minElem > 12020-01-06T19:29:41ZAdminsurfaceFeatureExtract trims all features on a brick when minElem > 1### Summary
Not sure if this is a bug report of a feature request, but here it goes.
When I extract features on a brick defined by an stl file, the edge features (12 of them) only get extracted if trimFeatures minElem is not used or set...### Summary
Not sure if this is a bug report of a feature request, but here it goes.
When I extract features on a brick defined by an stl file, the edge features (12 of them) only get extracted if trimFeatures minElem is not used or set to something not higher than 1. Since all the features are "connected" on the brick, I would have expected features to not be trimmed until at least a value of 13 on minElem.
This probably gets into how you are determining the number of elements in feature strings. In other software I've used, they generally separate things into "connected" feature groups and then apply element filtering to each of those. For example, a brick would have 12 connected feature edges and be in one group, so a minElem of 2 shouldn't trim any of the features, but in surfaceFeatureExtract, it does.
### Steps to reproduce
Run surfaceFeatureExtract on the attached brick model. No features will be extracted because minElem is set to 2. If you set it to 1, the features get extracted.
### Example case
[brick.zip](/uploads/be63b675856f5a189e7cd6035e0294e6/brick.zip)
### What is the current *bug* behaviour?
No features will be extracted because minElem is set to something above 1.
### What is the expected *correct* behavior?
I would expect all features to be extracted until minElem reaches 13, since there are 12 connected feature edges on a brick.
### Environment information
OpenFOAM version : v1906
Operating system : RHEL / Windows
Compiler : gcc / MinGW
### Possible fixes
I looked in surfaceFeatures.C to try and glean how feature strings were being determined, but I was unable to decipher the strategy being used. My guess is that there is a difference in strategy, if that's the case, then this is a feature request.
\## Reattaching the author to the issue ticket: @graups ##https://develop.openfoam.com/Development/openfoam/-/issues/1491SnappyHexMesh: Treat feature edge/cell between different PID for layer addtition2019-11-12T12:09:21ZPrashant SonakarSnappyHexMesh: Treat feature edge/cell between different PID for layer addtition### Functionality to add/problem to solve
Using mutli-region feature edge we can capture in-plane edges. Improve the snapping to help generate layers at this section.
### Links / references
EP#1084### Functionality to add/problem to solve
Using mutli-region feature edge we can capture in-plane edges. Improve the snapping to help generate layers at this section.
### Links / references
EP#1084Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1492fixup for PDRsetFields2019-11-19T11:21:20ZMark OLESENfixup for PDRsetFieldsPlaceholder for topics, changes etc.
@pratap @puttockPlaceholder for topics, changes etc.
@pratap @puttockMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1507Modify the static regIOobject::store method, possibly remove the member version?2024-02-20T15:58:37ZMark OLESENModify the static regIOobject::store method, possibly remove the member version?Just discussed with @Mattijs, following up on discussions with @andy
Given the scenario of having a local (unregistered) field
```
volScalarField* ptr = volScalarField:New(...).ptr(); // An unregistered pointer
```
I would later like...Just discussed with @Mattijs, following up on discussions with @andy
Given the scenario of having a local (unregistered) field
```
volScalarField* ptr = volScalarField:New(...).ptr(); // An unregistered pointer
```
I would later like to register this on its objectRegistry and have the registry take ownership.
- Using `ptr->store()` merely changes the ownership flag, but doesn't register.
- Using `ptr->checkIn()` will register it, but not take ownership.
The static `store()` version is just the same as the member one, with a nullptr check, but does not actually give ownership to the registry.
The static regIOobject::store() should probably attempt to check-in the object if not already marked as registered_.
If the object cannot be checked in, Fatal, Warn, or package as autoPtr for deletion?
Minor (style) - the objectRegistry debug diagnostics will warn about attempting to insert an object with identical name. Should probably check if existing object is actually different.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1528snappyHexMesh castellation step creates gaps between curved triangulated surf...2024-01-02T13:17:31ZDries AllaertssnappyHexMesh castellation step creates gaps between curved triangulated surfaces### Summary
In multiRegion cases, the castellation step of snappyHexMesh creates small gaps between curved triangulated surfaces (specified by stl files exported from CAD software AutoDesk Invecntor) when they are not exactly equal, eve...### Summary
In multiRegion cases, the castellation step of snappyHexMesh creates small gaps between curved triangulated surfaces (specified by stl files exported from CAD software AutoDesk Invecntor) when they are not exactly equal, even when stl files are exported at very high resolution (highest resolution available in the CAD software).
### Steps to reproduce
The issue can be reproduced by applying snappyHexMesh on a multiregion case with a curved interface between two regions, and with the different regions specified by different stl files exported from CAD software.
### Example case
Attached is a minimal working example consisting of two concentric cylinders corresponding to a fluid and a solid region. Only the castellation step of snappyHexMesh is run. [MWE.tar.gz](/uploads/21ca31e1c36f1f0e4a2673ec786c5fd9/MWE.tar.gz)
### What is the current *bug* behaviour?
The castellation step of snappyHexMesh creates small gaps between two triangulated surfaces, i.e., on the interface between two regions. As a result, some faces on the interface are identified as walls instead of mappedWalls between the two surfaces. In the snapping step, the gaps are closed but the patch type of some faces remains wall instead of mappedWall.
### What is the expected *correct* behavior?
snappyHexMesh should not remove cells located between two triangulated surface when the two triangulated surfaces coincide within a certain tolerance. The tolerance should be such that coinciding surfaces exported by CAD software can be meshed without creating small gaps. Possibly, this tolerance could be a user input.
### Relevant logs and/or images
Attached is a log file ([log.txt](/uploads/d20cb17863dbfce7ae643e6f8d23c929/log.txt)) of the provided minimal working example (logs of surfaceFeatureExtract - blockMesh - snappyHexMesh - splitMeshRegions) as well as some figures showing the case setup and the gaps on the interface.
Overview of the multiRegion geometry.
![MWE_fig1](/uploads/46a8588961f77c7616bdefac7eede9f1/MWE_fig1.png)
Detailed view of the interface.
![MWE_fig2](/uploads/a691486b653b0a97414885d0052784e1/MWE_fig2.png)
View of the interface, showing some faces that are identified as type wall (white) instead of mappedWall (red)
![MWE_fig3](/uploads/d6a1e6157024dad044c6cc8306f2dd6c/MWE_fig3.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 : v1906
- Operating system : CentOS Linux release 7.6.1810
- Hardware info :
- Compiler : intel
### Possible fixeshttps://develop.openfoam.com/Development/openfoam/-/issues/1532Local Time Stepping for High Aspect Ratio Cells2022-04-26T16:10:39ZLiamLocal Time Stepping for High Aspect Ratio CellsLocal Time stepping an extremely effective method to obtain steady state solutions to a variety of cases. However, in cases with high aspect ratio cells, the local time-step becomes extremely small. This occurs in a number of situations,...Local Time stepping an extremely effective method to obtain steady state solutions to a variety of cases. However, in cases with high aspect ratio cells, the local time-step becomes extremely small. This occurs in a number of situations, specifically in cases where a wall resolved simulation is required. As the mesh must be refined to Y+ < 1, the aspect ratio becomes very high and the simulation begins to converge very slowly.
It has been shown in literature, and in other CFD codes, that taking into account the aspect ratio of the cell can speed up the convergence of the computation significantly (by an order of magnitude). In my own experience, certain cases (airfoils/de Lave nozzles) with high Reynolds number and thus very small Y+ = 1 distance, had an acceleration of over 100 times making these simulations optimum for parametric studies or optimization.
Implementing this feature which takes into account the aspect ratio of the cell in computing the local time-step would alleviate the number of iterations required to converge the solution in these cases. Literature on this can be found:
https://arc.aiaa.org/doi/pdf/10.2514/6.2001-2557
Additionally, this has been implemented into ANSYS Fluent under the name of "Convergence Acceleration for Stretched Meshes (CASM)".
http://www.pmt.usp.br/ACADEMIC/martoran/NotasModelosGrad/ANSYS%20Fluent%20Theory%20Guide%2015.pdf (PDF Pg. 699)
https://support.ansys.com/staticassets/ANSYS/Conference/Dallas/downloads/fluid-dynamics-14.0-update.pdf (PDF Pg. 14)
http://www.pmt.usp.br/academic/martoran/notasmodelosgrad/ANSYS%20Fluent%20Users%20Guide.pdf (PDF Pg. 1499)
An appropriate test case, for example, would be: NACA0012 with a wall-resolved mesh and the appropriate turbulence model for a wall-resolved RAS simulation. Running this at a high Re number would help high-light the effectiveness. Run the simulation with and without this new feature. The results should be effectively identical however using this feature the simulation should required significantly fewer iterations.v2206https://develop.openfoam.com/Development/openfoam/-/issues/1542checkMesh aspect ratio2024-01-10T16:47:46ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh aspect ratio### Functionality to add/problem to solve
checkMesh calculates an aspect ratio in the global coordinate system. More relevant would probably using a cell-local coordinate system.
### Proposal
Use the cell-local coordinate system calc...### Functionality to add/problem to solve
checkMesh calculates an aspect ratio in the global coordinate system. More relevant would probably using a cell-local coordinate system.
### Proposal
Use the cell-local coordinate system calculation from e.g. the cellDeterminant check and determine the aspect ratio in that.
### What does success look like, and how can we measure that?
Make e.g. cavity with a lot of grading. See if the reported aspect ratio changes if the case is rotated (e.g. using `transformPoints -rotate`)https://develop.openfoam.com/Development/openfoam/-/issues/1570Cloud post-processing data not written when steady case converges using resid...2020-01-28T09:28:57ZAndrew HeatherCloud post-processing data not written when steady case converges using residualControl<!--
*** 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 -->
When using clouds in steady solvers combined with case termination controls set using `residualControl` in the `fvSolution` file, cloud post-processing data are not written on the last iteration.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Add `residualControl` settings to a steady flow solver with cloud functionality and cloud a post-processing object, e.g. `particleTracks`
```
particleTracks
{
type particleTracks;
trackInterval 5;
maxSamples 1000000;
resetOnWrite yes;
}
```
and notice that the cloud post-processing data are not written
### 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?
When the criteria specified in the `residualControls` dictionary are achieved the solver loop calls `time.writeAndEnd()` to write any objects registered with `AUTO_WRITE` and exits. Operations such as cloud post-processing are currently only triggered when evolving the cloud and intercept the `writeTime()` flag and are therefore missed.
### 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 :
- Operating system :
- 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
-->
Couple of options
- instead of exiting straight away, run for 1 more iteration with the `writeTime_` flag set (e.g. using `time.writeOnce()` and exit
- intercept the `write()` call to trigger other post-processing actionsv2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1576coded FO does not support mesh changes2020-01-27T15:19:10ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcoded FO does not support mesh changes### Functionality to add/problem to solve
coded FO never gets warned of mesh changes (movePoints, updateMesh). These calls are defaulted in functionObject but should be redirected instead.
Needs:
- functionObjectTemplate[CH] to specify...### Functionality to add/problem to solve
coded FO never gets warned of mesh changes (movePoints, updateMesh). These calls are defaulted in functionObject but should be redirected instead.
Needs:
- functionObjectTemplate[CH] to specify missing callbacks
- syntax inside codedFunctionObject to specify the missing code ('codeMovePoints'?)
- redirection callshttps://develop.openfoam.com/Development/openfoam/-/issues/1581transient solver with suitable ddtScheme2020-02-03T12:37:26ZPrashant Sonakartransient solver with suitable ddtScheme### Functionality to add/problem to solve
Trying to run a transient solver with 'steadyState' as ddtScheme usually causes a divide by zero (sigfpe). This is quite an easy mistake to make when starting from a steady-state solution.
###...### Functionality to add/problem to solve
Trying to run a transient solver with 'steadyState' as ddtScheme usually causes a divide by zero (sigfpe). This is quite an easy mistake to make when starting from a steady-state solution.
### Proposal
Would be nice to give a warning message. It still should be possible in general (e.g. to replace an outer loop with the time loop).
Cross Ref: EP#1204https://develop.openfoam.com/Development/openfoam/-/issues/1583checkMesh : patch geometry : include flatness2020-02-05T13:34:26ZPrashant SonakarcheckMesh : patch geometry : include flatness### Functionality to add/problem to solve
Would be nice for checkMesh to report whether a patch is flat for e.g. follow-on extrudeMesh.
### Proposal
Add to -allGeometry check the reporting of the maximum deviation of (face) normal w....### Functionality to add/problem to solve
Would be nice for checkMesh to report whether a patch is flat for e.g. follow-on extrudeMesh.
### Proposal
Add to -allGeometry check the reporting of the maximum deviation of (face) normal w.r.t. average.
Q:
- how much deviation is non-flat
- report per patch-region (e.g. for lid-driven cavity tutorial where single patch has 3 different orientations)
Cross-ref : EP#1159https://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/1601Feature request: sedFOAM submodule2023-11-24T16:26:48ZKutalmış BerçinFeature request: sedFOAM submodule### Functionality to add/problem to solve
http://servforge.legi.grenoble-inp.fr/pub/soft-sedfoam/
https://github.com/sedfoam/sedfoam
Following the short discussion in their repo: https://github.com/SedFoam/sedfoam/issues/15
the mainta...### Functionality to add/problem to solve
http://servforge.legi.grenoble-inp.fr/pub/soft-sedfoam/
https://github.com/sedfoam/sedfoam
Following the short discussion in their repo: https://github.com/SedFoam/sedfoam/issues/15
the maintainer of sedFOAM showed keen interest on OpenFOAM's submodule functionality.
sedFOAM is represented as a code suite for two-phase flow sediment flow applications.
### Target audience
Wave/free surface involved applications, e.g. masts erected in sea bed, tidal turbines, or in general, underwater structures close to sea bed (might misunderstand).
### Proposal
If the maintenance cost of adding and shipping a new submodule is very low for OpenFOAM, sedFOAM submodule would be a win-win.
### What does success look like, and how can we measure that?
The suite is based on a set of publications, and has its own user group (it seems). Also, reasonably well maintained by a group of people, compatible with recent OF versions.
### Funding
NA
@andy @mark @Mattijs @Sergio @Prashant @RogerKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1604Restart not possible for liquidFilmFoam2022-04-26T16:10:40ZChiara PesciRestart not possible for liquidFilmFoam<!--
*** 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
Impossible to restart a simulation with liquidFilmFoam
### Steps to reproduce
Run the tutorial $FOAM_TUTORIALS/finiteArea/liquidFilmFoam/cylinder
Restart the simulation from latestTime
### 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?
At restart the solver looks for the ```areaScalarField h``` (as it is given in the 0 folder), but in the saved time folders it is written out as a ```volScalarField``` (with object name H).
Two different fields, h (area) and H (vol), are created, but possibly the write() function is not case sensitive and the volScalarField overwrites the areaScalarField.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
```
--> FOAM FATAL IO ERROR:
unexpected class name volScalarField expected areaScalarField
while reading object h
file: /liquidFilmFoam/cylinder/0.5/h at line 15.
From function Foam::Istream& Foam::regIOobject::readStream(const Foam::word&, bool)
in file db/regIOobject/regIOobjectRead.C at line 170.
FOAM exiting
```
### 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 :
- 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
-->v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1611Wrong curvature at finite area boundary2022-05-06T08:04:23ZChiara PesciWrong curvature at finite area boundary<!--
*** 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
Curvature computation at finite area boundaries is wrong.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
To visualize the curvature field, one can modify for instance the *checkFaMesh* utility. A volScalarField can be added and the aMesh.faceCurvatures() can be written out on its boundary corresponding to the faMesh.
```
volScalarField curvVf
(
IOobject
(
"curvVf",
runTime.timeName(),
mesh,
IOobject::NO_READ,
IOobject::AUTO_WRITE
),
mesh,
dimensionedScalar(dimless/dimLength, Zero)
);
// Create volume-to surface mapping object
volSurfaceMapping vsm(aMesh);
vsm.mapToVolume(aMesh.faceCurvatures(), curvVf.boundaryFieldRef());
curvVf.write();
```
### 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
-->
Consider the surface of half a sphere, this is represented by a finite area mesh with a boundary, the circumference at the equator. The curvature of the sphere is known; in this case the radius of the sphere is 1 m, thus the curvature should be -2.
### What is the current *bug* behaviour?
<!-- What actually happens -->
The figures below show the local curvature and the error in its computation on half a sphere for which the analytical curvature is known.
![curvatureV1912boundary](/uploads/d5527f5f263d9bc311c9bf0c605480b1/curvatureV1912boundary.png)
Note that the error persists when refining the mesh or using different cell/face shapes.
### 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.
-->
```
Curvature: min = min(faceCurvatures) [0 -1 0 0 0 0 0] -2.0005
max = max(faceCurvatures) [0 -1 0 0 0 0 0] -1.48813
```
### 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 (problem present also in older versions)
- Operating system :
- 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
-->
A correction for the faces having a point on the boundary of the finite area mesh has to be included. The curvature computation depends on the pointAreaNormals and at the boundary of the finite area mesh these normals introduce the error. A solution for cases where the mesh is not being highly deformed close to the boundary may be possible.v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1615chtMultiregionFoam relaxation problem2021-07-06T17:09:26ZTj KimchtMultiregionFoam relaxation problemIn the Pimple mode with relaxation of p_rgh, the chtMultiregionFoam solver returns an error message of
"not stored. Use field.storePrevIter()"
I found the solver already includes a function call of storePrevIter().
So I think that it is ...In the Pimple mode with relaxation of p_rgh, the chtMultiregionFoam solver returns an error message of
"not stored. Use field.storePrevIter()"
I found the solver already includes a function call of storePrevIter().
So I think that it is out of my job.
The solver in v1906 is same as the v1912.
With the same fvSolution file, OF-7 runs good.
Could you please check the reason?
My recommendation is to update solutioncontrol classes in v1912 similar to those in OF-7Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1616CrankNicolson ddtScheme isn't working with MPPICInterFoam2022-04-26T16:10:39ZLinus KCrankNicolson ddtScheme isn't working with MPPICInterFoam### Summary
MPPICInterFoam isn't working when using the CrankNicolson ddtScheme. After my own project didnt work, I tried the "twoPhasePachuka" tutorial case with the same result. After the first time step it crashes, showing the error ...### Summary
MPPICInterFoam isn't working when using the CrankNicolson ddtScheme. After my own project didnt work, I tried the "twoPhasePachuka" tutorial case with the same result. After the first time step it crashes, showing the error message attached further down.
### Steps to reproduce
Take the "twoPhasePachuka" tutorial case.
In file fvSchemes, change the ddtScheme to CrankNicolson:
```
ddtSchemes
{
default CrankNicolson 0.1;
}
```
In file fvSolution, change the number of AlphaSubCycles to 1:
```
solvers
{
"alpha.water.*"
{
nAlphaCorr 2;
nAlphaSubCycles 1;
cAlpha 1;
```
### Relevant logs and/or images
```
--> FOAM FATAL ERROR:
tmp<N4Foam14GeometricFieldIdNS_13fvsPatchFieldENS_11surfaceMeshEEE> deallocated
From function const T& Foam::tmp<T>::cref() const [with T = Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh>]
in file /OpenFOAM/v1812/OpenFOAM-v1812/src/OpenFOAM/lnInclude/tmpI.H at line 230.
FOAM aborting
```
### Environment information
OpenFOAM version : v1812v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1631Writing fields with layer information makes snappyHexMesh crash in motorbike ...2021-10-29T20:19:32ZRiccardo RossiWriting fields with layer information makes snappyHexMesh crash in motorbike tutorial (reopen)I've just tried to test the issue reported in #1420 with the v1912 and it's still there:
`
Writing fields with layer information:
nSurfaceLayers : actual number of layers
thickness : overall layer thickness
[0] #0 [1...I've just tried to test the issue reported in #1420 with the v1912 and it's still there:
`
Writing fields with layer information:
nSurfaceLayers : actual number of layers
thickness : overall layer thickness
[0] #0 [1] #0 [2] #0 [3] #0 [4] #0 [5] #0 Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&) at at ??:?
`https://develop.openfoam.com/Development/openfoam/-/issues/1633Overset performance degradation (re-opened)2020-03-20T09:30:34ZRiccardo RossiOverset performance degradation (re-opened)I'm reopening this topic as preliminary testing with our model using the latest v1912 release shows the same issues.
In the following I'll present the results from testing based from what we learned from the previous discussion in #1183...I'm reopening this topic as preliminary testing with our model using the latest v1912 release shows the same issues.
In the following I'll present the results from testing based from what we learned from the previous discussion in #1183 using with tutorials from the official release (twoSimpleRotors and boatAndPropeller) and our test case (surfboard maneuvering).
The v1912 will be also compared to v1706 as the old release so far is the only one able to run our model with no issues.https://develop.openfoam.com/Development/openfoam/-/issues/1634Style formatting config needed (e.g. clang-format)2024-02-16T13:40:05ZGerasimos ChourdakisStyle formatting config needed (e.g. clang-format)### Functionality to add/problem to solve
Add a [clang-format](https://clang.llvm.org/docs/ClangFormat.html) or similar system config file in the code repository, so that contributions to the repository or derived projects can follow th...### Functionality to add/problem to solve
Add a [clang-format](https://clang.llvm.org/docs/ClangFormat.html) or similar system config file in the code repository, so that contributions to the repository or derived projects can follow the [Coding Style Guide](https://develop.openfoam.com/Development/openfoam/wikis/Coding-Style-Guide).
Clang-format is an established formatting tool and integration is already provided in many editors and IDEs, including [Emacs](https://clang.llvm.org/docs/ClangFormat.html#emacs-integration), [Vim](https://clang.llvm.org/docs/ClangFormat.html#vim-integration), and [CLion](https://clang.llvm.org/docs/ClangFormat.html#clion-integration).
### Target audience
- Regular developers of OpenFOAM
- External contributors to OpenFOAM
- Contributors to third-party OpenFOAM projects (e.g. function objects, such as the [preCICE OpenFOAM adapter](https://github.com/precice/openfoam-adapter))
### Proposal
1. Create a `.clang-format` file, e.g. in the root directory of the repository, or any other directory preferred for developers' tools.
- For example, with `clang-format -style=llvm -dump-config > .clang-format`
2. Define the preferred rules following the [Clang-Format Style Options](https://clang.llvm.org/docs/ClangFormatStyleOptions.html). Beware that the rules may depend on the Clang-Format version.
### What does success look like, and how can we measure that?
Running `clang-format -i FILES` should reformat the source files `FILES` to follow the coding style guidelines.
### Links / references
- [Clang-Format Style Options](https://clang.llvm.org/docs/ClangFormatStyleOptions.html)
- [OpenFOAM Coding Style Guide](https://develop.openfoam.com/Development/openfoam/wikis/Coding-Style-Guide)
### Funding
I am not aware of existing functionality regarding this. However, it may have been already developed by other developers.https://develop.openfoam.com/Development/openfoam/-/issues/1639simpleFoam: non-realistic turbulence increase in the streamwise direction in ...2024-01-11T17:22:49ZLorenzo CozzisimpleFoam: non-realistic turbulence increase in the streamwise direction in a wall-bounded flowDear developers,
running a case of a wall bounded flow over a flat plate with simpleFoam I got really weird results, with turbulent kinetic energy and turbulence intensity increasing in the flow direction when they are supposed to lower...Dear developers,
running a case of a wall bounded flow over a flat plate with simpleFoam I got really weird results, with turbulent kinetic energy and turbulence intensity increasing in the flow direction when they are supposed to lower down because of the turbulence decay.
To ease the issue-solving procedure, I prepared an archive with my case folder ready to be used. Find the .tar file here: [https://www.dropbox.com/s/szkz4vymu92eev0/smooth-openFOAM-RANS-Re70k-CFDOnline.tar?dl=0](https://www.dropbox.com/s/szkz4vymu92eev0/smooth-openFOAM-RANS-Re70k-CFDOnline.tar?dl=0)v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1645Re-open Issue: Gauss CoBlended scheme fails for div(phi,alpha) in interFoam2022-04-26T16:10:40ZLydia SchulzeRe-open Issue: Gauss CoBlended scheme fails for div(phi,alpha) in interFoam<!--
*** 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
Note:
I re-open this issue, as it is still relevant and not fixed in the latest version.
The issue was already described in #1236 for version v1812.
When using the scheme Gauss CoBlended for the term div(phi,alpha) in the solver interFoam, the simulation breaks up with the following error message: fvSchemes:
```div(phi,alpha) Gauss CoBlended 1. Minmod 2. upwind;```
logfile output:
`\--> FOAM FATAL ERROR: Operator + is undefined for unoriented and oriented types From function Foam::orientedType Foam::operator+(const Foam::orientedType&, const Foam::orientedType&) in file orientedType/orientedType.C at line 458.`
### Steps to reproduce
Use tutorial /multiphase/RAS/interFoam/damBreak. Change in fvSchemes:
```div(phi,alpha) Gauss CoBlended 1. Minmod 2. upwind;```
Run the case with Allrun.
### Example case
The damBreak tutorial (tutorials/multiphase/RAS/damBreak)
### What is the current *bug* behaviour?
<!-- What actually happens -->
Run fails in first alpha-Subcycle.
See logfile output below.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
Normal interFoam-running would be expected.
### 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.
-->
```Courant Number mean: 0 max: 0 Interface Courant Number mean: 0 max: 0 deltaT = 0.00119048 Time = 0.00119048 PIMPLE: iteration 1 smoothSolver: Solving for alpha.water, Initial residual = 0, Final residual = 0, No Iterations 0 Phase-1 volume fraction = 0.130194 Min(alpha.water) = 0 Max(alpha.water) = 1 --> FOAM FATAL ERROR: Operator + is undefined for unoriented and oriented types From function Foam::orientedType Foam::operator+(const Foam::orientedType&, const Foam::orientedType&) in file orientedType/orientedType.C at line 458.```
### 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 : centos
- Hardware info :
- 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
-->v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1652adding porous media in rotatine zone2022-04-26T16:10:39ZRoshanakadding porous media in rotatine zoneAdding feature of "Relative velocity Resistance formulation" which exists in Ansys-fluent for better prediction of source term when rotating region and porous zone are located in one zone. in Ansys-Fluent, the results, when you choose th...Adding feature of "Relative velocity Resistance formulation" which exists in Ansys-fluent for better prediction of source term when rotating region and porous zone are located in one zone. in Ansys-Fluent, the results, when you choose this option or not selecting it, are quite different.
it seems that Openfoam can only calculate porous source term based on absolute velocity. when it is calculated Darcy-Forchimmier source term based on absolute velocity, it seems that porous zone is fixed in position and not rotating(see attachment files)![Screenshot_from_2020-03-30_10-42-16](/uploads/993db2537153c78ad9347af3ff8f75ad/Screenshot_from_2020-03-30_10-42-16.png)![Screenshot_from_2020-03-30_10-42-32](/uploads/39025939c059c1eb36d8aa33dcaec335/Screenshot_from_2020-03-30_10-42-32.png)v2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1672waveMaker MultiPaddleFlap crashes if the boundary normal is in the Y direction.2020-07-02T07:43:53ZJaap StolkwaveMaker MultiPaddleFlap crashes if the boundary normal is in the Y direction.### Summary
<!-- Summarize the bug encountered concisely -->
waveMaker MultiPaddleFlap crashes if the boundary normal is in the Y direction.
### Steps to reproduce
in version v1912, copy the multiphase\interFoam\laminar\waves\waveMake...### Summary
<!-- Summarize the bug encountered concisely -->
waveMaker MultiPaddleFlap crashes if the boundary normal is in the Y direction.
### Steps to reproduce
in version v1912, copy the multiphase\interFoam\laminar\waves\waveMakerMultiPaddleFlap example.
- I have swapped X and Y of verices in system/blockMeshDict (attached) and adjusted the vertex order to keep the hex () definition CCW.
- I swapped the X and Y decomposition in system/decomposeParDict
- in 0.orig/pointDisplacement, I changed the normal vector to: n (0 1 0)
- then ran the case using the Allrun script.
### Example case
place the attached system/blockMeshDict in the v1912 multiphase\interFoam\laminar\waves\waveMakerMultiPaddleFlap example, and make the 2 additional modifications mentioned above.
### What is the current *bug* behaviour?
It results in a floatingpoint-error in Foam::waveMakerPointPatchVectorField::initialiseGeometry()
without any other errors or warnings logged. (see attached log.interFoam)
### What is the expected *correct* behavior?
The calculation should run as the original example, or produce an error message when the waveMaker normal vector is outside the supported range.
I tried to reproduce with minimal changes to an example case. In my original case I had the waveMaker boundary on the -Y side and swapping everything in my case in the x=y line resolved my crash, but now the postprocessing does not follow my other cases that have the waveMaker boundary on the -X side.
### Relevant logs and/or images
[blockMeshDict](/uploads/ecde43c3bda4ea4dbc9d45ab7a45423e/blockMeshDict)
[log.interFoam](/uploads/ac80e7fd15e51b2884e8eb6c2302b5b7/log.interFoam)
### Environment information
- OpenFOAM version : v1912 (compiled from source)
- Operating system : ubuntu
- Hardware info : 2x Intel(R) Xeon(R) E5-2690 2.9 GHz
- Hardware info : 1x AMD 1950X
- Compiler : gccv2012Kutalmış BerçinKutalmış Berçin