openfoam issueshttps://develop.openfoam.com/Development/openfoam/-/issues2023-08-19T21:13:19Zhttps://develop.openfoam.com/Development/openfoam/-/issues/12Documentation/BUG: Volume point smoothing2023-08-19T21:13:19ZPrashant SonakarDocumentation/BUG: Volume point smoothingIs it possible to have nSmoothInternal > nSmoothPatch?
Documentation says it can't. But present version can allow this.
Please fix either of these! :)
@andy Is it possible to have nSmoothInternal > nSmoothPatch?
Documentation says it can't. But present version can allow this.
Please fix either of these! :)
@andy Functionality migration from internal development lineMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/23Discussion: FO output : blendingFactor2015-12-15T07:07:16ZPrashant SonakarDiscussion: FO output : blendingFactorIs it OK to have two output statements per iteration?
blendingFactor blendingFactor1 output:
scheme 1 cells : 106634
scheme 2 cells : 0
blended cells : 0
blendingFactor blendingFactor1 output:
writing fi...Is it OK to have two output statements per iteration?
blendingFactor blendingFactor1 output:
scheme 1 cells : 106634
scheme 2 cells : 0
blended cells : 0
blendingFactor blendingFactor1 output:
writing field blendingFactor1:U
/home/alex2/prashant/QA/UNIT_TESTS/FO-tests/compressible/motorBike/log.rhoPimpleFoam.blendingFactor
@Mattijs Functionality migration from internal development lineMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/22Discussion: patchProbes compatibility with fixedLocations2016-11-07T14:27:03ZPrashant SonakarDiscussion: patchProbes compatibility with fixedLocationsStandard probes FO has additional entry
// Optional: do not recalculate cells if mesh moves
fixedLocations false;
Is this also applicable for patchProbes?
@andy Standard probes FO has additional entry
// Optional: do not recalculate cells if mesh moves
fixedLocations false;
Is this also applicable for patchProbes?
@andy Functionality migration from internal development lineMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://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/195Need means of distinguishing between openfoam versions for user-coding2016-12-23T12:44:52ZMark OLESENNeed means of distinguishing between openfoam versions for user-codingWhen migrating user code between versions, there are some changes in OpenFOAM that may require alteration in the user code.
If this code exists in a codeStream, for example, it may not be possible to run the same case with slightly diff...When migrating user code between versions, there are some changes in OpenFOAM that may require alteration in the user code.
If this code exists in a codeStream, for example, it may not be possible to run the same case with slightly different OpenFOAM versions.
It is proposed to supply a pre-processor define to reflect the current base-level compatibility. This type of define could also be used to distinguish between OpenFOAM+ and other variants. This type of definition would also greatly simplify other third-party applications that may be built for various OpenFOAM versions.
For example,
#ifdef OPENFOAM_PLUS
...
#endif
The `OPENFOAM_PLUS` define would have a numerical value corresponding to the newly introduced version numbers (eg, `1606`) since these provide a simple, consistent, linear numbering without any additional effort.
#ifdef OPENFOAM_PLUS
#if (OPENFOAM_PLUS >= 1612)
...
#endif
#endif
This type of code naturally becomes quite cluttered and thus should only be used when strictly necessary.
It remains at the discretion of the developers to bump the number between release cycles, to indicate a newer functionality. Finer granularity than one month is not intended.
Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/352cleanup noFunctionObjects vs withFunctionObjects etc2018-08-09T10:21:58ZMark OLESENcleanup noFunctionObjects vs withFunctionObjects etcpotentialFoam is the only solver or application to use `-withFunctionObjects`, all others have an implicit `-noFunctionObjects`. This exception does make sense, but opens questions about the general handling of function-objects. There ar...potentialFoam is the only solver or application to use `-withFunctionObjects`, all others have an implicit `-noFunctionObjects`. This exception does make sense, but opens questions about the general handling of function-objects. There are a number of utilities (conversion, blockMesh, etc) without a time-loop and thus it doesn't make much sense to even provide a `-noFunctionObjects` option for them.
Propose adding a argList::noFunctionObjects() method - similar to the argList::noParallel() method - to remove the availability of the `-noFunctionObjects` option and adjust Time accordingly.
Currently:
functionObjects_
(
*this,
argList::validOptions.found("withFunctionObjects")
? args.optionFound("withFunctionObjects")
: !args.optionFound("noFunctionObjects")
)
Proposed:
functionObjects_
(
*this,
argList::validOptions.found("withFunctionObjects")
? args.optionFound("withFunctionObjects")
: argList::validOptions.found("noFunctionObjects")
? !args.optionFound("noFunctionObjects")
: false
)
For potentialFoam it also doesn't make sense to provide the `-noFunctionObjects` option at all. It adds clutter and will always be ignored anyhow.
@andy @Mattijs @PrashantVersion v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/595simplify/extend List, DynamicList2021-01-26T20:22:11ZMark OLESENsimplify/extend List, DynamicListInspired by some of Franjo's @Juretic work, I've started looking into how to incorporate the short list optimization into the standard DynamicList as well as other methods and possible optimizations. I'd like some feedback on some of the...Inspired by some of Franjo's @Juretic work, I've started looking into how to incorporate the short list optimization into the standard DynamicList as well as other methods and possible optimizations. I'd like some feedback on some of these ideas @andy @Mattijs
The static allocation size needs to be templated but the number of parameters for DynamicList is growing too much. My current thought is to remove the SizeInc,SizeMult,SizeDiv from templates and replace with a run-time sizing policy that we can combine with templated factory methods for some compile-time safety.
Eg,
template<class T, unsigned StaticSize = 16>
class DynamicList
{
...
//-
inline void setSizingPolicy(const sizingPolicy& policy);
};
In use this would mean something like this:
DynamicList<label> lst;
lst.setSizingPolicy(sizingPolicy::increment<10>());
lst.setSizingPolicy(sizingPolicy::factor<2>());
lst.setSizingPolicy(sizingPolicy::factor<3,2>());
lst.setSizingPolicy(sizingPolicy::general<10,3,2>());
This is still a long way from handling allocations with an allocator, but I think it is an improvement.
To accommodate some other routines, I've tentatively added in these methods:
UList
//- Find index of the first occurence of the value.
// Linear search.
// \return -1 if not found.
label find(const T& val, const label start=0) const;
//- True if the value if found in the list. Linear search.
inline bool found(const T& val, const label start=0) const;
//- Move element to the first position.
void moveFirst(const label i);
//- Move element to the last position.
void moveLast(const label i);
//- Swap with the first element. Fatal on an empty list.
void swapFirst(const label i);
//- Swap with the last element. Fatal on an empty list.
void swapLast(const label i);
DynamicList
//- Remove and return the last element. Fatal on an empty list.
inline T remove();
//- Remove and return the specified element. Fatal on an empty list.
// With fast=true (default), the removed element is replaced with
// the last one in the list.
// With fast=false, the elements are copied down in the list.
inline T remove(const label i, const bool fast=true);v1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/429Support dictionary scoping as lvalue2017-12-18T23:19:00ZMark OLESENSupport dictionary scoping as lvalueCurrently can use `${:subdict.name}` as rvalue substitution - using the `:` to denote an absolute location, but it is not possible to use this type of notation as a lvalue. For example `:subdict.name` as a name, since `:` is a punctuatio...Currently can use `${:subdict.name}` as rvalue substitution - using the `:` to denote an absolute location, but it is not possible to use this type of notation as a lvalue. For example `:subdict.name` as a name, since `:` is a punctuation token. It might be possible to add additional quoting etc, but could also make sense just to allow another character for denoting an absolute location. I would propose allowing `^` as an absolute position anchor. This is a one-line change in dictionary::lookupScopedEntryPtr()
if (keyword[0] == ':' || keyword[0] == '^')
Once this is in place, I could rework the `removeEntry` function entry to handle scoped names and eliminate the current restriction:
> The removal only occurs in the current context.
> Removing sub-entries or parent entries is not supported.
@andy @Mattijsv1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/860foamLog extract min, max, avg2021-07-06T12:57:16ZMark OLESENfoamLog extract min, max, avg- can currently only extract min value (EP 690), and foamLog is not sophisticated enough to handle arbitrary parsing.
- adjust AMI reporting as `min = ... max = ...` instead of `min/max/average = ...` for easier parsing.
@Prashant- can currently only extract min value (EP 690), and foamLog is not sophisticated enough to handle arbitrary parsing.
- adjust AMI reporting as `min = ... max = ...` instead of `min/max/average = ...` for easier parsing.
@Prashantv1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/893Need stderr or equivalent alternative to Info2020-05-23T11:04:36ZMark OLESENNeed stderr or equivalent alternative to InfoIn some situations informative output gets in the way of desired output (eg, foamDictionary output - EP702).
We can avoid some of this output with `argList::noBanner()`. In the .org version they have replace this with a dedicated InfoHe...In some situations informative output gets in the way of desired output (eg, foamDictionary output - EP702).
We can avoid some of this output with `argList::noBanner()`. In the .org version they have replace this with a dedicated InfoHeader message stream, which handles the same problem. However, we may also to have a more general solution (cf. #881).
In similar cases it could also be helpful to have a Serr that only outputs on the master.
With dynamic code generation (eg `#calc`) the process generated copious quantities of output, all of which land on stdout.
Perhaps we need a version of `system()` with a `dup2()` to redirect.
@Mattijsv1812Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1073change internal dictionary separator2024-01-10T19:58:42ZMark OLESENchange internal dictionary separatorPropose for **1906**, we could adjust the internal dictionary separator from a dot (.) to a comma (,) separator.
The change in output appearance would be minimal. Eg,
```
/path/dictionary/subdict1,subdict2,entry
```
But by using a comma,...Propose for **1906**, we could adjust the internal dictionary separator from a dot (.) to a comma (,) separator.
The change in output appearance would be minimal. Eg,
```
/path/dictionary/subdict1,subdict2,entry
```
But by using a comma, which is rarely if ever used within a keyword, we could have things like this
```
file.obj
{
type xxx;
}
```
And now be able to recover the keyword `file.obj` from the dictionary dictName() method. At the moment the dictName() parses based on dot and would return `obj` instead.
@Developmentv1906Mark OLESENMark OLESEN2019-02-01https://develop.openfoam.com/Development/openfoam/-/issues/1129paraFoam displays 'internalMesh' after any patch groups in the 'Mesh Parts' s...2020-03-13T14:35:45ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comparaFoam displays 'internalMesh' after any patch groups in the 'Mesh Parts' selectioninternalMesh used to be first. Is this wanted?internalMesh used to be first. Is this wanted?v1906Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1917adjust Sine Function12020-12-22T07:59:46ZMark OLESENadjust Sine Function1The `sine` Function1 currently takes `frequency` as cycles per second, and thus multiplies by 2 PI. For some times cycles (eg, seasonal variations), this is quite unnatural.
- propose supporting `frequency` or `period`, where period is ...The `sine` Function1 currently takes `frequency` as cycles per second, and thus multiplies by 2 PI. For some times cycles (eg, seasonal variations), this is quite unnatural.
- propose supporting `frequency` or `period`, where period is in seconds.
- ~~potentially useful to add an optional phase shift, for cases where a time shift may be less appropriate.~~
- clip min/max limits. Eg ensures we maintain min levels
@orgogozov2012Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2276extend dictionary directives2021-11-26T12:27:23ZMark OLESENextend dictionary directivesOn [an issue raised on cfd-online](https://www.cfd-online.com/Forums/openfoam-programming-development/239595-possible-use-info-inside-calc-print-string.html), the user was attempting to use `#calc` to report dictionary values. For exampl...On [an issue raised on cfd-online](https://www.cfd-online.com/Forums/openfoam-programming-development/239595-possible-use-info-inside-calc-print-string.html), the user was attempting to use `#calc` to report dictionary values. For example,
```
myVariable 42;
#calc "Info << $myVariable << endl";
```
which supposed works somehow, but I cannot figure out how.
In a somewhat similar vein (in EP1742), they were misusing `#calc` to perform string concatenation. For example,
```
_foName #calc #{ "some_prefix_solverInfo_${application}" #};
$_foName
{
type solverInfo;
libs (utilityFunctionObjects);
fields (".*");
}
#remove _foName;
```
As both cases illustrate, there must be a better way to solve this.v2112Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1471Potentially redundant set of computations for G object within eddy-viscosity ...2022-04-26T16:10:39ZKutalmış BerçinPotentially redundant set of computations for G object within eddy-viscosity turbulence modelsSome of the eddy-viscosity-based turbulence models compute G (the turbulent kinetic energy production rate due to the anisotropic part of the stress tensor). For example, in kEpsilon:
```
volScalarField::Internal G
(
thi...Some of the eddy-viscosity-based turbulence models compute G (the turbulent kinetic energy production rate due to the anisotropic part of the stress tensor). For example, in kEpsilon:
```
volScalarField::Internal G
(
this->GName(),
nut.v()*(dev(twoSymm(tgradU().v())) && tgradU().v())
);
tgradU.clear();
```
Here, we compute a deviatoric-symmetric tensor (`(dev(twoSymm(tgradU().v()))`) with a full tensor `tgradU().v()`.
**Any tensor** can be divided into its symmetric and anti-symmetric parts. And any double-inner product of a symmetric tensor and an anti-symmetric tensor is zero.
Therefore, the above double-inner product can be reduced between two symmetric tensors without losing any level of accuracy in the final outcome.
Such reduction seems to be carried out in the more recently implemented turbulence models, e.g. v2f.
The simpler, cheaper-to-run alternative can be:
```
tmp<volTensorField> tgradU = fvc::grad(U);
const volScalarField::Internal G
(
this->GName(),
nut.v()*2*magSqr(dev(symm(tgradU.cref().v())))
);
tgradU.clear();
```
PS: Asked the question in CFD-Online: [here](https://www.cfd-online.com/Forums/openfoam-solving/229596-potentially-redundant-set-computations-g-object-within-turbulence-models.html).v2206Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2054Question about GAMG solver strategy (only V cycles currently)2023-07-19T16:41:29ZMINHAO XUQuestion about GAMG solver strategy (only V cycles currently)### Functionality to add/problem to solve
I checked the source code of GAMG solver and found that there is only V cycle for multi-grid. From some literature it said that F and W cycly may convergence faster thant normal V cycle. My quest...### Functionality to add/problem to solve
I checked the source code of GAMG solver and found that there is only V cycle for multi-grid. From some literature it said that F and W cycly may convergence faster thant normal V cycle. My question is: why not add F and W cycle as an alternative? What are your worries?
(Brief scope)
### Target audience
GAMG are mainly used in solving matrics of pressure field and as I know it is always hard to convergence and costs much time in the whole solving proccess. So everyone who uses GAMG solver may nenifit from the changes.
(Who will benefit from the changes?)
(What type of cases?)
### Proposal
Add W and F cycle of multi-grid series solver.
(How are we going to solve the problem?)
### What does success look like, and how can we measure that?
add alternative cycles and api to let user choose own cycles.
(What are the success factors and acceptance criteria? e.g. test cases, error margins)
### Links / references
https://en.wikipedia.org/wiki/Multigrid_method
(Links to literature, supporting information)
### Funding
(Does the functionality already exist/is sponsorship available?)https://develop.openfoam.com/Development/openfoam/-/issues/1847REQUEST: snGrad field function object2020-09-21T07:59:30ZChiara PesciREQUEST: snGrad field function object### Functionality to add/problem to solve
It would be nice to have a field function object which computes the surface normal gradient (snGrad) at a boundary patch/patches, with patch name provided as input by the user.
### Proposal
Th...### Functionality to add/problem to solve
It would be nice to have a field function object which computes the surface normal gradient (snGrad) at a boundary patch/patches, with patch name provided as input by the user.
### Proposal
The field FO could look like the div or grad FOs.
Cheers,
ChiaraKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1844REVIEW: laplacianFoam2021-07-07T09:56:34ZKutalmış BerçinREVIEW: laplacianFoamKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/986snappyHexMesh does not extrude (using medialAxis) in thin gaps2020-01-08T14:40:39ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh does not extrude (using medialAxis) in thin gapsThe medialAxis shrinker by default used to disable edges with any point
on an extruded wall to contain the medial axis. Now this is a bit more
intelligent and it only checks the actual medial axis point to be away from
the wall.
```
// R...The medialAxis shrinker by default used to disable edges with any point
on an extruded wall to contain the medial axis. Now this is a bit more
intelligent and it only checks the actual medial axis point to be away from
the wall.
```
// Revert to <=1806 behaviour:
disableWallEdges true;
```
Below is a hacked version of the addLayersToFaceZones tutorials where the 'B' faceZone has been shifted to be one
cell to the right of the 'A' faceZone.
1806 (or with `disableWallEdges false`)
![disableWallEdges_on](/uploads/8807b57094525080c75ec7fcaed97a02/disableWallEdges_on.png)
develop:
![disableWallEdges_off](/uploads/f2f9659340c23c698ce8117e8f836850/disableWallEdges_off.png)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1122snappyHexMesh automatic gap level refinement : 'small feature' phase should i...2020-09-10T14:39:28ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh automatic gap level refinement : 'small feature' phase should ignore min levelThe `Small surface feature refinement iteration` only works if minimum gap level is triggered. So if
- the specified min level is > 0
- and the geometry is inside a single cell
it will not do anything (since the initial cell level is zer...The `Small surface feature refinement iteration` only works if minimum gap level is triggered. So if
- the specified min level is > 0
- and the geometry is inside a single cell
it will not do anything (since the initial cell level is zero and never increases).
If we leave this behaviour the problem is that the behaviour depends on whether the geometry is fully inside a cell or does intersect. Which is illogical.
Or we fix and then ideally have a switch to bypass this behaviour (since it can be very slow on large cases). Maybe supply a 'maxIter' parameter for the snappyRefineDriver::smallFeatureRefine.
Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com