Development issueshttps://develop.openfoam.com/groups/Development/-/issues2019-12-09T22:04:10Zhttps://develop.openfoam.com/Development/openfoam/-/issues/177ENH: Description update for fanFvPatchField.H2019-12-09T22:04:10ZPrashant SonakarENH: Description update for fanFvPatchField.HWith change in CSV file input, the description of fanFvPatchField.H needs update.
@andy @Mattijs With change in CSV file input, the description of fanFvPatchField.H needs update.
@andy @Mattijs Version v1612Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/176general configuration scripts2016-12-23T12:44:51ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comgeneral configuration scriptsVarious small script changes.Various small script changes.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/285Noise utility and models - unable to use environment variables for input files2016-11-28T05:07:21ZAdminNoise utility and models - unable to use environment variables for input filesCurrently the file names are not expanded for the control dictionary and surface noise model, so we cannot use `"$FOAM_CASE/..."` etcCurrently the file names are not expanded for the control dictionary and surface noise model, so we cannot use `"$FOAM_CASE/..."` etcVersion v1612https://develop.openfoam.com/Development/openfoam/-/issues/973ENH: feature request for ensight export2018-12-19T09:37:17ZPrashant SonakarENH: feature request for ensight exportAdd a bounding box to limit the region
cross ref EP#766Add a bounding box to limit the region
cross ref EP#766Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/181warning about GUI resource files in paraview plugins2016-12-23T12:44:51ZMark OLESENwarning about GUI resource files in paraview pluginsBuilding the Paraview plugins generates the following warning:
GUI resource files in plugins are no longer supported.
The same functionality can be obtained using Hints in the Server Manager xml files.
See the Major API ...Building the Paraview plugins generates the following warning:
GUI resource files in plugins are no longer supported.
The same functionality can be obtained using Hints in the Server Manager xml files.
See the Major API Changes document for details.
Hints already exist in the server manager xml, just need to correct the CMakeLists.txt to account for the API change with Paraview 4.3 Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/481BlockMesh: Implicit initialization of member overwrites previous initialization2017-06-29T20:38:04ZAdminBlockMesh: Implicit initialization of member overwrites previous initializationin src/mesh/blockMesh/blockEdges/arcEdge/arcEdge.H the members are declared in the following order:
```
point p1_, p2_, p3_;
cylindricalCS cs_;
scalar angle_;
scalar radius_;
```
in the constructor calcAngle() ...in src/mesh/blockMesh/blockEdges/arcEdge/arcEdge.H the members are declared in the following order:
```
point p1_, p2_, p3_;
cylindricalCS cs_;
scalar angle_;
scalar radius_;
```
in the constructor calcAngle() is called which sets angle_ and radius_.
If scalar is anything but a primitive type the default constructor of angle_ and radius_ will be called after calcAngle returns, thus overwriting its results.
```
Foam::blockEdges::arcEdge::arcEdge
(
const pointField& points,
const label start,
const label end,
const point& pMid
)
:
blockEdge(points, start, end),
p1_(points_[start_]),
p2_(pMid),
p3_(points_[end_]),
cs_(calcAngle())
{}
```
The easy fix is to switch the declaration of the members in the.H file.
The more sane fix probably is to not alter any member variables before initialization is done.Version v1706https://develop.openfoam.com/Development/openfoam/-/issues/898Adjust derived fields for incompressible2018-07-02T09:33:34ZMark OLESENAdjust derived fields for incompressibleAs tagged on EP645 by @SonVo and discussed with @Prashant - could/should have a `rhoRef` for derived fields in the surfMesh sampler so that `pTotal` and `rhoU` have more physical meanings.As tagged on EP645 by @SonVo and discussed with @Prashant - could/should have a `rhoRef` for derived fields in the surfMesh sampler so that `pTotal` and `rhoU` have more physical meanings.v1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/143heatTransfer/chtMultiRegionFoam/externalSolarLoad/2019-09-20T13:24:55ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comheatTransfer/chtMultiRegionFoam/externalSolarLoad/Has writeInterval 800 but runs for 18000 iterations so last dump is 17600.
Has writeInterval 800 but runs for 18000 iterations so last dump is 17600.
https://develop.openfoam.com/Development/openfoam/-/issues/241Adjust infrastructure to add foamToEnsight capability as function-object2016-11-15T06:09:52ZMark OLESENAdjust infrastructure to add foamToEnsight capability as function-objectCross-reference with http://exchange.openfoam.com/node/263Cross-reference with http://exchange.openfoam.com/node/263Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1294proxyMesh : cellSet update2019-05-20T12:44:37ZPrashant SonakarproxyMesh : cellSet update### Functionality to add/problem to solve
For movingCone (pimpleFoam) case, with cellSet defined over a fixed coordinate limits. [controlDict](/uploads/bef20a3ea2a894116a346b86d028db69/controlDict)
The foamToVTK doesn't seem to detect ...### Functionality to add/problem to solve
For movingCone (pimpleFoam) case, with cellSet defined over a fixed coordinate limits. [controlDict](/uploads/bef20a3ea2a894116a346b86d028db69/controlDict)
The foamToVTK doesn't seem to detect the change in sets.
### Proposal
probably change in size of set to be detected
### What does success look like, and how can we measure that?
movingCone case with above replacement dictionary and foamToVTK
@mark @MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1165snappyHexMesh Warning2020-01-08T14:46:44ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh Warning```
--> FOAM Warning :
From function void Foam::HashTable<T, Key, Hash>::resize(Foam::label) [with T = int; Key = int; Hash = Foam::Hash<int>; Foam::label = int]
in file HashTable.C at line 570
HashTable contains 395 cannot ...```
--> FOAM Warning :
From function void Foam::HashTable<T, Key, Hash>::resize(Foam::label) [with T = int; Key = int; Hash = Foam::Hash<int>; Foam::label = int]
in file HashTable.C at line 570
HashTable contains 395 cannot resize(0)
```Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/127BUG: runTimePostProcessing doesn't respect -case argument2016-06-14T07:51:19ZPrashant SonakarBUG: runTimePostProcessing doesn't respect -case argumentThe output is created in ./postProcessing/...
than $FOAM_CASE/postProcessing/...The output is created in ./postProcessing/...
than $FOAM_CASE/postProcessing/...AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1227ENH: Inform users that the functionObject in question is disabled when it thr...2020-01-03T14:48:25ZKutalmış BerçinENH: Inform users that the functionObject in question is disabled when it throws FatalErrorInFunction-type warnings### Functionality to add/problem to solve
I initialised a variable in the constructor of a (developing) functionObject via a function call which involves a check with `FatalErrorInFunction`:
```
bool Foam::functionObjects::myFunctionOb...### Functionality to add/problem to solve
I initialised a variable in the constructor of a (developing) functionObject via a function call which involves a check with `FatalErrorInFunction`:
```
bool Foam::functionObjects::myFunctionObject::isTemporalVariant
(
const bool runTimeModifiable
) const
{
if (runTimeModifiable)
{
FatalErrorInFunction
<< "Available only for fixed time-step computations."
<< exit(FatalError);
}
return false;
}
```
```
//... Member initialiser list in the constructor
isTemporalVariant_(isTemporalVariant(runTime.runTimeModifiable())),
//...
```
`FatalErrorInFunction` is called when the user sets `controlDict\runTimeModifiable true`.
`FatalErrorInFunction` throws `FOAM Warning` instead of `FOAM FATAL ERROR`.
```
-> FOAM Warning :
Available only for fixed time-step computations.
From function bool Foam::functionObjects::myFunctionObject::isTemporalVariant(bool) const
in file streamingTotalDMD.C at line 53.
From function bool Foam::functionObjectList::read()
in file db/functionObjects/functionObjectList/functionObjectList.C at line 896
--> while loading function object 'myFunctionObject1'
```
Yet, IMHO, the user was not informed that the functionObject is disabled, and the computation is let to run.
### Target audience
Users of functionObjects.
### Proposal
Append information stating that the relevant functionObject is disabled, and the remaining functionObjects and the computation itself are allowed to continue their run.
### What does success look like, and how can we measure that?
N/A
### Links / references
N/A
### Funding
N/Ahttps://develop.openfoam.com/Development/openfoam/-/issues/258paraview plugin not being built in merged version2016-10-24T21:17:05ZMark OLESENparaview plugin not being built in merged versionchange in logic with config changechange in logic with config changeMark OLESENMark OLESEN2016-10-04https://develop.openfoam.com/Development/openfoam/-/issues/774snappyMultiRegionHeater crashing2018-03-19T10:59:23ZMark OLESENsnappyMultiRegionHeater crashing- snappy crashes with gcc 4.8.5, runs with clang 3.8.0- snappy crashes with gcc 4.8.5, runs with clang 3.8.0Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/803Overset bugs2018-04-25T09:13:01ZAdminOverset bugsI'm using 68185c76 on Debian GNU/Linux 8 (jessie). I believe I found some problems with the overset mesh implementation.
1. dynamicOversetFvMesh.C:96
Pstream::exchange<labelList, label>(remoteFaceCells, sendCells);
Neither remoteFa...I'm using 68185c76 on Debian GNU/Linux 8 (jessie). I believe I found some problems with the overset mesh implementation.
1. dynamicOversetFvMesh.C:96
Pstream::exchange<labelList, label>(remoteFaceCells, sendCells);
Neither remoteFaceCells nor sendCells are used after this exchange. I can't see its purpose. Results are not affected when I comment it out.
2. Parallelisation problem. The overSimpleFoam tutorial (aerofoil) converges in serial, but fails to converge in parallel. May be related to above. Mind you, this may be a red herring, because I get this warning:
--> FOAM Warning :
From function bool Foam::oversetPolyPatch::master() const
in file oversetPolyPatch/oversetPolyPatch.C at line 149
The master overset patch is not the first patch. Generally the first patch should be an overset patch to guarantee consistent operation.
-Davidhttps://develop.openfoam.com/Development/openfoam/-/issues/1287sumDirection function in surfaceFieldValue FO does not write down the values,...2019-12-09T22:37:29ZMatej FormansumDirection function in surfaceFieldValue FO does not write down the values, just zeros**sunDirection** function used on **faceZone** on orthogonalMesh samples **phi** in surfaceFieldValue FO.
FaceZone is set of internal faces.
It writes the field (vtk) with real flux values in individual cells.
However, into the text f...**sunDirection** function used on **faceZone** on orthogonalMesh samples **phi** in surfaceFieldValue FO.
FaceZone is set of internal faces.
It writes the field (vtk) with real flux values in individual cells.
However, into the text file where it should write the sum, only zeros are entered.
I did alter the direction specification from ortho direction to see if it gets better, but no.
The reported value is still zero.https://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) AdminAdmin