Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-03-13T14:40:17Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1312Suggestion to replace tensor J with symmTensor J in momentOfInertia class2020-03-13T14:40:17ZJohan RoenbySuggestion to replace tensor J with symmTensor J in momentOfInertia classThe moment of inertia tensor is always a symmetric 3x3 matrix.
I therefore suggest replacing all occurrences of "tensor J" with "symmTensor J" in:
https://develop.openfoam.com/Development/OpenFOAM-plus/tree/develop/src/meshTools/momentO...The moment of inertia tensor is always a symmetric 3x3 matrix.
I therefore suggest replacing all occurrences of "tensor J" with "symmTensor J" in:
https://develop.openfoam.com/Development/OpenFOAM-plus/tree/develop/src/meshTools/momentOfInertia
I have not encountered problems with the current implementation, but the change will make the code more mathematically consistent.v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1315add patch blacklisting to surfaceMeshExtract2019-07-09T18:04:27ZMark OLESENadd patch blacklisting to surfaceMeshExtract- similar idea as to foamToVTK -excludePatches
Cross-ref EP.1000- similar idea as to foamToVTK -excludePatches
Cross-ref EP.1000Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1320add function object to record execution/clock time2019-05-23T10:08:46ZMark OLESENadd function object to record execution/clock time@ivanspisso@ivanspissoMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1321overset incorrect addressing in parallel2020-01-08T14:34:07ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comoverset incorrect addressing 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
-->
<!--
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
<!-- Summarize the bug encountered concisely -->
Overset crashes if there are cells which have all donor cells remote. Part local/remote donors seems to be ok.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Out-of-range index on PtrList/UListMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1324faceMomentum mode in twoPhaseEulerFoam fails2019-06-13T20:45:32ZAdminfaceMomentum mode in twoPhaseEulerFoam fails<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
It seems that the faceMomentum option in twoPhaseEulerFoam which damps some nu...<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
It seems that the faceMomentum option in twoPhaseEulerFoam which damps some numerical oscillations that occur in a fully collocated Eulerian multiphase approach fails on commit f3e10059bd2f6c1f7aacdda91d059ca8ab7a2385. I imagine no commits since then have fixed this. The error occurs in both serial and parallel. The below error is reported:
`[0] --> FOAM FATAL ERROR:
[0] Operator + is undefined for oriented and unoriented types
[0]
[0] From function Foam::orientedType Foam::operator+(const Foam::orientedType&, const Foam::orientedType&)
[0] in file [3]
`
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
This can be reproduced easily by going to any included tutorial for twoPhaseEulerFoam and adding the line "faceMomentum yes;" to the PIMPLE section of fvSolution.https://develop.openfoam.com/Development/openfoam/-/issues/1327reduction on incorrect type (FieldFunctions)2019-07-09T18:04:14ZMark OLESENreduction on incorrect type (FieldFunctions)- while examining some changes for #1086, noticed that the unary global field reductions perform the reduce on the `Type` and not the `ReturnType`. For the current usage (where ReturnType == Type) there is no difference, but should be co...- while examining some changes for #1086, noticed that the unary global field reductions perform the reduce on the `Type` and not the `ReturnType`. For the current usage (where ReturnType == Type) there is no difference, but should be corrected to avoid future surprises.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1329attach/detach does not correctly set owner/neighbour2019-07-03T19:27:33ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comattach/detach does not correctly set owner/neighbour<!--
*** 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
<!-- Summarize the bug encountered concisely -->
(exchange platform 1010)
Issue: If statement does not check to see if face was modified in codeblock from lines 115 to 156 of attachInterface.C. This results in the attach instructions for the faces on the master patch being overwritten with old values for owner/neighbour/patchID.
The overall effect is that attachInterface.C:
deletes the faces from the slave patch as expected, but,
does not delete the faces from the master patch, and the cells across the faceZone are not attached. So the information in polymesh/<neighbour,boundary,owner> is incorrect
Adding a check to exclude faces that have been modified at line attachInterface.C:176 fixes this behaviour.
### Possible fixes
attachInterface.CMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1330ENH: Suppress tokens in result (name) for single field conversion2019-06-04T10:37:48ZPrashant SonakarENH: Suppress tokens in result (name) for single field conversion### Functionality to add/problem to solve
zeroGradient FO takes multiple fields into account for conversion. Appends suffix specified via tokens @@ in result keyword.
If we have single field to convert, can we suppress the requirement ...### Functionality to add/problem to solve
zeroGradient FO takes multiple fields into account for conversion. Appends suffix specified via tokens @@ in result keyword.
If we have single field to convert, can we suppress the requirement of such tokens?
### Links / references
EP#1018Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1332Forced physical solutions through solver2019-06-04T10:40:02ZAdminForced physical solutions through solver### Functionality to add/problem to solve
Solvers return solutions that are obviously non-physical.
At the moment, only advanced discretization schemes are used to (mainly) secure physical values of alpha, T, k, epsilon and similar. Thi...### Functionality to add/problem to solve
Solvers return solutions that are obviously non-physical.
At the moment, only advanced discretization schemes are used to (mainly) secure physical values of alpha, T, k, epsilon and similar. This could be improved by deliberately removing obvious non-physical solutions through solvers.
### Target audience
Those that use multiphase solver or turbulence or similar in their cases.
### Proposal
It could be solved by adding IF blocks in solvers:
IF (alpha<0) alpha=0;
IF (alpha>1) alpha=1;
Maybe some will see this as a feature that reduces the quality or the beauty of the calculations, but I think that the point of the calculations is to get the results that are as close to the real ones as possible and from that standpoint, I think that this feature would be good. Maybe because of that viewpoint, some lines for enabling this feature could be added to fvSolution dictionary:
forcePhysical
{
turnOn yes;
alpha.greaterThan 0;
alpha.smallerThan 1;
}
so that those that do not want to use this feature could not use it.
I think that this could be viewed as usual practise. During my studies, when I used one well-known software environment, in some calculations that should return real numbers, the result used to be, for example, ...+i*1e-20, so I deliberately used the IF blocks to remove those numerical errors, something like:
IF (imaginaryPart(number)<1e-10) {number=realPart(number)};
### What does success look like, and how can we measure that?
Test cases could be the already present tutorials. This way there is the possibility that even Gauss linear could be used, what could be good in some cases when some value changes drastically.
Error margins do not exist because no errors should be made if this is implemented correctly.
### Links / references
No links to literature.
### Funding
The functionality does not exist, but IF blocks exist and I think that the implementation should be relatively quick. I don't know who would sponsor this, but maybe some of the present sponsors would be interested because this would make the calculations more stable, what sounds as important for industry.https://develop.openfoam.com/Development/openfoam/-/issues/1333spurious time indexing for collated ensight write2019-06-28T09:50:42ZMark OLESENspurious time indexing for collated ensight writeAs noted in #1328 (@Prashant) - the areaWrite exhibits some odd output with ensight.
The cause traces back to the handling of time values, which are administered in the fieldDict. Both the less-than and the equal comparison operators ne...As noted in #1328 (@Prashant) - the areaWrite exhibits some odd output with ensight.
The cause traces back to the handling of time values, which are administered in the fieldDict. Both the less-than and the equal comparison operators need some additional tolerance.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1334overset patchFields no value field2019-07-02T09:24:37ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comoverset patchFields no value fieldoverset bc does not print value field so can only be post processed if liboverset.so was loadedoverset bc does not print value field so can only be post processed if liboverset.so was loadedMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1336particle traking problem across processors boundaries2019-06-11T23:15:26ZSergio Ferrarisparticle traking problem across processors boundaries![particle_tracking](/uploads/1474399da1e9504d84dee952fa080f04/particle_tracking.png)
It seems to be a problem with the tracking path of particles across processor boundaries. See pic. I assigned a constant value to all the cells throug...![particle_tracking](/uploads/1474399da1e9504d84dee952fa080f04/particle_tracking.png)
It seems to be a problem with the tracking path of particles across processor boundaries. See pic. I assigned a constant value to all the cells through which the particle crosses.At the interfaces of processors there are cells which are not
marked.https://develop.openfoam.com/Development/openfoam/-/issues/1341Improve lumped point functionality2020-06-19T14:38:04ZMark OLESENImprove lumped point functionality- Alternative euler orders for lumped point definitions
- with the more recent changes to quaternion and euler coordinate rotations we can now also support rotations
beyond the standard 'ZXZ' euler intrinsic rotations.
- cross ref: E...- Alternative euler orders for lumped point definitions
- with the more recent changes to quaternion and euler coordinate rotations we can now also support rotations
beyond the standard 'ZXZ' euler intrinsic rotations.
- cross ref: EP 1008
- Support multiple controllers (not just a single axis)
- Enable VTK output in parallel
Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1342GAMG uses hardcoded coarse-level solver2019-11-08T07:11:42ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comGAMG uses hardcoded coarse-level solver### Functionality to add/problem to solve
GAMG currently has two different methods for solving the coarsest level : direct or CG. It would be nice to override this behaviour
### Target audience
(Who will benefit from the changes?)
(W...### Functionality to add/problem to solve
GAMG currently has two different methods for solving the coarsest level : direct or CG. It would be nice to override this behaviour
### Target audience
(Who will benefit from the changes?)
(What type of cases?)
Parallel running
### Proposal
(How are we going to solve the problem?)
Allow specification of coarse-level solverMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1343Bug2020-03-13T13:32:51ZAdminBugI am trying to compile a new application on Ubuntu(new turbulence model), I get the following error:
In file included from /home/rozie/OpenFOAM/ThirdParty-v1812/platforms/linux64/gcc-6.3.0/include/c++/6.3.0/x86_64-pc-linux-gnu/bits/c++c...I am trying to compile a new application on Ubuntu(new turbulence model), I get the following error:
In file included from /home/rozie/OpenFOAM/ThirdParty-v1812/platforms/linux64/gcc-6.3.0/include/c++/6.3.0/x86_64-pc-linux-gnu/bits/c++config.h:507:0,
from /home/rozie/OpenFOAM/ThirdParty-v1812/platforms/linux64/gcc-6.3.0/include/c++/6.3.0/utility:68,
from /home/rozie/OpenFOAM/OpenFOAM-v1812/src/OpenFOAM/lnInclude/autoPtr.H:51,
from ../turbulenceModels/lnInclude/turbulenceModel.H:39,
from incompressibleTurbulenceModel.H:38,
from incompressibleTurbulenceModel.C:26:
/home/rozie/OpenFOAM/ThirdParty-v1812/platforms/linux64/gcc-6.3.0/include/c++/6.3.0/x86_64-pc-linux-gnu/bits/os_defines.h:39:22: fatal error: features.h: No such file or directory
#include <features.h>
^
compilation terminated.
\## Reattaching the author to the issue ticket: @Rozie123 ##https://develop.openfoam.com/Development/openfoam/-/issues/1344pressure with isentropic fails2019-06-19T13:30:19ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.compressure with isentropic fails<!--
*** 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 -->
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Following fails in e.g. rhoSimpleFoam tutorial:
```
isentropicPressure
{
type pressure;
libs ("libfieldFunctionObjects.so");
enabled yes;
writeControl writeTime;
calcIsen yes;
calcTotal no;
calcCoeff no;
result isenTropicP;
}
```
### Example case
compressible/rhoSimpleFoam/squareBend
<!--
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
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1345derivedFields fo creating fields without time instance2019-06-27T12:31:48ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comderivedFields fo creating fields without time instance@mark@markMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1346sampling (of sets) on patch only2019-06-27T12:31:49ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsampling (of sets) on patch only### Functionality to add/problem to solve
Sample boundary faces only using a definition similar to `uniform` set i.e. start & end
### Proposal
New sampledSet### Functionality to add/problem to solve
Sample boundary faces only using a definition similar to `uniform` set i.e. start & end
### Proposal
New sampledSetMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1348Adaptive mesh refinement fails when field relaxation is applied2019-12-09T22:37:29ZAdminAdaptive mesh refinement fails when field relaxation is applied<!--
*** 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 -->
If field relaxation combined with adaptive mesh refinement are used together, a simulation will fail. The following error is produced:
```
GAMGPCG: Solving for p_rgh, Initial residual = 9.32957e-07, Final residual = 5.87573e-11, No Iterations 3
[1]
[1]
[1] --> FOAM FATAL ERROR:
[1] Field<scalar> f1(15738), Field<scalar> f2(15738) and Field<scalar> f3(8906)
for operation f1 = f2 - f3
[1]
[1] From function void Foam::checkFields(const Foam::UList<T>&, const Foam::UList<Key>&, const Foam::UList<Type3>&, const char*) [with Type1 = double; Type2 = double; Type3 = double]
[1] in file /home/gavin/code/OpenFOAM-plus/src/OpenFOAM/lnInclude/FieldM.H at line 76.
```
My code is on commit d9cbe69c81c9382a8f55d11673ea7260f5907a5c.
This can be easily reproduced. Just go to tutorials/multiphase/interFoam/RAS/motorBike, set nOuterCorrectors to 2, and add relaxation to any field.AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1349possible build issue with non-MPI vtk and runTimePostProcessing2019-07-02T09:40:17ZMark OLESENpossible build issue with non-MPI vtk and runTimePostProcessingFlagged by @PawanFlagged by @PawanMark OLESENMark OLESEN