Development issueshttps://develop.openfoam.com/groups/Development/-/issues2019-04-08T15:04:14Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1269possible regression in uniformFixedValuePointPatch?2019-04-08T15:04:14ZMark OLESENpossible regression in uniformFixedValuePointPatch?In tutorials/basic/overLaplacianDyMFoam/heatTransfer I'm getting some very odd output which I think could be related to this commit: 0987898f5c1678
I initially thought it might be related to the generic point patches since reconstructPa...In tutorials/basic/overLaplacianDyMFoam/heatTransfer I'm getting some very odd output which I think could be related to this commit: 0987898f5c1678
I initially thought it might be related to the generic point patches since reconstructPar was failing when fill-nan is set. The values it reconstructs for the pointDisplacement right1 boundary are scalars, not vectors.
Backtracking some more, it seems that the original decomposed fields are a bit *odd*.
In 1812:
processor0/0/pointDisplacement.right1
right1
{
type uniformFixedValue;
value nonuniform 0();
uniformValue constant (0 0 0);
}
In develop:
processor0/0/pointDisplacement.right1
right1
{
type uniformFixedValue;
uniformValue ( 0 0 0 );
}
At later times this looks different again. Eg, processor0/0.5/pointDisplacement.right1
1812:
right1
{
type uniformFixedValue;
value nonuniform 0();
uniformValue constant (0 0 0);
}
develop:
right1
{
type uniformFixedValue;
value nonuniform 0();
uniformValue nonuniform 0();
}
When this is reconstructed, the generic point patch process the entries quite badly. Even the output for `value` does not look correct.
@PrashantMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/834Micro change in nutUBlendedWallFunction?2020-06-12T17:34:59ZKutalmış BerçinMicro change in nutUBlendedWallFunction?Hi,
Please consider `Foam::nutTestUBlendedWallFunctionFvPatchScalarField::calcUTau`:
```c
tmp<scalarField> tuTaup(new scalarField(patch().size(), 0.0));
scalarField& uTaup = tuTaup.ref();
const scalarField& nutw = *this;
...Hi,
Please consider `Foam::nutTestUBlendedWallFunctionFvPatchScalarField::calcUTau`:
```c
tmp<scalarField> tuTaup(new scalarField(patch().size(), 0.0));
scalarField& uTaup = tuTaup.ref();
const scalarField& nutw = *this;
forAll(uTaup, facei)
{
scalar ut = sqrt((nutw[facei] + nuw[facei])*magGradU[facei]);
if (mag(ut) > ROOTVSMALL)
{
scalar error = GREAT;
label iter = 0;
while (iter++ < 10 && error > 0.001)
{
scalar yPlus = y[facei]*ut/nuw[facei];
scalar uTauVis = magUp[facei]/yPlus;
scalar uTauLog = kappa_*magUp[facei]/log(E_*yPlus);
scalar utNew = pow(pow(uTauVis, n_) + pow(uTauLog, n_), 1.0/n_);
error = mag(ut - utNew)/(ut + ROOTVSMALL);
ut = 0.5*(ut + utNew);
}
}
uTaup[facei] = ut;
}
return tuTaup;
```
Without sacrificing readability, wouldn't be possible to remove `new scalarField(patch().size(), 0.0)` and simplify the rest accordingly?
```c
const scalarField& nutw = *this;
tmp<scalarField> tuTaup = sqrt((nutw + nuw)*magGradU);
scalarField& uTaup = tuTaup.ref();
forAll(uTaup, facei)
{
if (mag(uTaup[facei]) > ROOTVSMALL)
{
scalar error = GREAT;
label iter = 0;
while (error > 0.001 && iter++ < 10)
{
scalar yPlus = y[facei]*uTaup[facei]/nuw[facei];
scalar uTauVis = magUp[facei]/yPlus;
scalar uTauLog = kappa_*magUp[facei]/log(E_*yPlus);
scalar utNew = pow(pow(uTauVis, n_) + pow(uTauLog, n_), 1.0/n_);
error = mag(uTaup[facei] - utNew)/(uTaup[facei] + ROOTVSMALL);
uTaup[facei] = 0.5*(uTaup[facei] + utNew);
}
}
}
return tuTaup;
```
Also, in `while (iter++ < 10 && error > 0.001)`, I observed for a typical channel case I run that `error > 0.001` becomes `False` quicker than `iter++ < 10`. Might be wiser to swap `error` and `iter`, so that `while` exits without testing `iter` redundantly when `error < 0.001`?v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/121BUG: zoom function in runTimePostProcessing FO2023-12-07T19:01:58ZPrashant SonakarBUG: zoom function in runTimePostProcessing FOThe zoom function doesn't seem to have any effect on resulting image.
(in the code, cameraZoom_ is not used after assignment) The zoom function doesn't seem to have any effect on resulting image.
(in the code, cameraZoom_ is not used after assignment) AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/932single-precision compilation2019-12-09T22:22:46ZMark OLESENsingle-precision compilationMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/512cleanup construction selectors2017-07-10T12:42:23ZMark OLESENcleanup construction selectorsCan use `auto` with that hashtable `cfind` for simpler looking code.Can use `auto` with that hashtable `cfind` for simpler looking code.v1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/904hard-coded name separators in foamCreateVideo2018-07-02T09:39:22ZMark OLESENhard-coded name separators in foamCreateVideo- looks for things like `image.0001.png`, but default Catalyst scripts will generate `image_0001.png`, and with additional amounts of padding (eg, `pressure_00020056.png`) which are needed when generating a higher time resolution visuali...- looks for things like `image.0001.png`, but default Catalyst scripts will generate `image_0001.png`, and with additional amounts of padding (eg, `pressure_00020056.png`) which are needed when generating a higher time resolution visualization.v1806Mark OLESENMark OLESENhttps://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/870distanceSurface is very picky2018-07-02T09:34:41ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdistanceSurface is very pickyIf
- the surface is open
- and the nearest point on the surface is on one of the open edges
the distanceSurface seems to pick up the 'wrong' normal. What is the normal on an open edge?
Workaround is to always make sure your surface is ...If
- the surface is open
- and the nearest point on the surface is on one of the open edges
the distanceSurface seems to pick up the 'wrong' normal. What is the normal on an open edge?
Workaround is to always make sure your surface is big enough so all mesh points project onto its interior.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1253missing -dict on some utilities2020-01-08T14:35:27ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commissing -dict on some utilities### Functionality to add/problem to solve
Some utilities are still missing the -dict option to specify an alternative location.
E.g. extrudeMesh.### Functionality to add/problem to solve
Some utilities are still missing the -dict option to specify an alternative location.
E.g. extrudeMesh.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1171maxDeltaxyzCubeRootLESDelta doubly registers 'hmax'2021-12-09T20:12:38ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commaxDeltaxyzCubeRootLESDelta doubly registers 'hmax'maxDeltaxyzCubeRootLESDelta constructs three LESdelta. Each of them uses the same name (and tries to register it).
Run any case with debug flag
```
regIOobject 2;
```maxDeltaxyzCubeRootLESDelta constructs three LESdelta. Each of them uses the same name (and tries to register it).
Run any case with debug flag
```
regIOobject 2;
```v2112Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/479non-virtual methods on streams2017-07-08T09:17:18ZMark OLESENnon-virtual methods on streamsOFstream::name() and IFstream::name() are (intentionally/non-intentionally?) non-virtual.
- Implemented as virtual in Istream, ISstream, Ostream, OSstream, but not in IFstream, OFstream, ITstream.OFstream::name() and IFstream::name() are (intentionally/non-intentionally?) non-virtual.
- Implemented as virtual in Istream, ISstream, Ostream, OSstream, but not in IFstream, OFstream, ITstream.v1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/170unset shell functions failing in dash2017-01-26T15:22:26ZMark OLESENunset shell functions failing in dashneed "unset -f" instead of a plain "unset" to properly unset functions.
affects the etc/config.sh/functionsneed "unset -f" instead of a plain "unset" to properly unset functions.
affects the etc/config.sh/functionsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/382inverseDistanceDiffusivity is hardcoded to patchWave2018-05-29T05:39:49ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.cominverseDistanceDiffusivity is hardcoded to patchWaveAttached is a version of inverseDistanceDiffusivity that uses the 'wallDist' entry in the fvSchemes. Is untested.
[inverseDistanceDiffusivity.C](/uploads/edcc6e6fb85567366ed49d8164a5d739/inverseDistanceDiffusivity.C)Attached is a version of inverseDistanceDiffusivity that uses the 'wallDist' entry in the fvSchemes. Is untested.
[inverseDistanceDiffusivity.C](/uploads/edcc6e6fb85567366ed49d8164a5d739/inverseDistanceDiffusivity.C)https://develop.openfoam.com/Development/openfoam/-/issues/664BUG: overset hole cutting not correct in parallel2021-07-08T21:46:39ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comBUG: overset hole cutting not correct in parallelincompressible/overPimpleDyMFoam/simpleRotor with attached controlDict and decomposePar produces incorrect hole cutting at time Time = 0.00478355:
```
calculated : 196
instead of say
calculated : 1281
```
[controlDict](/uplo...incompressible/overPimpleDyMFoam/simpleRotor with attached controlDict and decomposePar produces incorrect hole cutting at time Time = 0.00478355:
```
calculated : 196
instead of say
calculated : 1281
```
[controlDict](/uploads/770c830ac0284f22ea518396552b6e7e/controlDict)[decomposeParDict](/uploads/4c71bc99ad6b1c94eb7886c4f3f60778/decomposeParDict)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/491stl reads points in double precision2017-06-14T13:48:15ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comstl reads points in double precisionIn v1612+ triSurface reads points in single precision, in develop it is double precision.In v1612+ triSurface reads points in single precision, in develop it is double precision.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/202decomposePar -cellDist misses patches2019-12-09T22:04:11ZMark OLESENdecomposePar -cellDist misses patchesIt would be easier to visualize if patches were included in `cellDist` as well.It would be easier to visualize if patches were included in `cellDist` as well.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1263Missing inline for boundBox::nDim2019-12-09T22:37:28ZMark OLESENMissing inline for boundBox::nDimMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/852Feature: avoid meshing in given arbitrary region2018-07-04T10:46:04ZPrashant SonakarFeature: avoid meshing in given arbitrary regionRefer : EP#648
- capability to avoid meshing in given closed domain. this can help to use wrapped meshes to avoid leakRefer : EP#648
- capability to avoid meshing in given closed domain. this can help to use wrapped meshes to avoid leakMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/371STYLE: Correct documentation vector field2019-12-09T21:29:27ZPrashant SonakarSTYLE: Correct documentation vector fieldvalue should be vector input at
src/finiteVolume/lnInclude/pressureInletOutletVelocityFvPatchVectorField.H
@Mattijsvalue should be vector input at
src/finiteVolume/lnInclude/pressureInletOutletVelocityFvPatchVectorField.H
@MattijsVersion v1706AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/204Simplify, cleanup mesh conversion infrastructure2017-12-18T23:19:31ZMark OLESENSimplify, cleanup mesh conversion infrastructureWill continue for 1706 as wellWill continue for 1706 as wellVersion v1706Mark OLESENMark OLESEN