Development issueshttps://develop.openfoam.com/groups/Development/-/issues2024-01-16T06:05:40Zhttps://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/168Compile and Install OpenFOAM-v3.0+ on Ubuntu16.04 LTS -- hardcoded check on ...2016-06-30T09:10:05ZAdminCompile and Install OpenFOAM-v3.0+ on Ubuntu16.04 LTS -- hardcoded check on flex version numberWhen compiling OF3+ on the latest Ubuntu, it throws an error when compiling solidDisplacementFoam:
...platforms/linux64GccDPInt32Opt/lib/libtriSurface.so: undefined reference to `yyFlexLexer::yywrap()'
The issue and a workaround is...When compiling OF3+ on the latest Ubuntu, it throws an error when compiling solidDisplacementFoam:
...platforms/linux64GccDPInt32Opt/lib/libtriSurface.so: undefined reference to `yyFlexLexer::yywrap()'
The issue and a workaround is documented at http://dxln.blog.163.com/blog/static/31698071201632395924792/
(not my work)
It does solve the issue for me though.https://develop.openfoam.com/Development/openfoam/-/issues/594Incorrect documentation for the van Driest LES delta2019-01-09T21:15:59ZAdminIncorrect documentation for the van Driest LES deltaThe description of the van Driest LES delta is incorrect. It is currently a copy from the cubeRootVol delta, see
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/OpenFOAM-v1706/src/TurbulenceModels/turbulenceModels/LES/LESdel...The description of the van Driest LES delta is incorrect. It is currently a copy from the cubeRootVol delta, see
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/OpenFOAM-v1706/src/TurbulenceModels/turbulenceModels/LES/LESdeltas/vanDriestDelta/vanDriestDelta.H
Kind regards,
TimofeyKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/661surfaceFieldValue with faceZone restricted to boundary faces2017-12-20T09:40:03ZMark OLESENsurfaceFieldValue with faceZone restricted to boundary facesWas discussing this with @landmann - any reason not to simply use a owner/neighbour average value for internal faces?
@andy, @MattijsWas discussing this with @landmann - any reason not to simply use a owner/neighbour average value for internal faces?
@andy, @MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/196Inconsistent face ordering between hex and boundBox2019-12-09T22:04:11ZMark OLESENInconsistent face ordering between hex and boundBoxFrom code inspection the face definitions in boundBox appear to be wrong - different face order than the hex cellModel, inverted face normals.
For code-style: the treeBoundBox enum for FRONT/BACK, TOP/BOTTOM could be misleading since ...From code inspection the face definitions in boundBox appear to be wrong - different face order than the hex cellModel, inverted face normals.
For code-style: the treeBoundBox enum for FRONT/BACK, TOP/BOTTOM could be misleading since TOP in this case designates +y and not +z as may be expected.
Will send additional notes per email.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/990BUG: Incorrect points reported in multiSolidBody motion2019-12-09T22:22:46ZPrashant SonakarBUG: Incorrect points reported in multiSolidBody motionsrc/dynamicMesh/motionSolvers/displacement/solidBody/multiSolidBodyMotionSolver.C
should report total points being used. It reports only from master at the moment.
```
Info<< "Applying solid body motion " << SBMFs_[zonei]....src/dynamicMesh/motionSolvers/displacement/solidBody/multiSolidBodyMotionSolver.C
should report total points being used. It reports only from master at the moment.
```
Info<< "Applying solid body motion " << SBMFs_[zonei].type()
<< " to "
<< returnReduce(pointIDs_[zonei].size(), sumOp<label>())
<< " points of cellZone " << iter().keyword() << endl;
```
@Mattijs @andy @Sergio
Cross reference: EP#793https://develop.openfoam.com/Development/openfoam/-/issues/1094Gravity uniform field cannot be used cleanly in dynamic mesh boundary conditions2018-11-27T06:18:02ZAdminGravity uniform field cannot be used cleanly in dynamic mesh boundary conditionsGravity is read and registered on the mesh database typically in the application's `createFields.H`, after the construction of the mesh. In moving mesh cases the mesh has already been constructed by this point in the execution, and so g...Gravity is read and registered on the mesh database typically in the application's `createFields.H`, after the construction of the mesh. In moving mesh cases the mesh has already been constructed by this point in the execution, and so gravity cannot be accessed (easily).v1812AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/447Lagrangian: problematic tracking with dynamic meshes2018-07-03T10:45:44ZAdminLagrangian: problematic tracking with dynamic meshesWhen using a dynamic mesh solver, the tracking of a particle may be wrong: the particle may not cross an internal face when it is moving parallel to other one. Particle rescues are not enough.
I attach a solver "dMeshSprayFoam" (based...When using a dynamic mesh solver, the tracking of a particle may be wrong: the particle may not cross an internal face when it is moving parallel to other one. Particle rescues are not enough.
I attach a solver "dMeshSprayFoam" (based on sprayDyMFoam but it only updates the mesh and evolved the particles) and a simple case named "EjemploMM". I also attach a video which shows the particle tracking problem.
After investigating the problem I found that it starts in line 175 of particleI.H: "tetPointRef tet00 = tetIs.oldTet(mesh_)". This tetrahedron has a problem in its first point which is an oldCellCenter calculated in line 89 of tetIndicesI.H.
I think that there is an issue with the memory reference of this point.
[ProblematicTracking.tar.gz](/uploads/72931680ec544f389a19e302882321a9/ProblematicTracking.tar.gz)![Injection](/uploads/2b61edcd19ff3b30d5d5b63fb9c09e82/Injection.ogv)https://develop.openfoam.com/Development/openfoam/-/issues/715pimpleFoam in OF1612 shows same time step twice in log file2019-07-03T19:49:21ZAdminpimpleFoam in OF1612 shows same time step twice in log fileHi,
I recently installed OF1612 on my Uni's cluster (Scientific Linux 6.9 (Carbon)) without sudo right. I have been testing it using a wavy channel flow case. I found out if I set the timePrecision and writePrecision to 6, same time ste...Hi,
I recently installed OF1612 on my Uni's cluster (Scientific Linux 6.9 (Carbon)) without sudo right. I have been testing it using a wavy channel flow case. I found out if I set the timePrecision and writePrecision to 6, same time step will appear twice in the log file and the probed data in postProcessing:
In log file:
```
Time = 11.0001
PIMPLE: iteration 1
DILUPBiCG: Solving for Ux, Initial residual = 0.000628327, Final residual = 6.49228e-06, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 0.00710122, Final residual = 7.02765e-06, No Iterations 4
DILUPBiCG: Solving for Uz, Initial residual = 0.00741627, Final residual = 1.45782e-06, No Iterations 5
Pressure gradient source: uncorrected Ubar = 0.3, pressure gradient = 0.188916
DICPCG: Solving for p, Initial residual = 0.198051, Final residual = 0.00192128, No Iterations 611
time step continuity errors : sum local = 2.37292e-07, global = -1.72581e-07, cumulative = -5.94041e-07
Pressure gradient source: uncorrected Ubar = 0.300001, pressure gradient = 0.147912
DICPCG: Solving for p, Initial residual = 0.0992778, Final residual = 9.82839e-07, No Iterations 762
time step continuity errors : sum local = 1.72608e-07, global = -1.72581e-07, cumulative = -7.66622e-07
Pressure gradient source: uncorrected Ubar = 0.300002, pressure gradient = 0.141237
ExecutionTime = 52.3 s ClockTime = 52 s
Courant Number mean: 0.0777575 max: 3.3662
Time = 11.0001
PIMPLE: iteration 1
DILUPBiCG: Solving for Ux, Initial residual = 0.000555812, Final residual = 7.84982e-07, No Iterations 3
DILUPBiCG: Solving for Uy, Initial residual = 0.00624087, Final residual = 2.50926e-07, No Iterations 4
DILUPBiCG: Solving for Uz, Initial residual = 0.00659523, Final residual = 8.90043e-06, No Iterations 2
Pressure gradient source: uncorrected Ubar = 0.3, pressure gradient = 0.126081
DICPCG: Solving for p, Initial residual = 0.137678, Final residual = 0.00136057, No Iterations 522
time step continuity errors : sum local = 1.76456e-07, global = -1.43068e-07, cumulative = -9.0969e-07
Pressure gradient source: uncorrected Ubar = 0.3, pressure gradient = 0.153548
DICPCG: Solving for p, Initial residual = 0.0448662, Final residual = 9.80399e-07, No Iterations 680
time step continuity errors : sum local = 1.43092e-07, global = -1.43068e-07, cumulative = -1.05276e-06
Pressure gradient source: uncorrected Ubar = 0.299999, pressure gradient = 0.156989
ExecutionTime = 72.1 s ClockTime = 72 s
Courant Number mean: 0.0777578 max: 4.50452
Time = 11.0002
PIMPLE: iteration 1
DILUPBiCG: Solving for Ux, Initial residual = 0.000544009, Final residual = 3.90541e-06, No Iterations 1
DILUPBiCG: Solving for Uy, Initial residual = 0.00601562, Final residual = 2.7355e-06, No Iterations 3
DILUPBiCG: Solving for Uz, Initial residual = 0.00635443, Final residual = 5.66006e-06, No Iterations 3
Pressure gradient source: uncorrected Ubar = 0.3, pressure gradient = 0.158873
DICPCG: Solving for p, Initial residual = 0.0671597, Final residual = 0.000644585, No Iterations 467
time step continuity errors : sum local = 1.35701e-07, global = -1.20709e-07, cumulative = -1.17347e-06
Pressure gradient source: uncorrected Ubar = 0.3, pressure gradient = 0.154128
DICPCG: Solving for p, Initial residual = 0.0185901, Final residual = 9.677e-07, No Iterations 698
time step continuity errors : sum local = 1.20732e-07, global = -1.20709e-07, cumulative = -1.29418e-06
Pressure gradient source: uncorrected Ubar = 0.3, pressure gradient = 0.153915
ExecutionTime = 90.76 s ClockTime = 91 s
Courant Number mean: 0.077758 max: 2.9458
Time = 11.0002
PIMPLE: iteration 1
DILUPBiCG: Solving for Ux, Initial residual = 0.000541136, Final residual = 2.5145e-06, No Iterations 2
DILUPBiCG: Solving for Uy, Initial residual = 0.00600186, Final residual = 5.11656e-06, No Iterations 2
DILUPBiCG: Solving for Uz, Initial residual = 0.00634764, Final residual = 4.17754e-06, No Iterations 2
Pressure gradient source: uncorrected Ubar = 0.3, pressure gradient = 0.153745
DICPCG: Solving for p, Initial residual = 0.0565432, Final residual = 0.000557925, No Iterations 528
time step continuity errors : sum local = 1.16266e-07, global = -1.03347e-07, cumulative = -1.39752e-06
Pressure gradient source: uncorrected Ubar = 0.3, pressure gradient = 0.152974
DICPCG: Solving for p, Initial residual = 0.0136746, Final residual = 9.9346e-07, No Iterations 656
time step continuity errors : sum local = 1.03369e-07, global = -1.03347e-07, cumulative = -1.50087e-06
Pressure gradient source: uncorrected Ubar = 0.3, pressure gradient = 0.154393
ExecutionTime = 110.86 s ClockTime = 111 s
Courant Number mean: 0.077758 max: 2.6735
```
and in probed data:
```
# Probe 0 1
# Time
11.2001 (0.346425 -0.0206927 -0.0443701) (0.396648 -0.0308353 0.0045432)
11.2001 (0.346504 -0.0208275 -0.0438397) (0.396732 -0.0307284 0.00444979)
11.2002 (0.346596 -0.0209262 -0.0432698) (0.39684 -0.030652 0.00439261)
11.2002 (0.346701 -0.0209961 -0.0426602) (0.396971 -0.0306104 0.00437403)
```
Changing the timePrecision and writePrecision from 6 to 7 solves the problem. But I think there is a bug as the precision should be increased automatically if the program senses above problem. This is what OF230 did, in a similar case in OF230 (the precisions were 6 as well), the log file showed following and the time step were displayed correctly:
```
--> FOAM Warning :
From function Time::operator++()
in file db/Time/Time.C at line 1055
Increased the timePrecision from 6 to 7 to distinguish between timeNames at time 10.67
```
However, I think there is also a bug in OF230, because although OF230 automatically increase the precision in log file, it's probed data still show the same time steps twice.
The above issues can be reproduced.
I have discussed above problem in cfd-online forum and people thought it may be a bug. The link of the thread is: https://www.cfd-online.com/Forums/openfoam-bugs/197814-pimplefoam-of1612-shows-same-time-step-twice-log-file.html
Please can you have an investigation and solve the problem.
Kind regards,
YeruKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/745Sampling does not stop at 'end'2019-12-09T22:18:10ZAdminSampling does not stop at 'end'Hi,
I stumbled over a bug, namely that running with the function object 'sets', then sampling continues beyond the point 'end' in the set definition. This bug is reproducible with the damBreak case. Simply test with this function object...Hi,
I stumbled over a bug, namely that running with the function object 'sets', then sampling continues beyond the point 'end' in the set definition. This bug is reproducible with the damBreak case. Simply test with this function object (sorry for the formatting):
functions
{
testSet
{
type sets;
functionObjectLibs ("libsampling.so");
writeControl timeStep; //adjustableRunTime;
writeInterval 1;
setFormat raw;
interpolationScheme cellPointFace;
fields ( alpha.water );
sets
(
gauge_1
{
type face;
axis y;
start (0.02 0.20 0.005);
end (0.02 0.25 0.005);
nPoints 100;
}
gauge_2
{
type face;
axis y;
start (0.2 0.03 0.005);
end (0.2 0.55 0.005);
nPoints 100;
}
);
}
}
The problem is fixed by changing line 78 in faceOnlySet.C from
OLD>> if (mag(trackPt - end_) < smallDist)
to
NEW>> if (smallDist < ((trackPt - end_) & (end_ - start_)))
The old formulation only ends, if the absolute distance is less than smallDist, which will hardly ever happen. The new formulation makes a projection along the search direction and the search stops as soon as the value become larger than smallDist.
A quick check showed the same error in foam-extend-3.1, so the bug seems to have been around for a long time.
Kind regards
NielsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/786Bug or feature: Pimple solves pressure to final convergence on every iteration2020-07-31T15:13:36ZAdminBug or feature: Pimple solves pressure to final convergence on every iterationI've switched from the 1606+ version to the latest 1712+ version. I noticed that my pimpleFoam computations take a lot more time. When I looked at the pressure iterations the last nonOrthogonal correction solves the pressure to the final...I've switched from the 1606+ version to the latest 1712+ version. I noticed that my pimpleFoam computations take a lot more time. When I looked at the pressure iterations the last nonOrthogonal correction solves the pressure to the final convergence criterion. (See lines 7,15,23 in 1712log). The 1606 solver does not converge to the final convergence (see line 10 in 1606log). It is not the same simulation. These logs I had ready. I did do the test though.
If you would like to reproduce just take a pimple case (running in pimple mode) and see the difference between the two versions.
This is caused by a change in the pimplecontrol class. In older versions the finalInnerIter read:
`
inline bool Foam::pimpleControl::finalInnerIter() const
{
return
finalIter()
&& corrPISO_ == nCorrPISO_
&& corrNonOrtho_ == nNonOrthCorr_ + 1;
}
`
In the 1712 version it reads:
`
inline bool Foam::pimpleControl::finalInnerIter() const
{
return
corrPISO_ == nCorrPISO_
&& corrNonOrtho_ == nNonOrthCorr_ + 1;
}
`
When adding the `finalIter()` I see the previous (1606) behaviour again.
I have to admit that it is a bit of a black box for me, so I don't know what it does and what's the reason behind removing this statement. It does slow down my simulations with a factor 2-3, so it might be worth changing it back.[1606Log](/uploads/242f7062ba35c345938c5056c1daf4a8/1606Log)[1712Log][1606Log](/uploads/538a7fd214ba363e587989507379dd5a/1606Log)https://develop.openfoam.com/Development/openfoam/-/issues/266Unify surface area/normal calculations2017-01-02T12:22:12ZMark OLESENUnify surface area/normal calculationsNeed face areas and normals for meshed surfaces in several places. It makes sense to relocate this frequently needed functionality to PrimitivePatch. PolyPatch continues to use a slice field for efficiency on poly meshes.Need face areas and normals for meshed surfaces in several places. It makes sense to relocate this frequently needed functionality to PrimitivePatch. PolyPatch continues to use a slice field for efficiency on poly meshes.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1039rigid body motion solver2021-07-06T13:28:55ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comrigid body motion solverGeneric issues with rigid body motion solverGeneric issues with rigid body motion solverhttps://develop.openfoam.com/Development/openfoam/-/issues/1298parProfiling output cleanup2023-12-07T19:00:15ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comparProfiling output cleanupparProfiling output is not very clear.
- negative numbers
- gets output twice
```
parProfiling:
reduce : avg = 77.2517s
min = -97.6182% (processor 0)
max = +21.4343% (processor 4)
all-all : avg = 13.3667s...parProfiling output is not very clear.
- negative numbers
- gets output twice
```
parProfiling:
reduce : avg = 77.2517s
min = -97.6182% (processor 0)
max = +21.4343% (processor 4)
all-all : avg = 13.3667s
min = -18.3042% (processor 5)
max = +11.6958% (processor 4)
parProfiling:
reduce : avg = 77.2517s
min = -97.6182% (processor 0)
max = +21.4343% (processor 4)
all-all : avg = 13.3667s
min = -18.3042% (processor 5)
max = +11.6958% (processor 4)
```https://develop.openfoam.com/Development/openfoam/-/issues/99BUG: incorrect camera position for nFrames>1 (runTimePostProcessing)2023-12-07T19:01:59ZPrashant SonakarBUG: incorrect camera position for nFrames>1 (runTimePostProcessing)It seems the position should be
position_ = currentFrameI_*dPosition_;
instead of
position_ += currentFrameI_*dPosition_;
in $FOAM_SRC/postProcessing/functionObjects/graphics/runTimePostProcessing/scene.CIt seems the position should be
position_ = currentFrameI_*dPosition_;
instead of
position_ += currentFrameI_*dPosition_;
in $FOAM_SRC/postProcessing/functionObjects/graphics/runTimePostProcessing/scene.CAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1144inheritance pattern with chemistry reader2021-07-06T14:52:39ZMark OLESENinheritance pattern with chemistry readerAs noted on [cfd-online](https://www.cfd-online.com/Forums/openfoam-programming-development/213451-multiple-inheritance-paradigms-openfoam.html) the inheritance with an `autoPtr` probably not needed. Could be replaced with member composi...As noted on [cfd-online](https://www.cfd-online.com/Forums/openfoam-programming-development/213451-multiple-inheritance-paradigms-openfoam.html) the inheritance with an `autoPtr` probably not needed. Could be replaced with member composition instead.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1190create module ignores -output option2019-12-09T22:37:28ZMark OLESENcreate module ignores -output optionalso no easy way to pass in preferences
@ivanspissoalso no easy way to pass in preferences
@ivanspissoMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1296inconsistent handling of trapping exceptions between IOerror and error2019-05-20T12:44:37ZMark OLESENinconsistent handling of trapping exceptions between IOerror and errorWith the #575 change (87fdc2eaf3cd8c3bb005e110802b7053dc7eed79) it is possible to throw/catch exceptions in parallel, but this was not propagated to IOerror.With the #575 change (87fdc2eaf3cd8c3bb005e110802b7053dc7eed79) it is possible to throw/catch exceptions in parallel, but this was not propagated to IOerror.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/866vtkWrite support for Lagrangian data2019-06-28T09:51:57ZAdminvtkWrite support for Lagrangian dataHas vtkWrite support been implemented for Lagrangian? If not, could this be implemented ASAP. We have some cases that we want to animate, and using the old approach of writing the Lagrangian data only, then reconstructing, then convert...Has vtkWrite support been implemented for Lagrangian? If not, could this be implemented ASAP. We have some cases that we want to animate, and using the old approach of writing the Lagrangian data only, then reconstructing, then converting to vtk is very unwieldy. We’d like to write the spray data in vtk format directly from a functionObject, and be able to select which associated spray properties (d, U, nP, etc.) get output.
KarlMark OLESENMark OLESEN