Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-08-19T21:13:18Zhttps://develop.openfoam.com/Development/openfoam/-/issues/3Reposition fvMotionSolver in Allwmake2023-08-19T21:13:18ZPrashant SonakarReposition fvMotionSolver in AllwmakePlaceholder for resolution of mesh compilation, depending on fvMotionSolver
wmake $targetType fvMotionSolverPlaceholder for resolution of mesh compilation, depending on fvMotionSolver
wmake $targetType fvMotionSolverMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2414report number of cells/faces capped by limitVelocity2022-04-25T11:49:45ZMark OLESENreport number of cells/faces capped by limitVelocitycf. EP1841
Also report relative (%) of cells/faces affected.cf. EP1841
Also report relative (%) of cells/faces affected.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/3096replace listCombineReduce with allGatherList etc.2024-03-12T07:46:11ZMark OLESENreplace listCombineReduce with allGatherList etc.In places such as CloudIO.C, patchInjectionBase.C, turbulentDFSEMInletFvPatchVectorField.C (probably more), there is use of listCombineReduce to collect values from each processor into a list. This particular usage is directly equivalent...In places such as CloudIO.C, patchInjectionBase.C, turbulentDFSEMInletFvPatchVectorField.C (probably more), there is use of listCombineReduce to collect values from each processor into a list. This particular usage is directly equivalent to using allGatherList, which also corresponds to an MPI intrinsic for primitive types.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1871replace autoPtr/tmp combination with refPtr2021-12-03T16:44:51ZMark OLESENreplace autoPtr/tmp combination with refPtrSome of the optimization code uses a combination of autoPtr and tmp to manage the referenced or local turbulence fields. This is ugly but works and was previously the only way to handle these variants.
In the meantime have a `refPtr` (f...Some of the optimization code uses a combination of autoPtr and tmp to manage the referenced or local turbulence fields. This is ugly but works and was previously the only way to handle these variants.
In the meantime have a `refPtr` (formerly called tmpNrc) which can wrap a reference or handle pointer management. Both `tmp` and `refPtr` now have three types of storage:
- PTR : Managing a pointer (not ref-counted)
- CREF : Using (const) reference to an object
- REF : Using (non-const) reference to an object
Can thus have storage with deletion, reference an external object, or a nullptr.
Using a `refPtr` instead of a `tmp` means that we shouldn't accidentally clear memory. Also no reference counting to get in the way.Vaggelis PapoutsisVaggelis Papoutsishttps://develop.openfoam.com/Development/openfoam/-/issues/344renumberMesh twice in the same workflow2018-05-29T05:39:49ZvilfayeaurenumberMesh twice in the same workflowHi,
In some situation, you have to run renumberMesh twice in the same workflow. For example, if you run a coarse case, map to a fine mesh and run it.
This leads to a error message:
Reading volScalarField cellID
[3]
[3]
[3] --> FOAM ...Hi,
In some situation, you have to run renumberMesh twice in the same workflow. For example, if you run a coarse case, map to a fine mesh and run it.
This leads to a error message:
Reading volScalarField cellID
[3]
[3]
[3] --> FOAM FATAL IO ERROR:
[3] size 58624 is not equal to the given value of 58185
[3]
[3] file: /home/a45bwpq/OpenFOAM/1606+/a45bwpq-16.06plus/tutorials/incompressible/simpleFoam/motorBike/processor3/constant/cellID from line 18 to line 58953.
[3]
[3] From function Foam::Field<Type>::Field(const Foam::word&, const Foam::dictionary&, Foam::label) [with Type = double; Foam::label = int]
[3] in file /appl/openfoam/16.06plus/OpenFOAM-16.06plus/src/OpenFOAM/lnInclude/Field.C at line 295.
[3]
FOAM parallel run exiting
motorBike test case is attached to reproduce the error.
Best,
Sebastien
[motorBike.tgz](/uploads/67b76ae6ecde6bb5fb8a3fa1179fdc9d/motorBike.tgz)https://develop.openfoam.com/Development/openfoam/-/issues/351renumberMesh no longer cleans up old ProcAdressing files in develop2018-05-29T05:39:48ZAdminrenumberMesh no longer cleans up old ProcAdressing files in developI'm unsure if this was intentional or by mistake, but renumberMesh no longer cleans up old ProcAdressing files. Any mesh changes done in parallel now require the manual cleanup of the ProcAdressing files, this functionality used to be pr...I'm unsure if this was intentional or by mistake, but renumberMesh no longer cleans up old ProcAdressing files. Any mesh changes done in parallel now require the manual cleanup of the ProcAdressing files, this functionality used to be provided by renumberMesh.
I've attached a pipe model with some faceZones that creates a porous jump using createBaffles in parallel and then runs renumberMesh and reconstruct. This no longer works due to out of date ProcAdressing files.
[tube_test_pj.tar.gz](/uploads/4cbaf933a3d1afc19178da2a92e74d55/tube_test_pj.tar.gz)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/221renumberMesh doesn't work2016-08-26T05:29:46ZAdminrenumberMesh doesn't workI want to solve the DTC-Hull in interFoam solver with another ship. all the commands in allrun file work properly except "renumberMesh" with the following error.![Screenshot_from_2016-08-25_03-17-23](/uploads/16343e9389fbea7cd23573c74692...I want to solve the DTC-Hull in interFoam solver with another ship. all the commands in allrun file work properly except "renumberMesh" with the following error.![Screenshot_from_2016-08-25_03-17-23](/uploads/16343e9389fbea7cd23573c746927bbc/Screenshot_from_2016-08-25_03-17-23.png)https://develop.openfoam.com/Development/openfoam/-/issues/2043Renumbering mesh results in high non-orthogonality and skewness2021-04-15T08:57:40ZGhost UserRenumbering mesh results in high non-orthogonality and skewnessHello,
When I run the `checkMesh` utility in my case with the attached Grid `mesh.x`, it reports the following values of non-orthogonality and skewness (See the `checkMesh.beforeRenumbering` attached file for details):
**Before running...Hello,
When I run the `checkMesh` utility in my case with the attached Grid `mesh.x`, it reports the following values of non-orthogonality and skewness (See the `checkMesh.beforeRenumbering` attached file for details):
**Before running renumberMesh**:
```
Mesh non-orthogonality Max: 36.0957 average: 9.08335
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 2.03538 OK.
```
But when I run the renumberMesh utility, then checkMesh, I get the following (see `checkMesh.afterRenumbering` attached file):
**After running renumberMesh**:
```
Mesh non-orthogonality Max: 78.4614 average: 9.84955
*Number of severely non-orthogonal (> 70 degrees) faces: 26.
Non-orthogonality check OK.
<<Writing 26 non-orthogonal faces to set nonOrthoFaces
Face pyramids OK.
Max skewness = 3.322 OK.
Coupled point location match (average 0) OK.
Failed 1 mesh checks.
```
As you can see, the **max skewness becomes 3.322**, and the **max non-orthogonality becomes 78.4614**.
I wonder if this is a side-effect of renumbering the cells or is it a bug?
Thank you
**Note**:
to convert the mesh.x to OpenFOAM format, use: `plot3dToFoam -2D 0.01 -noBlank mesh.x`
**Attached files**:
[mesh.x](/uploads/398f669511ad3547d37385db6383b66b/mesh.x)
[checkMesh.beforeRenumbering](/uploads/1e6e09b3c8fbfab13039646c3db28f60/checkMesh.beforeRenumbering)
[checkMesh.afterRenumbering](/uploads/358d8b8b7eb0e0df2df265b343716c1b/checkMesh.afterRenumbering)https://develop.openfoam.com/Development/openfoam/-/issues/1204renaming of residuals to solverInfo2019-02-14T21:54:35ZMark OLESENrenaming of residuals to solverInfo```
--> FOAM Warning :
Unknown function type residuals
```
Could resolve compatibility by adding an addNamed... lookup, but may also need symlink the etc/caseDicts/../numerical/residuals* files```
--> FOAM Warning :
Unknown function type residuals
```
Could resolve compatibility by adding an addNamed... lookup, but may also need symlink the etc/caseDicts/../numerical/residuals* filesAdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/2280remove unused domainName and full hostName2022-02-28T13:26:41ZMark OLESENremove unused domainName and full hostName- neither are used
- probably don't work properly on windows
- POSIX version use deprecated gethostbyname()- neither are used
- probably don't work properly on windows
- POSIX version use deprecated gethostbyname()v2206Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/256remove unneeded lines in list binary output.2017-07-03T07:20:58ZMark OLESENremove unneeded lines in list binary output.Writing an empty list in binary results in unnecessary newlines.Writing an empty list in binary results in unnecessary newlines.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1075remove old code from dynamicRefineFvMesh2018-11-20T14:12:24ZMark OLESENremove old code from dynamicRefineFvMesh@Mattijs@MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/554remove Foam::string::operator() operator2017-10-06T07:53:53ZMark OLESENremove Foam::string::operator() operatorThis is a holdover from foamString and is functionally identical to the substr() method, but is also harder to notice when it is being invoked.
I think that we should finally remove it.
@andy @Mattijs @petebachantThis is a holdover from foamString and is functionally identical to the substr() method, but is also harder to notice when it is being invoked.
I think that we should finally remove it.
@andy @Mattijs @petebachantv1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/998removeFaces removes too many points2020-01-08T14:42:41ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comremoveFaces removes too many pointsSeems to be if from 2x2 block of cells only 3 are selected. It also removes the points still used by the fourth cell.Seems to be if from 2x2 block of cells only 3 are selected. It also removes the points still used by the fourth cell.https://develop.openfoam.com/Development/openfoam/-/issues/523remove deprecated ensight output order2017-07-13T06:34:42ZMark OLESENremove deprecated ensight output orderAdded for transition purposes only in 1612 - to verify that the output was identical with the new output backend.
Remove for 1712.
The deprecated order was `(hex prism pyr tet poly)` whereas the newer order is `(tet pyr prism hex pol...Added for transition purposes only in 1612 - to verify that the output was identical with the new output backend.
Remove for 1712.
The deprecated order was `(hex prism pyr tet poly)` whereas the newer order is `(tet pyr prism hex poly)` (increasing number of points) consistent with foamToEnsightParts
v1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2083remove/deprecate construct list from two iterators2021-07-15T16:54:40ZMark OLESENremove/deprecate construct list from two iteratorsThere are different two-parameter forms when constructing a `List`, notably these:
```
List(const label len, const T& val);
List(const UList<T>& list, const labelUList& indices);
template<class InputIterator>
List(InputIterator begIter...There are different two-parameter forms when constructing a `List`, notably these:
```
List(const label len, const T& val);
List(const UList<T>& list, const labelUList& indices);
template<class InputIterator>
List(InputIterator begIter, InputIterator endIter)
```
This typically causes compilation issues with 64-bit labels, eg,
```
bad: labelList test(5, 0);
good: labelList test(label(5), 0);
good: labelList test(5, Zero);
```
otherwise the two-iterator constructor masks everything.
In the past, this has prompted both the removal (c43b78e8de830a327409a0449400e6decc9488f4) and the reinstatement (d01eb45cfc5936d337bafd93d7ed1370d26586b9) of this constructor, even if the problem was never resolved.
Although we generally deal with the problem by properly casting the arguments, still cannot unmask the mapping constructor.
For example,
```
labelList allValues = ...;
labelList indices = ...;
labelList myValues(allValues, indices); -> Error bad iterator pair!!
```
Although this mapping lookup works with Field and most other types of List, it will not work for a `labelList`.
This leads to this type of code:
```
callFunction(labelList(UIndirectList<label>(allValues, indices)));
```
vs
```
callFunction(labelList(allValues, indices));
```
Propose once again removing the construct from iterator pair and/or replace with a tagged version. For example,
```
template<class InputIterator>
List(std::piecewise_construct, InputIterator begIter, InputIterator endIter)
```
Open to suggestions for better dispatch tags.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/536remove ccm26ToFoam2017-11-30T13:37:05ZMark OLESENremove ccm26ToFoamThis single-purpose application has less functionality than ccmToFoam.This single-purpose application has less functionality than ccmToFoam.v1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2373remove additional template on CompactListList2022-03-14T16:18:23ZMark OLESENremove additional template on CompactListListThe `Container` template parameter is only being used from construction from different sublist types (eg, face instead of labelList) and deserializing (with the `operator()`).
Both would be better served with a pack factory method and a...The `Container` template parameter is only being used from construction from different sublist types (eg, face instead of labelList) and deserializing (with the `operator()`).
Both would be better served with a pack factory method and an unpack() method, which would also allow unpacking into different container types from the same compact content.
Partial motivation is reuse for a CSRList type etc.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/299Reminder: Please don't forget to test building v1612+ with the following scen...2017-01-02T12:29:19ZAdminReminder: Please don't forget to test building v1612+ with the following scenariosI don't know who is responsible for packaging the OpenFOAM+ releases, but this issue is a reminder of what happened with v1606+ and which can be avoided with v1612+:
1. There were a few problems when building with 64-bit labels, which...I don't know who is responsible for packaging the OpenFOAM+ releases, but this issue is a reminder of what happened with v1606+ and which can be avoided with v1612+:
1. There were a few problems when building with 64-bit labels, which were only fixed in the `master` branch after the release. Therefore, please also test building with 64-bit labels.
2. Even though it's rare, having on the building test loop the option to build with SP (Single Precision) would also be welcome, to also avoid support issues later on. If it at least builds, that's a good step forward.
3. There were a couple of other problems that would only appear when building with the "OpenFOAM-v1606+" and "ThirdParty-v1606+" folder paths and not with "OpenFOAM-plus"... unfortunately at the moment I can't remember what they were. Therefore, please also run build tests with the release folder, not just the repository folder, before releasing.https://develop.openfoam.com/Development/openfoam/-/issues/2801Reimplementation of dlOpen for macOS to avoid SIP problems2023-07-25T18:28:07ZAlexey MatveichevReimplementation of dlOpen for macOS to avoid SIP problems### Functionality to add/problem to solve
SIP (System Integrity Protection) on macOS clears environment variables, which affect behaviour of dynamic linker (`DYLD_LIBRARY_PATH`). OpenFOAM keeps backup of this variable in `FOAM_LD_LIBRAR...### Functionality to add/problem to solve
SIP (System Integrity Protection) on macOS clears environment variables, which affect behaviour of dynamic linker (`DYLD_LIBRARY_PATH`). OpenFOAM keeps backup of this variable in `FOAM_LD_LIBRARY_PATH` and currently it restores `DYLD_LIBRARY_PATH` in `RunFunctions` file. This solution is not quite complete, as it (a) requires sourcing of `RunFunctions` file, (b) additional errors appear depending on a user workflow (ex. #2793, #2555).
The patch solves the problem by iterating through paths stored in backup variable, while loading dynamic library.
### Target audience
OpenFOAM users on macOS with SIP enabled.
### Proposal
Try to emulate `dlopen` behaviour: iterate over paths stored in `FOAM_LD_LIBRARY_PATH`, for each of the paths construct full path to the library, try to load a library using full path.
### What does success look like, and how can we measure that?
1. There is no need to restore `DYLD_LIBRARY_PATH` in `RunFunctions`.
2. User with SIP enabled can load additional libraries in case files and solver finds them independently of the way the case is executed (from command line, from a script using `runApplication` function, from a script using `foamJob` script, etc.)
### Funding
Patch implementing the functionality is attached to the issue.
[01-dlopen-SIP-remediation.patch](/uploads/8c8d00874f6af5c6d57bbcb0ada00113/01-dlopen-SIP-remediation.patch)
### Note
`sprintf` and `vfork` are deprecated on macOS, so I also added changes to remove deprecation warnings during compilation.Mark OLESENMark OLESEN