Development issueshttps://develop.openfoam.com/groups/Development/-/issues2018-05-08T07:52:35Zhttps://develop.openfoam.com/Development/openfoam/-/issues/820yna2018-05-08T07:52:35ZAdminynahttps://develop.openfoam.com/Development/openfoam/-/issues/322objectRegistry functionality2018-10-17T15:39:55ZMark OLESENobjectRegistry functionalityWhile attempting to use the subRegistry functionality to add extra information onto the mesh obr, I noticed some odd behaviour.
Delving into the code, it seems to be related to how the lookupObject works. It implicitly includes a upwards...While attempting to use the subRegistry functionality to add extra information onto the mesh obr, I noticed some odd behaviour.
Delving into the code, it seems to be related to how the lookupObject works. It implicitly includes a upwards recursion into the parent registry, only stopping when it hits Time. This means that adding subRegistry2("name=abc") to subRegistry1 will fail if the _parent_ of subRegistry1 already contained an objectRegistry with the name "abc". [Test-objectRegistry.C](/uploads/a900bca5989288cf211d5cefd70cefef/Test-objectRegistry.C)
I think we need to make this recursion an optional parameter (default = true for compatibility) to at least a few methods. It would also be a nice time to add this, for symmetry with dictionary lookupEntryPtr:
//- Lookup and return pointer to the object of the given Type,
// return nullptr if the object was not found or had the incorrect type
template<class Type>
const Type* lookupObjectPtr(const word& name, bool recursive=true) const;
//- Lookup and return the object of the given Type,
// return nullptr if the object was not found or had the incorrect type
template<class Type>
Type* lookupObjectPtr(const word& name, bool recursive=true) const;
Then use like this:
volScalarField* fieldPtr = mesh().lookupObjectPtr<volScalarField>("foo");
if (fieldPtr)
{
volScalarField& fld = *fieldPtr;
...
}
Instead of
if (mesh().foundObject<volScalarField>("foo"))
{
volScalarField& fld = const_cast<volScalarField&>(mesh().lookupObject<volScalarField>("foo"));
...
}
@andyVersion v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/531Feature: Possibility to suppress slaves from output2018-04-19T08:02:53ZPrashant SonakarFeature: Possibility to suppress slaves from outputWhen using large number of CPU e.g 720+, each execution of utility prints slaves.
-should this printing be optional ?When using large number of CPU e.g 720+, each execution of utility prints slaves.
-should this printing be optional ?https://develop.openfoam.com/Development/openfoam/-/issues/246Add sudo to docker container2020-06-18T21:18:13ZAdminAdd sudo to docker containerIn the install script /etc/profile.d is projected into the container. Which is great because that way a non-root access for installing software etc could be set up. Problem is that sudo currently is not installed in the container.
\## ...In the install script /etc/profile.d is projected into the container. Which is great because that way a non-root access for installing software etc could be set up. Problem is that sudo currently is not installed in the container.
\## Reattaching the author to the issue ticket: @bgschaid ##Pawan GhildiyalPawan Ghildiyalhttps://develop.openfoam.com/Development/openfoam/-/issues/823reference functionObject : issue while running in parallel2018-06-08T22:46:03ZAdminreference functionObject : issue while running in parallelWhile running in parallel, `pRef` field is written in `processor0` only.While running in parallel, `pRef` field is written in `processor0` only.AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/830compilation with IntelMPI failed2019-12-09T22:18:11ZPawan Ghildiyalcompilation with IntelMPI failedUsing ThirdParty compiler Gcc64 and pointing to MPI_ROOT path to intelMPI
complain about mpi.h not found during compilation of src/Pstream and src/parallel/decompose/ptscotchDecomp
"sinclude $(GENERAL_RULES)/mplib$(WM_MPLIB)"
"sin...Using ThirdParty compiler Gcc64 and pointing to MPI_ROOT path to intelMPI
complain about mpi.h not found during compilation of src/Pstream and src/parallel/decompose/ptscotchDecomp
"sinclude $(GENERAL_RULES)/mplib$(WM_MPLIB)"
"sinclude $(RULES)/mplib$(WM_MPLIB)"
Solution: **Mark** pointed out following need to be added to fix this issue
"sinclude $(DEFAULT_RULES)/mplib$(WM_MPLIB)"
Regards
PawanMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1234add wmake rules for PGI compiler2019-04-26T08:09:16ZMark OLESENadd wmake rules for PGI compilerMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1044Add lagrangianTools functionality to develop branch2018-11-24T14:58:40ZRoger AlmenarAdd lagrangianTools functionality to develop branchIs it possible to add the functionality available under lagrangianTools to the develop branch, towards release with v1812?Is it possible to add the functionality available under lagrangianTools to the develop branch, towards release with v1812?Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/525ENH: moving average with exact terms in window2018-03-07T14:55:05ZPrashant SonakarENH: moving average with exact terms in windowRefer EP#430Refer EP#430v1712AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/585paraview reader module only handles information from first cloud2017-09-12T13:58:38ZMark OLESENparaview reader module only handles information from first cloud@andy @andy v1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/614runnning with dummy Pstream library does not have pthread dependency2020-04-06T10:37:45ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comrunnning with dummy Pstream library does not have pthread dependencyFor now add it to dummy/Pstream dependency (since libOSspecific is not a shared library)For now add it to dummy/Pstream dependency (since libOSspecific is not a shared library)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/586paraview reader attempts to shallow copy nullptr2017-09-12T13:58:30ZMark OLESENparaview reader attempts to shallow copy nullptrCan occur if the selected geometry does not actually exist, but treat as a non-critical bug since paraview catches this anyhow and just emits a warning message.Can occur if the selected geometry does not actually exist, but treat as a non-critical bug since paraview catches this anyhow and just emits a warning message.v1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/564mismatch in send/receive sizes of int32/int642021-07-06T12:05:23ZMark OLESENmismatch in send/receive sizes of int32/int64I think the root cause for #505 could be how ints are being sent/received.
For example, an int32_t is sent with a LABEL tag and is 4 bytes. But a LABEL is received in UIPstream as a `label` and could be 32 or 64-bits (depending on WM_LAB...I think the root cause for #505 could be how ints are being sent/received.
For example, an int32_t is sent with a LABEL tag and is 4 bytes. But a LABEL is received in UIPstream as a `label` and could be 32 or 64-bits (depending on WM_LABEL_SIZE). It would seem to be the same for int64, but we probably haven't been sending those about too much in that form.
@andy @MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1011odd behaviour in bash completions2018-09-19T19:00:25ZMark OLESENodd behaviour in bash completionsCould be a bash bug or something else. With a local copy of foamToVTK with a `-legacy` option, the completion function triggers a syntax error.
```
foamToVTK -le<TAB>
```
Results in
```
foamToVTK -lebash: [: -n: integer expression expec...Could be a bash bug or something else. With a local copy of foamToVTK with a `-legacy` option, the completion function triggers a syntax error.
```
foamToVTK -le<TAB>
```
Results in
```
foamToVTK -lebash: [: -n: integer expression expected
gacy
```
The offending line is this one in bash_completion:
```
elif [ -n "$cur" -a "${cur#-}" = "${cur}" ]
then
# Already started a (non-empty) word that isn't an option
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/367BUG: fieldAveraging write conflict with timeEnd2019-12-09T21:29:27ZPrashant SonakarBUG: fieldAveraging write conflict with timeEndAttached example illustrating the issue.
- The end time written from solver doesn't contain pMean field
- If we try commenting timeEnd entry from averaging FO, the field is written well.
[pitzDaily_averageFields_pimpleFoam.tgz](/uploa...Attached example illustrating the issue.
- The end time written from solver doesn't contain pMean field
- If we try commenting timeEnd entry from averaging FO, the field is written well.
[pitzDaily_averageFields_pimpleFoam.tgz](/uploads/3448d7e0d4738368f79fac7e05929290/pitzDaily_averageFields_pimpleFoam.tgz)
@mark @MattijsVersion v1706AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/517reduce the size of the environment2020-05-06T07:59:51ZMark OLESENreduce the size of the environmentMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/345dictionary variable expansion broken?2021-07-06T10:55:56ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdictionary variable expansion broken?Trying to do fancy things:
[dynamicMeshDict](/uploads/546b7109c94f93c4ebf1340698f6da81/dynamicMeshDict)
behaves different in v1606+ and plus.develop.Trying to do fancy things:
[dynamicMeshDict](/uploads/546b7109c94f93c4ebf1340698f6da81/dynamicMeshDict)
behaves different in v1606+ and plus.develop.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/427topoSet: nearestToCell, nearestToPoint return nearest on each processor inste...2018-05-03T18:08:12ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comtopoSet: nearestToCell, nearestToPoint return nearest on each processor instead of overall nearestMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/547bad range check for foamHelp (SEGFAULT)2019-12-09T22:11:26ZMark OLESENbad range check for foamHelp (SEGFAULT)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/6Missing documentation: porosity in force/coefficient FO2023-08-19T21:13:19ZPrashant SonakarMissing documentation: porosity in force/coefficient FO@andy @Mattijs
Add details about porosity in Header files in $src/postProcessing/functionObjects/forces@andy @Mattijs
Add details about porosity in Header files in $src/postProcessing/functionObjects/forcesFunctionality migration from internal development lineAdminAdmin