Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-06-14T12:16:13Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2800support MPI_Request cancellation/freeing2023-06-14T12:16:13ZMark OLESENsupport MPI_Request cancellation/freeingeg, when speculative receives have been initiated but are no longer required @Mattijseg, when speculative receives have been initiated but are no longer required @MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1874support multiple faceZones/patches in sampling and surfaceFieldValue2021-02-01T18:50:37ZMark OLESENsupport multiple faceZones/patches in sampling and surfaceFieldValueItems raised in EP1415, EP1416
- should sampling onto faceZones.
Currently does not exist, even although they are supported in surfaceFieldValue.
- no support for multiple patches or faceZones in surfaceFieldValue.
Sampling onto mult...Items raised in EP1415, EP1416
- should sampling onto faceZones.
Currently does not exist, even although they are supported in surfaceFieldValue.
- no support for multiple patches or faceZones in surfaceFieldValue.
Sampling onto multiple patches works, so why not surfaceFieldValue.
@Prashantv2012Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1930Support multiple weights on some field function objects2020-11-30T14:35:30ZMark OLESENSupport multiple weights on some field function objectsRaised on EP1453, but it would also partly cover the derivedFields workaround as well. Support 0-N scalar weight fields and 0-1 vector weight fields (for surface weighting). Multiplicative weighting, with legacy handling of "none" and tr...Raised on EP1453, but it would also partly cover the derivedFields workaround as well. Support 0-N scalar weight fields and 0-1 vector weight fields (for surface weighting). Multiplicative weighting, with legacy handling of "none" and treat "rho" as unity for incompressible cases.
If implemented could have `(rho U)` weighting.v2012Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1510support specified time for transformPoints2019-12-15T21:09:38ZPrashant Sonakarsupport specified time for transformPoints### Functionality to add/problem to solve
transformPoints reads time from points instance. But it might be nice to operate on given time.
### Proposal
As discussed with @mark Use given time or default to constant### Functionality to add/problem to solve
transformPoints reads time from points instance. But it might be nice to operate on given time.
### Proposal
As discussed with @mark Use given time or default to constantMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/928Support user-independent build2020-03-16T14:24:57ZMark OLESENSupport user-independent buildWhen building for cluster installations the user prefs.sh and various config.sh/ files will be used, but this can lead to installations that are no longer properly portable.When building for cluster installations the user prefs.sh and various config.sh/ files will be used, but this can lead to installations that are no longer properly portable.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2999support user specification of timeFormat and precision for ensight output cases2023-10-28T11:06:00ZMark OLESENsupport user specification of timeFormat and precision for ensight output casesCurrently the ensight cases use a hard-coded time format (usually scientific) and precision. When the time-steps are very close to each other, this lose of precision makes the time names indistinguishable at later processing.
Add user-c...Currently the ensight cases use a hard-coded time format (usually scientific) and precision. When the time-steps are very close to each other, this lose of precision makes the time names indistinguishable at later processing.
Add user-configurable specification of time format and precision for ensight volume/surface/sets writers.
cross-ref EP2297Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/144surfaceAdd -mergeRegions2016-11-18T05:58:11ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsurfaceAdd -mergeRegionsThe mergeRegions option does not detect regions with same name. Instead it assumes regions have the same order.The mergeRegions option does not detect regions with same name. Instead it assumes regions have the same order.https://develop.openfoam.com/Development/openfoam/-/issues/347surfaceCheck - no outputThreshold option2017-12-22T15:34:47ZMatej FormansurfaceCheck - no outputThreshold optionThe source code of surfaceCheck lists the -outputThreshold option, but the utility is not compiled with the option available.
surfaceCheck returns: Invalid option: -outputThreshold
(both master and develop trees)The source code of surfaceCheck lists the -outputThreshold option, but the utility is not compiled with the option available.
surfaceCheck returns: Invalid option: -outputThreshold
(both master and develop trees)Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/717surfaceCheck output2020-01-03T14:21:04ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsurfaceCheck output1. it does not display the number of badquality triangles.
2. it has no way of visualising these (apart from surfaceSubset+Dict)
Attached start of adding writeSet option to surfaceCheck. This needs to be extended to output strings of ed...1. it does not display the number of badquality triangles.
2. it has no way of visualising these (apart from surfaceSubset+Dict)
Attached start of adding writeSet option to surfaceCheck. This needs to be extended to output strings of edges. See ep #703.
[surfaceCheck.C](/uploads/dfe8af4f901817396c6bf2ca6d67793e/surfaceCheck.C)
Typical output:
```
min 0 for triangle 110081
max 1 for triangle 985653
--> FOAM Warning :
From function int main(int, char**)
in file surfaceCheck.C at line 483
0. This might give problems in self-intersection testing later on.
Dumping bad quality faces to "badFaces"
```https://develop.openfoam.com/Development/openfoam/-/issues/955surfaceFeatureExtract accesses zero-sized bitSet2020-01-03T14:23:08ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsurfaceFeatureExtract accesses zero-sized bitSetMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1258SurfaceFeatureExtract cannot handle filenames starting with numerals.2019-03-29T07:59:34ZAdminSurfaceFeatureExtract cannot handle filenames starting with numerals.<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
-->
<!--
All text between these marker...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
When the filename of the geometry file in surfaceFeatureExtractDict starts with numerals, the applications quits with an error. However, filenames starting with numerals are legitimate filenames.
### Steps to reproduce
The issue can be reproduced by renaming the name of the geometry file to be processed to one starting with numerals, and making the corresponding change in the surfaceFeatureExtractDict.
### Example case
A simple example case has been added to this bug report.
[001_surfaceFeatureExtract_FileName_Bug.tar.gz](/uploads/a3892b7d3455cbb041dcf4ff382b2dc6/001_surfaceFeatureExtract_FileName_Bug.tar.gz)
### What is the current *bug* behaviour?
When surfaceFeatureExtract is run, and the name of the geometry file starts with numerals, surfaceFeatureExtract quits with the following error:
```
--> FOAM FATAL IO ERROR:
Expected a '(' or a '{' while reading List, found on line 17: word '_cfdValidation_8mm_15deg_001.stl'
file: /home/simuser001/OpenFOAM/simuser001-plus/run/RJ990_Issue_Testing/001_surfaceFeatureExtract_FileName_Bug/system/surfaceFeatureExtractDict at line 17.
From function char Foam::Istream::readBeginList(const char*)
in file db/IOstreams/IOstreams/Istream.C at line 134.
FOAM exiting
```
### What is the expected *correct* behavior?
The expectation is that the application surfaceFeatureExtract find the geometry file specified in the dict, extracts the edges, and quits without any error.
### Relevant logs and/or images
```
-NA-
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
OpenFOAM version : 1812
Operating system : CentOS 7
Compiler : GCC 4.8.5
### Possible fixes
None so far.https://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/1488surfaceField FO fails on interpolate2019-12-09T16:01:25ZMark OLESENsurfaceField FO fails on interpolatecross-ref EP1101 @Prashantcross-ref EP1101 @PrashantMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/783surfaceFieldValue does not check for failure to open data file2023-12-07T19:03:27ZPrashant SonakarsurfaceFieldValue does not check for failure to open data fileWith >1024 surfaceFieldValue function objects you might run out of filedescriptors for the data file!
There is currently no error message if it cannot open a data file.With >1024 surfaceFieldValue function objects you might run out of filedescriptors for the data file!
There is currently no error message if it cannot open a data file.Prashant SonakarPrashant Sonakarhttps://develop.openfoam.com/Development/openfoam/-/issues/1884surfaceFieldValue : doesn't handle volumeField2020-11-17T12:06:40ZPrashant SonakarsurfaceFieldValue : doesn't handle volumeField### Functionality to add/problem to solve
surface field value doesn't handle volume fields when using in faceZone mode.
Cross reference: EP#1316 and EP#1415
@mark @andy### Functionality to add/problem to solve
surface field value doesn't handle volume fields when using in faceZone mode.
Cross reference: EP#1316 and EP#1415
@mark @andyMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2066surfaceFieldValue is not exporting fields using sampledSurface2021-05-12T02:21:17Zzein elserfysurfaceFieldValue is not exporting fields using sampledSurface
### Summary
I am trying to save the velocity, pressure and rho on a rectangular surface. The surface is imported to OpenFOAM as STL file in the triSurface/constant.
These lines are added to the the contolDict file
```
surfaceFiel...
### Summary
I am trying to save the velocity, pressure and rho on a rectangular surface. The surface is imported to OpenFOAM as STL file in the triSurface/constant.
These lines are added to the the contolDict file
```
surfaceFieldValue1
{
type surfaceFieldValue;
libs ("libfieldFunctionObjects.so");
log true;
surfaceFormat foam;
writeControl writeTime;
timeStart 0;
writeInterval 1 ;
writeFields yes; // yes | no
writeArea yes;
regionType sampledSurface;
name sampledSurface;
sampledSurfaceDict
{
type sampledTriSurfaceMesh;
surface c-rect0.125c.stl;
source cells; // sample cells or boundaryFaces
interpolate true;
}
operation none;
fields (p);
}
```
The output log file does not show any problems with reading the function
`surfaceFieldValue surfaceFieldValue1:
operation = none
surfaceFormat = foam
`
The files output in the postProcessing folder is not including the surface directory for saved data
only folder name (surfaceFieldValue1) is generated contain one file (surfaceFieldValue.dat)
What could be the problem?is there a limit for STL file size? but also not error are shownhttps://develop.openfoam.com/Development/openfoam/-/issues/2989surfaceFieldValue: Not all patches in 'names' list are reported in Info stream2023-11-09T23:23:29ZMartin LichtmessurfaceFieldValue: Not all patches in 'names' list are reported in Info stream<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
When evaluating multiple patches in surfaceFieldValue FO using 'names' keyword, not all patch names seem to be reported back in Info stream, whereas the numerical value appears to be correct - only first patch name in list? - May cause confusion as to which patches contribute to the evaluation.
### Steps to reproduce
1. Set up surfaceFieldValue FO using list of patches (e.g. 'names (inlet, outlet)' in pitzDaily) and apply 'sum' operation
2. Run case and monitor info stream/solver output regarding surfaceFieldValue evaluation
### Example case
$FOAM_TUTORIALS/incompressible/pisoFoam/LES/pitzDaily
### What is the current *bug* behaviour?
Log snippet for three FOs (1. 'name inlet', sum(phi); 2. 'name outlet', sum(phi); 3. 'names (inlet outlet), sum(phi)):
```
surfaceFieldValue namesTest_inlet write:
sum(inlet) of phi = -0.000253241
surfaceFieldValue namesTest_outlet write:
sum(outlet) of phi = 0.000253241
surfaceFieldValue namesTest_inlet_outlet write:
sum(inlet) of phi = 2.09431e-11
```
### What is the expected *correct* behavior?
```
surfaceFieldValue namesTest_inlet_outlet write:
sum(inlet, outlet) of phi = 2.09431e-11
```
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
- OpenFOAM version : v2306
- Operating system : Ubuntu WSL/RedHat 8
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/1999surfaceFieldValue surface writer (VTK) fails with multiple fields2021-02-17T12:46:07ZMark OLESENsurfaceFieldValue surface writer (VTK) fails with multiple fieldscross-ref EP-1482 - agreed to fix in develop
It only outputs the final field.cross-ref EP-1482 - agreed to fix in develop
It only outputs the final field.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2273surfaceFieldValue weightedAverage missing division for mag(Sf)2021-11-26T12:27:34ZChiara PescisurfaceFieldValue weightedAverage missing division for mag(Sf)<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
Within the surfaceFieldValue FO we can compute weighted operations, among which the `weightedAverage`.
When the weightField is a vector field, then it is not clear if the weighting factor is computed correctly.
The computation of the weightedAverage is done in [surfaceFieldValueTemplates.C, line 195](https://develop.openfoam.com/Development/openfoam/blob/OpenFOAM-v2012/src/functionObjects/field/fieldValues/surfaceFieldValue/surfaceFieldValueTemplates.C#L195). But [here](https://develop.openfoam.com/Development/openfoam/blob/OpenFOAM-v2012/src/functionObjects/field/fieldValues/surfaceFieldValue/surfaceFieldValueTemplates.C#L193) the weighting factor is computed only for scalar values. As it is using the function `weightingFactor(weightField)` defined in [surfaceFieldValue.C, line 833](https://develop.openfoam.com/Development/openfoam/blob/OpenFOAM-v2012/src/functionObjects/field/fieldValues/surfaceFieldValue/surfaceFieldValue.C#L833). To my understanding here we are missing the case where the weightField is a vector, but we do not want an area weighting as well.
On the other hand, for area-averaged operations, such as weightedAreaAverage, we have both cases of [weightFactor=scalar](https://develop.openfoam.com/Development/openfoam/blob/OpenFOAM-v2012/src/functionObjects/field/fieldValues/surfaceFieldValue/surfaceFieldValue.C#L850) and [weightFactor=vector](https://develop.openfoam.com/Development/openfoam/blob/OpenFOAM-v2012/src/functionObjects/field/fieldValues/surfaceFieldValue/surfaceFieldValue.C#L874).
### What is the expected *correct* behavior?
For weightedAverage operation, the weighting factor with vector weightField should be computed using a unity vector, i.e. `weightField & (Sf/mag(Sf))`.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906|v1912|v2006|v2012|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2106, develop
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
To my understanding for the weighted averages with vector weightField we need to compute the factor as below:
```c
weightField & (Sf/mag(Sf))
```
together with the change in [surfaceFieldValueTemplates.C, line 193](https://develop.openfoam.com/Development/openfoam/blob/OpenFOAM-v2012/src/functionObjects/field/fieldValues/surfaceFieldValue/surfaceFieldValueTemplates.C#L193) as follows:
```c
const scalarField factor(weightingFactor(weightField, Sf));
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/661surfaceFieldValue with faceZone restricted to boundary faces2017-12-20T09:40:03ZMark OLESENsurfaceFieldValue with faceZone restricted to boundary facesWas discussing this with @landmann - any reason not to simply use a owner/neighbour average value for internal faces?
@andy, @MattijsWas discussing this with @landmann - any reason not to simply use a owner/neighbour average value for internal faces?
@andy, @MattijsMark OLESENMark OLESEN