Development issueshttps://develop.openfoam.com/groups/Development/-/issues2016-12-23T16:24:51Zhttps://develop.openfoam.com/Development/openfoam/-/issues/292DriftfluxFoam does not produce a settling alpha field2016-12-23T16:24:51ZAdminDriftfluxFoam does not produce a settling alpha fieldSince the code update to 4.x, DriftfluxFoam does not settle. Now, this has been solved in OpenFOAM 4.x. I made a bugreport there: http://bugs.openfoam.org/view.php?id=2317 and it was solved by commit OpenFOAM-4.x commit 8e01ae0462c90f06a...Since the code update to 4.x, DriftfluxFoam does not settle. Now, this has been solved in OpenFOAM 4.x. I made a bugreport there: http://bugs.openfoam.org/view.php?id=2317 and it was solved by commit OpenFOAM-4.x commit 8e01ae0462c90f06af7fba33dca9fef5cb63f26e
Is it possible to merge this solution to the future release of OpenFOAM1612+?https://develop.openfoam.com/Development/openfoam/-/issues/454refineWallLayer does not run in parallel2017-06-29T20:38:04ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comrefineWallLayer does not run in parallelAt first sight there should be no problem with parallel operation.At first sight there should be no problem with parallel operation.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/507overset incompressible solvers do not set reference cell for pcorr2021-07-06T10:06:01ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comoverset incompressible solvers do not set reference cell for pcorr- they currently analyse on a per overset 'zone' basis
- this should be any disconnected region instead (so also ones resulting from blocked cells)- they currently analyse on a per overset 'zone' basis
- this should be any disconnected region instead (so also ones resulting from blocked cells)Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/673scalarRanges from string could be improved2018-01-23T15:54:43ZMark OLESENscalarRanges from string could be improvedAs noted discovered in #672 the creation of scalarRanges from a string uses an Istream for the intermediate tokens and parses through until it hits an error. This fails when the Istream is an ITstream since for that class the eof trig...As noted discovered in #672 the creation of scalarRanges from a string uses an Istream for the intermediate tokens and parses through until it hits an error. This fails when the Istream is an ITstream since for that class the eof triggers an error.
Would be cleanest to pass through the raw string directly create tokens and then walk through them in a normal loop.v1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/760A redundant setting (or a possible typo) in the tutorial: snappyMultiRegionHe...2018-03-13T13:24:20ZKutalmış BerçinA redundant setting (or a possible typo) in the tutorial: snappyMultiRegionHeaterHi,
In `decomposeParDict` of https://develop.openfoam.com/Development/OpenFOAM-plus/blob/c7969911bc736af70c14faa74496b8b7801baa91/tutorials/heatTransfer/chtMultiRegionFoam/snappyMultiRegionHeater/system/decomposeParDict
The following ...Hi,
In `decomposeParDict` of https://develop.openfoam.com/Development/OpenFOAM-plus/blob/c7969911bc736af70c14faa74496b8b7801baa91/tutorials/heatTransfer/chtMultiRegionFoam/snappyMultiRegionHeater/system/decomposeParDict
The following is written:
```
coeffs
{
n (2 2 1);
}
```
IMHO, it was forgotten to be deleted in one of the commits while changing the method from `hierarchial` to `scotch`.https://develop.openfoam.com/Development/openfoam/-/issues/874isoSurface on processor case (so not parallel) crashes since asks for patchNe...2021-07-06T13:00:29ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comisoSurface on processor case (so not parallel) crashes since asks for patchNeighbourFieldIf not running parallel should just use patchInternalField? Problem is that it also uses this routine to generate coordinates which then would be on top of each other.
See isoSurface::adaptPatchFields in sampling/surface/isoSurface/isoS...If not running parallel should just use patchInternalField? Problem is that it also uses this routine to generate coordinates which then would be on top of each other.
See isoSurface::adaptPatchFields in sampling/surface/isoSurface/isoSurfaceTemplates.Chttps://develop.openfoam.com/Development/openfoam/-/issues/893Need stderr or equivalent alternative to Info2020-05-23T11:04:36ZMark OLESENNeed stderr or equivalent alternative to InfoIn some situations informative output gets in the way of desired output (eg, foamDictionary output - EP702).
We can avoid some of this output with `argList::noBanner()`. In the .org version they have replace this with a dedicated InfoHe...In some situations informative output gets in the way of desired output (eg, foamDictionary output - EP702).
We can avoid some of this output with `argList::noBanner()`. In the .org version they have replace this with a dedicated InfoHeader message stream, which handles the same problem. However, we may also to have a more general solution (cf. #881).
In similar cases it could also be helpful to have a Serr that only outputs on the master.
With dynamic code generation (eg `#calc`) the process generated copious quantities of output, all of which land on stdout.
Perhaps we need a version of `system()` with a `dup2()` to redirect.
@Mattijsv1812Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/419externalCoupled uses reduce instead of scatter?2018-05-03T18:08:12ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comexternalCoupled uses reduce instead of scatter?Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/891"double" instead of "float"2018-07-02T09:34:22ZAdmin"double" instead of "float"The vtkSurfaceWriter places the "float" string in vtk files, where some versions of ParaView (specifically windows versions) require the "double" string to be present. As far as I can tell, all versions of ParaView work fine with the "d...The vtkSurfaceWriter places the "float" string in vtk files, where some versions of ParaView (specifically windows versions) require the "double" string to be present. As far as I can tell, all versions of ParaView work fine with the "double" string. I'm working on the master branch of OpenFOAM, commit 0770f9a384bb74492751c6b8068f2c01fac2c49f.
The following changes fix the problem:
diff --git a/src/sampling/sampledSurface/writers/vtk/vtkSurfaceWriter.C b/src/sampling/sampledSurface/writers/vtk/vtkSurfaceWriter.C
index 14a2716..f24b0cf 100644
--- a/src/sampling/sampledSurface/writers/vtk/vtkSurfaceWriter.C
+++ b/src/sampling/sampledSurface/writers/vtk/vtkSurfaceWriter.C
@@ -96,7 +96,7 @@ namespace Foam
const Field<scalar>& values
)
{
- os << "1 " << values.size() << " float" << nl;
+ os << "1 " << values.size() << " double" << nl;
forAll(values, elemI)
{
@@ -125,7 +125,7 @@ namespace Foam
const Field<vector>& values
)
{
- os << "3 " << values.size() << " float" << nl;
+ os << "3 " << values.size() << " double" << nl;
for (const vector& v : values)
{
@@ -143,7 +143,7 @@ namespace Foam
const Field<sphericalTensor>& values
)
{
- os << "1 " << values.size() << " float" << nl;
+ os << "1 " << values.size() << " double" << nl;
for (const sphericalTensor& v : values)
{
@@ -159,7 +159,7 @@ namespace Foam
const Field<symmTensor>& values
)
{
- os << "6 " << values.size() << " float" << nl;
+ os << "6 " << values.size() << " double" << nl;
for (const symmTensor& v : values)
{
@@ -179,7 +179,7 @@ namespace Foam
const Field<tensor>& values
)
{
- os << "9 " << values.size() << " float" << nl;
+ os << "9 " << values.size() << " double" << nl;
for (const tensor& v : values)
{
diff --git a/src/sampling/sampledSurface/writers/vtk/vtkSurfaceWriterTemplates.C b/src/sampling/sampledSurface/writers/vtk/vtkSurfaceWriterTemplates.C
index ee7c129..ddcf499 100644
--- a/src/sampling/sampledSurface/writers/vtk/vtkSurfaceWriterTemplates.C
+++ b/src/sampling/sampledSurface/writers/vtk/vtkSurfaceWriterTemplates.C
@@ -35,7 +35,7 @@ void Foam::vtkSurfaceWriter::writeData
const Field<Type>& values
)
{
- os << "1 " << values.size() << " float" << nl;
+ os << "1 " << values.size() << " double" << nl;
forAll(values, elemI)
{Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/61BUG: Tutorial case failure: multiphase/interDyMFoam/ras/motorBike2016-02-05T05:25:05ZPrashant SonakarBUG: Tutorial case failure: multiphase/interDyMFoam/ras/motorBikeThe restarted interDyMFoam job fails.
/home/alex2/prashant/OpenFOAM/OpenFOAM-plus.develop/tutorials/multiphase/interDyMFoam/ras/motorBike/log.interDyMFoam_restart
@andy @Sergio The restarted interDyMFoam job fails.
/home/alex2/prashant/OpenFOAM/OpenFOAM-plus.develop/tutorials/multiphase/interDyMFoam/ras/motorBike/log.interDyMFoam_restart
@andy @Sergio Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1160general cleanup items for containers2019-06-28T09:39:46ZMark OLESENgeneral cleanup items for containers- move some HashTable details into the Detail namespace
- avoid delete/new when calling HashSet::set()
- better handling of pointers in hashes (IO).
- FixedList output formatting influences pair/edge and thus we get things like `2{100}`...- move some HashTable details into the Detail namespace
- avoid delete/new when calling HashSet::set()
- better handling of pointers in hashes (IO).
- FixedList output formatting influences pair/edge and thus we get things like `2{100}` for a labelPair output. For these short lists it probably doesn't have much space saving. It would be nice to have the same output format for a Pair or a Tuple2 of the same content.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1149interCondensatingEvaporatingFoam mishandles heat conduction2019-02-22T02:57:23ZAdmininterCondensatingEvaporatingFoam mishandles heat conductionHey all,
I've tested interCondensatingEvaporatingFoam and found a pretty significant issue. If one takes a stagnant container with an initial condition of separated vapor and liquid phases, it appears that a strong temperature sink appe...Hey all,
I've tested interCondensatingEvaporatingFoam and found a pretty significant issue. If one takes a stagnant container with an initial condition of separated vapor and liquid phases, it appears that a strong temperature sink appears at the liquid/vapor interface. I noticed that this is because heat conduction is treated as laplacian(k/cp,e), which is wrong since e is discontinuous across the boundary due to the latent heat difference, and taking its gradient gives weird results.
I believe I can fix this issue, do I just submit a PR once it works?https://develop.openfoam.com/Development/openfoam/-/issues/465interCondensatingEvaporatingFoam for closed domain2017-05-09T15:41:27ZAdmininterCondensatingEvaporatingFoam for closed domainHello,
The solver shows a very strange behaviour for `alpha` field for closed domain cases. Simply after running the simulation for a while the entire domain reach `alpha = 1`. Indeed closed domains pose numerical challenges but usually...Hello,
The solver shows a very strange behaviour for `alpha` field for closed domain cases. Simply after running the simulation for a while the entire domain reach `alpha = 1`. Indeed closed domains pose numerical challenges but usually the problem appears due to `p` underspecification not `alpha`. I never had a similar experience with `interFoam` in closed domain cases.
To reproduce the issue:
* use the existing tutorial for this solver, `condensatingVessel`.
* set the `top` patch to wall.
* use the same boundary conditions for all fields as the `bottom` patch.
* add reference value for pressure in `pimple` subDict.
Note: I am using OpenFOAM-plus updated to commit e6cbe0b11923b2fe3ef24068af8da282db1c0978 to make sure I didn't miss any bug fix.
Thanks for your support, please let me know if further testes are required.
Best wishes,
Hassanhttps://develop.openfoam.com/Development/openfoam/-/issues/348Odd logic for treatment of blockMesh zones to sets2018-05-29T05:39:48ZMark OLESENOdd logic for treatment of blockMesh zones to setsIn the blockMesh application (around line 360 or so), the cell zones are written as sets (for ease of processing). Immediately *after* this, a `mesh.removeFiles()` is invoked prior to writing the mesh. Since the polyMesh::removeFiles als...In the blockMesh application (around line 360 or so), the cell zones are written as sets (for ease of processing). Immediately *after* this, a `mesh.removeFiles()` is invoked prior to writing the mesh. Since the polyMesh::removeFiles also removes the `sets` sub-directory, it doesn't look like the sets will survive very long.
Tagged in @Mattijs since he might have an idea.Version v1706https://develop.openfoam.com/Development/openfoam/-/issues/766profiling and number of calls2018-03-14T12:09:46Zvilfayeauprofiling and number of callsHi,
I'm using profiling to evaluate time execution and write of my function object. It reports 9999 calls when it is only evaluate and write at writeTime, i.e. the last time step:
`postPro1
{
type runTimePostProcessing...Hi,
I'm using profiling to evaluate time execution and write of my function object. It reports 9999 calls when it is only evaluate and write at writeTime, i.e. the last time step:
`postPro1
{
type runTimePostProcessing;
libs ("librunTimePostProcessing.so");
executeControl writeTime;
writeControl writeTime;
output
{
name image;
width 2000;
height 1200;
}
`
` trigger57
{
id 57;
parentId 30;
description "functionObject::postPro1::execute";
calls 9999;
totalTime 0.004897;
childTime 0;
onStack false;
}
trigger58
{
id 58;
parentId 30;
description "functionObject::postPro1::write";
calls 9999;
totalTime 0.004699;
childTime 0;
onStack false;
}
`
Is it normal?
Best,
Sebastienhttps://develop.openfoam.com/Development/openfoam/-/issues/312Separate build directory2018-05-29T05:39:49ZMark OLESENSeparate build directoryDuring recent discussions there was some interest expressed in a binary only distribution. This currently mostly possible by distributing bin/, etc/, platforms/ only. This of course loses that ability to have dynamic code, but can noneth...During recent discussions there was some interest expressed in a binary only distribution. This currently mostly possible by distributing bin/, etc/, platforms/ only. This of course loses that ability to have dynamic code, but can nonetheless be useful.
To make the distributed package smaller, need to manually strip out the dependencies and intermediate build targets.
Propose to split of these intermediates into a separate build/ directory as per third party.Version v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/509meanMomentumEnergyAndNMols.H bug?2017-06-29T20:38:03ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commeanMomentumEnergyAndNMols.H bug?src/lagrangian/molecularDynamics/molecule/mdTools/meanMomentumEnergyAndNMols.H:85
const vector& molOmega(inv(molMoI) & mol().pi());src/lagrangian/molecularDynamics/molecule/mdTools/meanMomentumEnergyAndNMols.H:85
const vector& molOmega(inv(molMoI) & mol().pi());Version v1706https://develop.openfoam.com/Development/openfoam/-/issues/161Bug smearing of interface in of2.3 and of2.42016-06-27T09:29:34ZAdminBug smearing of interface in of2.3 and of2.4[capillaryRisehe-5we-6OF23.zip](/uploads/862e6a8c1978d80b7e7b11cb80551a5e/capillaryRisehe-5we-6OF23.zip)
![capCompare](/uploads/978b8d176953e14fe17f78a9f651d7b6/capCompare.png)
Additional smearing of interface for spontaneous imbibit...[capillaryRisehe-5we-6OF23.zip](/uploads/862e6a8c1978d80b7e7b11cb80551a5e/capillaryRisehe-5we-6OF23.zip)
![capCompare](/uploads/978b8d176953e14fe17f78a9f651d7b6/capCompare.png)
Additional smearing of interface for spontaneous imbibition in micro-tube with OF2.3 and OF2.4 (interFoam). The test case was working well with OF2.1 and OF2.2. It also works well with OF-extend-3.1. https://develop.openfoam.com/Development/openfoam/-/issues/779Armclang support2023-12-07T19:03:27ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comArmclang supportAdd armclang support.Add armclang support.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/685BUG: incorrect dimensions for pressureTools2017-12-30T21:27:47ZPrashant SonakarBUG: incorrect dimensions for pressureToolsThe attached case replicates the issue.
- dimensions are incorrect for second iteration.
[cavity.tgz](/uploads/484b28a50405eb27e12492834fb953fb/cavity.tgz)
@Sergio @andy @MattijsThe attached case replicates the issue.
- dimensions are incorrect for second iteration.
[cavity.tgz](/uploads/484b28a50405eb27e12492834fb953fb/cavity.tgz)
@Sergio @andy @Mattijs