Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-08-05T17:56:26Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1238add support for mingw cross-compilation2020-08-05T17:56:26ZMark OLESENadd support for mingw cross-compilationMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/616surfaceFeatureExtract crashes on zero-length edges2020-03-16T20:32:24ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsurfaceFeatureExtract crashes on zero-length edges[bjoern.obj](/uploads/61e9e5663b25d0a97bccd9cd41092430/bjoern.obj)[bjoern.obj](/uploads/61e9e5663b25d0a97bccd9cd41092430/bjoern.obj)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/817use of '%' (modulo) where we just want foldaround2020-01-06T10:13:55ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comuse of '%' (modulo) where we just want foldarounde.g. rotateList in ListOpsTemplates, processorPolyPatch.C
This might be faster with just an 'if' and subtraction/addition.e.g. rotateList in ListOpsTemplates, processorPolyPatch.C
This might be faster with just an 'if' and subtraction/addition.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/857interDyMFoam/RAS/motorBike tutorial fails2020-01-03T13:58:32ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.cominterDyMFoam/RAS/motorBike tutorial fails(branch develop-pre-release)
[log.interFoam](/uploads/3b57a8add908b399ebf6add29ab0125d/log.interFoam)(branch develop-pre-release)
[log.interFoam](/uploads/3b57a8add908b399ebf6add29ab0125d/log.interFoam)https://develop.openfoam.com/Development/openfoam/-/issues/1118redistributePar error when reducing the number of processors2018-12-12T21:16:10ZAdminredistributePar error when reducing the number of processorsHi,
I'm facing the next issue with `redistributePar`. It fails for me when trying to redistribute from a higher number of processors to a smaller one.
# Steps to reproduce it
For example, modifying the `$FOAM_TUTORIALS/mesh/parallel/c...Hi,
I'm facing the next issue with `redistributePar`. It fails for me when trying to redistribute from a higher number of processors to a smaller one.
# Steps to reproduce it
For example, modifying the `$FOAM_TUTORIALS/mesh/parallel/cavity` tutorial to run the first steps with 5 processors and redistributing to 2 rather than vice versa.
[cavity5To2.zip](/uploads/2f24a867c36cd4cb68dbf1c978b38aac/cavity5To2.zip)
# Error log
```
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v1806 |
| \\ / A nd | Web: www.OpenFOAM.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : v1806
Arch : "LSB;label=32;scalar=64"
Exec : redistributePar -parallel -decomposeParDict system/decomposeParDict-2 -cellDist
Date : Dec 11 2018
Time : 19:12:26
Host : "e06709f01e3c"
PID : 797
I/O : uncollated
Case : /home/ofuser/workingDir/OpenFOAM/ofuser-v1806/run/cavity
nProcs : 2
Hosts :
(
(e06709f01e3c 2)
)
Pstream initialized with:
floatTransfer : 0
nProcsSimpleSum : 0
commsType : nonBlocking
polling iterations : 0
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
--> FOAM Warning :
From function int main(int, char**)
in file redistributePar.C at line 2300
Detected floating point exception trapping (FOAM_SIGFPE). This might give
problems when mapping fields. Switch it off in case of problems.
Creating time directories on all processors
Create time
Create undecomposed database
Using mesh subdirectory "polyMesh"
Setting time to that of master or undecomposed case : 0.5
Checking for mesh in "/home/ofuser/workingDir/OpenFOAM/ofuser-v1806/run/cavity/processor0/constant/polyMesh/faces"
Per processor mesh availability:
2{1}
[1] #0 Foam::error::printStack(Foam::Ostream&)[e06709f01e3c:00797] *** Process received signal ***
[e06709f01e3c:00797] Signal: Aborted (6)
[e06709f01e3c:00797] Signal code: (-6)
[e06709f01e3c:00797] [ 0] /lib64/libc.so.6(+0x35270)[0x7f4a16ea1270]
[e06709f01e3c:00797] [ 1] /lib64/libc.so.6(gsignal+0x37)[0x7f4a16ea11f7]
[e06709f01e3c:00797] [ 2] /lib64/libc.so.6(abort+0x148)[0x7f4a16ea28e8]
[e06709f01e3c:00797] [ 3] /lib64/libc.so.6(+0x74f47)[0x7f4a16ee0f47]
[e06709f01e3c:00797] [ 4] /lib64/libc.so.6(+0x7ab54)[0x7f4a16ee6b54]
[e06709f01e3c:00797] [ 5] /opt/OpenFOAM/OpenFOAM-v1806/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam4ListIcE7setSizeEi+0x1f5)[0x7f4a1805c155]
[e06709f01e3c:00797] [ 6] /opt/OpenFOAM/OpenFOAM-v1806/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam9UOPstream5writeEi+0xb0)[0x7f4a18069810]
[e06709f01e3c:00797] [ 7] /opt/OpenFOAM/OpenFOAM-v1806/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4FoamlsERNS_7OstreamEi+0xa)[0x7f4a17fd1a1a]
[e06709f01e3c:00797] [ 8] redistributePar(_ZNK4Foam5UListIiE9writeListERNS_7OstreamEi+0xc8)[0x44ca78]
[e06709f01e3c:00797] [ 9] /opt/OpenFOAM/OpenFOAM-v1806/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam18processorPolyPatch14initUpdateMeshERNS_14PstreamBuffersE+0x292)[0x7f4a18202e22]
[e06709f01e3c:00797] [10] /opt/OpenFOAM/OpenFOAM-v1806/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam16polyBoundaryMesh10updateMeshEv+0x275)[0x7f4a1820b635]
[e06709f01e3c:00797] [11] /opt/OpenFOAM/OpenFOAM-v1806/platforms/linux64GccDPInt32Opt/lib/libOpenFOAM.so(_ZN4Foam8polyMeshC1ERKNS_8IOobjectE+0xbf6)[0x7f4a1825b346]
[e06709f01e3c:00797] [12] /opt/OpenFOAM/OpenFOAM-v1806/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so(_ZN4Foam6fvMeshC2ERKNS_8IOobjectE+0x19)[0x7f4a1b4da8b9]
[e06709f01e3c:00797] [13] redistributePar[0x465014]
[e06709f01e3c:00797] [14] redistributePar[0x44838f]
[e06709f01e3c:00797] [15] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f4a16e8dc05]
[e06709f01e3c:00797] [16] redistributePar[0x44b410]
[e06709f01e3c:00797] *** End of error message ***
at ??:?
[1] #1 Foam::sigSegv::sigHandler(int)--------------------------------------------------------------------------
mpirun noticed that process rank 0 with PID 797 on node e06709f01e3c exited on signal 6 (Aborted).
--------------------------------------------------------------------------
```Prashant SonakarPrashant Sonakarhttps://develop.openfoam.com/Development/openfoam/-/issues/981ENH: support -time for blockMesh2019-06-28T09:49:27ZPrashant SonakarENH: support -time for blockMeshcorss reference and code at EP#765corss reference and code at EP#765Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/846BUG: redistributePar hangs with develop-pre-release2018-07-04T10:46:52ZPrashant SonakarBUG: redistributePar hangs with develop-pre-releasesteps to reproduce:
Case - motorbike
after snappyHexMesh is completed, try redistributing mesh using 6 CPUs
works in develop.
@mark @Mattijssteps to reproduce:
Case - motorbike
after snappyHexMesh is completed, try redistributing mesh using 6 CPUs
works in develop.
@mark @MattijsMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://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/574Curle's analogy2019-12-09T22:11:26ZAdminCurle's analogyI believe there is a mistake in the implemented acoustic analogy in OF-1706. The coefficient on the RHS should be 1/(4*pi) instead of 4*pi.
Probably change:
pDash = 4*mathematical::pi/c0_ * (d/magSqr(d) & dfdt);
to pDash = 1/4/mathemati...I believe there is a mistake in the implemented acoustic analogy in OF-1706. The coefficient on the RHS should be 1/(4*pi) instead of 4*pi.
Probably change:
pDash = 4*mathematical::pi/c0_ * (d/magSqr(d) & dfdt);
to pDash = 1/4/mathematical::pi/c0_ * (d/magSqr(d) & dfdt);https://develop.openfoam.com/Development/openfoam/-/issues/811annularThermalMixer tutorial does not run2018-04-27T06:18:15ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comannularThermalMixer tutorial does not runshm does not set the cellZones -> both rotor and stator side rotate.shm does not set the cellZones -> both rotor and stator side rotate.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/662Problem: extrudeMesh always overwrites2017-12-15T09:09:54ZAdminProblem: extrudeMesh always overwritesDear Foamers,
I observed that using
`extrudeMesh`
always overwrites the mesh and writes the new mesh to the 'constant/polyMesh' directory.
Shouldn't is be more consistent if the default setting would be like the one for snappy, that a ...Dear Foamers,
I observed that using
`extrudeMesh`
always overwrites the mesh and writes the new mesh to the 'constant/polyMesh' directory.
Shouldn't is be more consistent if the default setting would be like the one for snappy, that a new time directory is created for the extruded mesh. This would also require the option '-overwrite'.
Foam-version: 1706.
Regards,
Daghttps://develop.openfoam.com/Development/openfoam/-/issues/963blockMesh removes files even on failure2018-08-08T12:12:55ZMark OLESENblockMesh removes files even on failureSpecify something like `blockMesh -dict badName` and the existing polyMesh/ directory will be removed, even if the dictionary could not read and the operation is aborted.
Better to load dictionary (and possibly generate blocks) before r...Specify something like `blockMesh -dict badName` and the existing polyMesh/ directory will be removed, even if the dictionary could not read and the operation is aborted.
Better to load dictionary (and possibly generate blocks) before removing existing files.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/317BUG : foamToEnsight -faceZones sometimes fails in the develop branch2018-05-29T05:39:49ZAdminBUG : foamToEnsight -faceZones sometimes fails in the develop branchfoamToEnsight -faceZones '(".*")' sometimes fails in the most recent commit (7582334f). The attached case worked in commit 57a1e6d2, but fails in 7582334f. This failure only occurs in parallel and only occurs when using the -faceZones fl...foamToEnsight -faceZones '(".*")' sometimes fails in the most recent commit (7582334f). The attached case worked in commit 57a1e6d2, but fails in 7582334f. This failure only occurs in parallel and only occurs when using the -faceZones flag.
The error I receive appears to be an infinite loop of...
```
[adpn029:214314] *** Process received signal ***
[adpn029:214314] Signal: Segmentation fault (11)
[adpn029:214314] Signal code: (2102221680)
[adpn029:214314] Failing at address: (nil)
[adpn029:214314] [ 0] /lib64/libc.so.6[0x3d83c326a0]
[adpn029:214314] [ 1] /apps/OpenFOAM/.builds/OFPlus/dev/OpenFOAM-plus/platforms/linux64Gcc61DPInt32Opt/lib/libconversion.so(_ZNK4Foam11ensightMesh5writeERNS_14ensightGeoFileE+0xb4e)[0x7fc64ebc91fe]
[adpn029:214314] [ 2] foamToEnsight[0x4ecb4a]
[adpn029:214314] [ 3] /lib64/libc.so.6[0x3d83c326a0]
[adpn029:214317] [ 1] /apps/OpenFOAM/.builds/OFPlus/dev/OpenFOAM-plus/platforms/linux64Gcc61DPInt32Opt/lib/libconversion.so(_ZNK4Foam11ensightMesh5writeERNS_14ensightGeoFileE+0xb4e)[0x7fc374cae1fe]
[adpn029:214317] [ 2] foamToEnsight[0x4ecb4a]
[adpn029:214317] [ 3] /lib64/libc.so.6(__libc_start_main+0xfd)[0x3d83c1ed5d]
[adpn029:214317] [ 4] foamToEnsight[0x44d19d]
[adpn029:214317] *** End of error message ***
```
[dam_break.tar.gz](/uploads/bbdc6050da02940a8dab6b0ce5e3fdfa/dam_break.tar.gz)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/692add additional information in header of decomposedBlockData2024-01-10T16:23:36ZMark OLESENadd additional information in header of decomposedBlockDataWe already have a `blocks` entry, but it would be quite convenient for downstream users (eg, paraview) if we also could pass along the underlying data-type in an easy to find place.
Eg,
FoamFile
{
version 2.0;
...We already have a `blocks` entry, but it would be quite convenient for downstream users (eg, paraview) if we also could pass along the underlying data-type in an easy to find place.
Eg,
FoamFile
{
version 2.0;
format binary;
class decomposedBlockData;
blocks 4;
object U;
dataClass volVectorField;
}
At the moment it is a bit of a pain to get at this information.
Would it be useful to have this dataClass information present as `IOobject::headerDataClassName()` with it being identical to `IOobject::headerClassName()` when `dataClass` isn't present?Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/452paraFoam inside processor directory always looks for parent2017-06-29T20:38:04ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comparaFoam inside processor directory always looks for parentI've got a processor directory and put a system/ directory in it so it is self-contained. I cannot run paraFoam on it since it looks for ../system/controlDict.
This is a tiny issue since I can just softlink the system to the parent dire...I've got a processor directory and put a system/ directory in it so it is self-contained. I cannot run paraFoam on it since it looks for ../system/controlDict.
This is a tiny issue since I can just softlink the system to the parent directory.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/681Feature: Possibility for the concurrent usage of multiple subsetFeatures in s...2020-01-03T11:28:59ZKutalmış BerçinFeature: Possibility for the concurrent usage of multiple subsetFeatures in surfaceFeatureExtractDictConsider the OpenFOAM-v1706 tutorial: `/tutorials/mesh/foamyHexMesh/mixerVessel`
Therein, the feature lines of `shaftRotating.stl` were extracted and subsetted via the following group of entries in `surfaceFeatureExtractDict`:
```
subs...Consider the OpenFOAM-v1706 tutorial: `/tutorials/mesh/foamyHexMesh/mixerVessel`
Therein, the feature lines of `shaftRotating.stl` were extracted and subsetted via the following group of entries in `surfaceFeatureExtractDict`:
```
subsetFeatures
{
// Remove the top feature
insideBox (-0.1 -0.1 -0.1)(0.1 0.1 0.1);
}
```
Say, the user required not to remove (or remove) some other features in the same .stl file. To this end, IMHO, the user likely adds another `subsetFeatures` entry by intuition. Let add another box into the tutorial's entry, so that it can readily be reproduced:
```
subsetFeatures
{
// Remove all other features apart from the top and bottom features
insideBox (-0.1 -0.1 -0.1)(0.1 0.1 0.1);
insideBox (-0.1 -0.1 0.8)(0.1 0.1 1);
}
```
Yet the execution of `surfaceFeatureExtract` yields the consideration of **only** the latter box. The output stream is:
```
...
Subset edges inside box (-0.1 -0.1 0.8) (0.1 0.1 1)
...
```
In addition, the simultaneous usage of different entries seems also not possible. For example, when the user enters `insideBox` and `outsideBox` entries under the same `subsetFeatures`, the `insideBox` seems overriding the `outsideBox` entry irrespective of the order of entry sequence.
I found a workaround to subset features from several regions on the same surface mesh, yet this requires sequential command executions. For instance, if one wants to remove/add features from two different locations on the same surface mesh, the person can extract the first region through `surfaceFeatureExtract` with a single `subsetFeature`. Then, the resulted '.eMesh' files can be used to extract features in the second region through another `surfaceFeatureExtract`, however, this time using `extractionMethod extractFromFile;` with another `subsetFeature`, and so on.
IMHO, from a user perspective, a simultaneous surface feature extraction, which may need to consider multiple region restrictions for some reason, might be facilitative.
Kind regardshttps://develop.openfoam.com/Development/openfoam/-/issues/847value_type missing from UIndirectList iterators2018-05-30T09:50:18ZMark OLESENvalue_type missing from UIndirectList iterators- compilation using std::max_element fails on Darwin- compilation using std::max_element fails on DarwinMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1223potentialFoam with -region option2020-01-08T14:37:03ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.compotentialFoam with -region option### Functionality to add/problem to solve
(Brief scope)
Option to run potentialFoam with -region
### Target audience
(Who will benefit from the changes?)
(What type of cases?)
### Proposal
(How are we going to solve the problem?)...### Functionality to add/problem to solve
(Brief scope)
Option to run potentialFoam with -region
### Target audience
(Who will benefit from the changes?)
(What type of cases?)
### Proposal
(How are we going to solve the problem?)
Add handling of region name as command line argument. Feed through the -dry-run mesh handling.
### What does success look like, and how can we measure that?
(What are the success factors and acceptance criteria? e.g. test cases, error margins)
### Links / references
(Links to literature, supporting information)
### Funding
(Does the functionality already exist/is sponsorship available?)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/878basicThermo checks out 'p' upon destruction2021-07-06T13:00:52ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.combasicThermo checks out 'p' upon destructionSee commit 25c741880e. Is there another way?See commit 25c741880e. Is there another way?https://develop.openfoam.com/Development/openfoam/-/issues/459BUG: forceCoeff not working in sonicFoam -> nacaAirfoil2017-05-02T08:54:30ZPrashant SonakarBUG: forceCoeff not working in sonicFoam -> nacaAirfoilcarried forward from https://develop.openfoam.com/Community/OpenFOAM-addOns/issues/4carried forward from https://develop.openfoam.com/Community/OpenFOAM-addOns/issues/4