Development issueshttps://develop.openfoam.com/groups/Development/-/issues2016-10-04T09:50:10Zhttps://develop.openfoam.com/Development/openfoam/-/issues/249Field construct from indirect list2016-10-04T09:50:10ZMark OLESENField construct from indirect listCurrently need two parameters to construct a field from indirect addressing. A constructor from UIndirectList for ease of use. Already filed upstream, but no activity there.
@MattijsCurrently need two parameters to construct a field from indirect addressing. A constructor from UIndirectList for ease of use. Already filed upstream, but no activity there.
@MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/298Field construct from Xfer<Field> fails2016-12-15T21:06:49ZMark OLESENField construct from Xfer<Field> failsCannot pass through to underlying list directly.Cannot pass through to underlying list directly.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1675fieldCoordinateSystemTransform fails to write "U:Transformed" field on a Wind...2022-07-28T04:30:32ZJustin GraupmanfieldCoordinateSystemTransform fails to write "U:Transformed" field on a Windows OS### Summary
fieldCoordinateSystemTransform function object attempts to write "U:Transformed" field on Windows OS even though the ":" character it not supported in file names. This results in the field not being written.
### Steps to r...### Summary
fieldCoordinateSystemTransform function object attempts to write "U:Transformed" field on Windows OS even though the ":" character it not supported in file names. This results in the field not being written.
### Steps to reproduce
This can be reproduced using a modified version of the simpleFoam pipeCyclic tutorial.
1. Open a OpenFOAM-MS-DOSPrompt.bat window
2. Navigate to the attached slightly modified pipeCyclic tutorial
3. Run simpleFoam
The log will show that the field is trying to be written, but it never shows up in the time directory.
`functionObjects::fieldCoordinateSystemTransform coordinateTransform writing field: U:Transformed`
### Example case
[pipeCyclic.zip](/uploads/3059de4c995aef7c3ea9153da8be9610/pipeCyclic.zip)
### What is the current *bug* behaviour?
The U:Transformed is not written like it should be due to the Windows OS not supporting the ":" character in a file name.
### What is the expected *correct* behavior?
U:Transformed needs to be written with a compatible file name.
### Environment information
- OpenFOAM version : v1912
- Operating system : Windows 10
- Hardware info : Intel
- Compiler : MinGW
- Prompt : OpenFOAM-MS-DOSPrompt.bat
### Possible fixes
The simplest fix in my opinion would be to add the ability to change the name of the written field in the fieldCoordinateSystemTransform function object using an option like...
fields ( (U U_Transformed) );Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1076fieldCoordinateTransform wrong2018-11-20T14:12:14ZMark OLESENfieldCoordinateTransform wrong- doesn't work with cylindrical
- uses transform (local->global) instead of invTransform (global->local)
@Prashant- doesn't work with cylindrical
- uses transform (local->global) instead of invTransform (global->local)
@PrashantMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/713Field has no xfer()2018-03-26T20:14:18ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comField has no xfer()with
```
scalarField edgeWeight(...);
```
then the .xfer() returns a List<scalar> instead of a Field<scalar>
The workaround is
```
xferMoveTo<scalarField, scalarList>(edgeWeight)
```with
```
scalarField edgeWeight(...);
```
then the .xfer() returns a List<scalar> instead of a Field<scalar>
The workaround is
```
xferMoveTo<scalarField, scalarList>(edgeWeight)
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/405FieldMapper.H - null reference2018-05-29T05:39:48ZMark OLESENFieldMapper.H - null referenceICC complaints about line 79
PDRMesh.C line 358, 361 carp about ref to old-init at line 335
ICC complaints about line 79
PDRMesh.C line 358, 361 carp about ref to old-init at line 335
Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/207Field mapping using the tetOverlapVolume class an be fragile when using the c...2019-12-09T22:04:10ZAdminField mapping using the tetOverlapVolume class an be fragile when using the cellVolumeWeight optionThe cellVolumeWeight option calculates volume conservative weights when mapping between meshes. However, the use of tolerances e.g. comparing against the decomposed tet volume is not sufficient in some cases, and not consistent with the...The cellVolumeWeight option calculates volume conservative weights when mapping between meshes. However, the use of tolerances e.g. comparing against the decomposed tet volume is not sufficient in some cases, and not consistent with the failure mode reported by the plane class. Typical error suggests that a plane normal direction cannot be defined due to collapsed tet points:
```
[3] --> FOAM FATAL ERROR:
[3] Plane normal defined with zero length
Bad points:(0.176595 0.0984721 0.39584) (0.176595 0.0993738 0.39584) (0.176595 0.098964 0.39584)
[3]
[3] From function void Foam::plane::calcPntAndVec(const Foam::point&, const Foam::point&, const Foam::point&)
[3] in file meshes/primitiveShapes/plane/plane.C at line 101.
```Version v1612AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1861fieldMinMax does not show if max is on patchface2020-09-28T09:41:14ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfieldMinMax does not show if max is on patchface### Functionality to add/problem to solve
the fieldMinMax functionObject gives as output:
- min/max
- location
- processor
- cell
If the min/max is on a boundary face instead of in a cell it does not tell you so. Note that the locatio...### Functionality to add/problem to solve
the fieldMinMax functionObject gives as output:
- min/max
- location
- processor
- cell
If the min/max is on a boundary face instead of in a cell it does not tell you so. Note that the location is (correctly) the face centre but it would be nice if it could tell you e.g. the patch and face index instead of the cell.
### Proposal
Maybe print patch/face index instead of cell?https://develop.openfoam.com/Development/openfoam/-/issues/644fieldMinMax reporting wrong location2017-12-18T05:07:55ZRoger AlmenarfieldMinMax reporting wrong locationUsing v1706.
I am monitoring min/max velocities in a thermal case using the fieldMinMax FO (rhoSimpleFoam). The report of the maximum velocity seems to be going OK, but I have an issue with the location: the cell number stays constant, w...Using v1706.
I am monitoring min/max velocities in a thermal case using the fieldMinMax FO (rhoSimpleFoam). The report of the maximum velocity seems to be going OK, but I have an issue with the location: the cell number stays constant, whilst the actual XYZ location changes along the iterations, as shown here:
*> max(mag(U)) = 20.252895 in cell 110637 at location (0.38 0.004410381 0.004410381) on processor 12
> max(mag(U)) = 20.257627 in cell 388740 at location (0.476 -0.004410381 -0.004410381) on processor 3
> max(mag(U)) = 20.262458 in cell 388740 at location (0.47866667 -0.004410381 -0.004410381) on processor 3
> max(mag(U)) = 20.267294 in cell 388740 at location (0.484 -0.004410381 -0.004410381) on processor 3
> max(mag(U)) = 20.272106 in cell 388740 at location (0.48933333 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.276871 in cell 388740 at location (0.49466667 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.281582 in cell 388740 at location (0.5 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.286253 in cell 388740 at location (0.50533333 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.290906 in cell 388740 at location (0.51333333 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.295564 in cell 388740 at location (0.52133333 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.300241 in cell 388740 at location (0.532 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.304942 in cell 388740 at location (0.54 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.309656 in cell 388740 at location (0.548 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.314368 in cell 388740 at location (0.556 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.319065 in cell 388740 at location (0.564 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.323737 in cell 388740 at location (0.572 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.328381 in cell 388740 at location (0.58 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.333002 in cell 388740 at location (0.59066667 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.337603 in cell 388740 at location (0.59866667 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.342193 in cell 388740 at location (0.60933333 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.346773 in cell 388740 at location (0.62 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.351343 in cell 388740 at location (0.628 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.355903 in cell 388740 at location (0.63866667 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.360447 in cell 388740 at location (0.64933333 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.364974 in cell 388740 at location (0.66 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.369483 in cell 388740 at location (0.668 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.373976 in cell 388740 at location (0.67866667 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.378457 in cell 388740 at location (0.68933333 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.382929 in cell 388740 at location (0.7 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.387393 in cell 388740 at location (0.71066667 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.391851 in cell 388740 at location (0.71866667 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.396301 in cell 388740 at location (0.72933333 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.40074 in cell 388740 at location (0.74 -0.0022061122 -0.0022061122) on processor 3
> max(mag(U)) = 20.405165 in cell 388740 at location (0.75066667 -0.0022061122 -0.0022061122) on processor 3*v1712https://develop.openfoam.com/Development/openfoam/-/issues/2119field multiplication produces illegal word as field name2021-06-14T12:01:01ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfield multiplication produces illegal word as field name<!--
*** 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
<!-- Summarize the bug encountered concisely -->
Discretisation can create illegal words as field names. Below testcase produces a field
`(betavSolid*thermo:alpha)BlendingFactor` for use in localBlended scheme but that does not parse correctly.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
```
blockMesh
postProcess
```
[twoBlocks.tgz](/uploads/4a3df920bb4f393d0cb77cc85549a25b/twoBlocks.tgz)
### 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 : v2106https://develop.openfoam.com/Development/openfoam/-/issues/2382fieldScaling : missing for sampling in ensight format2022-03-02T14:25:16ZPrashant SonakarfieldScaling : missing for sampling in ensight format### Functionality to add/problem to solve
With commit https://develop.openfoam.com/Development/openfoam/-/commit/f8ffee8135d242d352531cbb9dc6b80c5bf4e62a field scaling was extended, however it is still missing for ensight format.### Functionality to add/problem to solve
With commit https://develop.openfoam.com/Development/openfoam/-/commit/f8ffee8135d242d352531cbb9dc6b80c5bf4e62a field scaling was extended, however it is still missing for ensight format.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1279fieldToCell does not use lookup; always reads from disk2022-12-23T14:55:17ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfieldToCell does not use lookup; always reads from disk### Functionality to add/problem to solve
fieldToCell currently always reads from disk. Hence it cannot be used in e.g. a functionObject to select some cells during the run (). Would be nice if it would try lookup first instead.
### Pr...### Functionality to add/problem to solve
fieldToCell currently always reads from disk. Hence it cannot be used in e.g. a functionObject to select some cells during the run (). Would be nice if it would try lookup first instead.
### Proposal
- add database lookup first and loading from disk only if that fails
- move fieldToCell to finiteVolume and use proper fields
Example of desired use: plot all cells where the pressure is between 5 and 1000.
```
vtkWrite1
{
type vtkWrite;
libs ("libutilityFunctionObjects.so");
timeStart 10;
writeControl timeStep;
writeInterval 1;
format binary;
legacy false;
decompose false;
fields (p U);
selection
{
threshold
{
action use;
source fieldToCell;
field p;
min 5;
max 1000;
}
}
}
```
There is currently also a bug in that it searches for the last valid p,U instead of loading them from the current time (and failing).v2306Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/974fileHandler in combination with threading2020-01-08T14:47:22ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfileHandler in combination with threadingWhen using a threaded fileHandler (e.g. collated) the code does not know to wait for a file being written before trying to read it. This happens e.g. in topoSet (reading a set that has just been written), decomposePar (reading the decomp...When using a threaded fileHandler (e.g. collated) the code does not know to wait for a file being written before trying to read it. This happens e.g. in topoSet (reading a set that has just been written), decomposePar (reading the decomposed mesh to decompose the fields)
Solutions:
- switch off threading altogether. This is what is currently done.
- have IFstream know about currently written files. This would require all IFstream to go through the fileHandler, so use fileHandler().NewIFstream instead of IFstream everywhere.
- since it is only a few applications that have this make sure to reset the fileHandler.
This last solution has been implemented by a new 'flush()' method on all fileHandlers which clears out any cached data (e.g. time directories) and waits for all file operations to finish.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1056filters for Lagrangian vtk output2018-12-12T21:17:26ZAdminfilters for Lagrangian vtk outputI’d like to be able to filter the Lagrangian output so that not such a large number of parcels gets written to the *.vtp files from the vtkCloud functionObject. Since the vtp files are being used for animations, I typically only need le...I’d like to be able to filter the Lagrangian output so that not such a large number of parcels gets written to the *.vtp files from the vtkCloud functionObject. Since the vtp files are being used for animations, I typically only need less than 50K parcels to get a reasonable representation of the spray. Could you add such a filter to the vtkCloud functionObject? One caveat is that the parcel ids would need to be consistent between output times (otherwise the animation would be very choppy, with a totally independent sampling of parcels at each output time). Also, it’d be nice to allow the user to apply some additional filters, for example only outputting parcels with a diameter within a specific range, etc.
Hope this is doable, as it would be a great help to my work!Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2609filter/smooth mapped file inputs2023-02-14T14:49:49ZMark OLESENfilter/smooth mapped file inputscross-ref EP1995 !568 !573
Sampling from high resolution onto lower resolution surface adds spatial frequency aliasing.cross-ref EP1995 !568 !573
Sampling from high resolution onto lower resolution surface adds spatial frequency aliasing.v2212Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1182find in list with predicate2019-01-26T20:13:47ZMark OLESENfind in list with predicatecan currently use find/found for UList, or even with the older (deprecated) findIndex, but these search for a value. Would be useful to allow a predicate.
@Mattijscan currently use find/found for UList, or even with the older (deprecated) findIndex, but these search for a value. Would be useful to allow a predicate.
@MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2233finiteArea fails with calcPointAreaNormals2022-04-29T15:14:48ZMark OLESENfiniteArea fails with calcPointAreaNormalsThis issue has been tagged internally (EP1619) and @vaggelisp did some investigation (notes in !490).
Here are some of his notes reattached:
> [Ahmed-FaMesh-3453d169.tar.gz](/uploads/27b25f20e0acf8edef8ebe705fa79fe3/Ahmed-FaMesh-3453d1...This issue has been tagged internally (EP1619) and @vaggelisp did some investigation (notes in !490).
Here are some of his notes reattached:
> [Ahmed-FaMesh-3453d169.tar.gz](/uploads/27b25f20e0acf8edef8ebe705fa79fe3/Ahmed-FaMesh-3453d169.tar.gz)
> ... makeFaMesh still fails for hierarchical: coeffs (5 4 2), with a different error this time (floating point exception in calcPointAreaNormals)
```
[23] #1 Foam::sigFpe::sigHandler(int) at ??:?
[23] #2 ? in /lib64/libpthread.so.0
[23] #3 Foam::faMesh::calcPointAreaNormals() const at ??:?
[23] #4 Foam::faMesh::pointAreaNormals() const at ??:?
[23] #5 Foam::faBoundaryMesh::calcGeometry() at ??:?
[23] #6 Foam::faMesh::faMesh(Foam::polyMesh const&) at ??:?
[23] #7 ? at ??:?
[23] #8 __libc_start_main in /lib64/libc.so.6
[23] #9 ? at ??:?
```
Along with some discussion notes:
![20211005_notesOnFaMesh](/uploads/e0f6843e4f0de836967a50b0de196b09/20211005_notesOnFaMesh.jpg)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2771finite-area issues with multiply connected edges2023-06-14T12:08:54ZMark OLESENfinite-area issues with multiply connected edgescross-ref EP2148
- multiply-connected edges can arise at the centre of a "star"
connection or because the patch faces are actually baffles.
- In the serial case these internal edges are also rather dubious in
terms of modelling...cross-ref EP2148
- multiply-connected edges can arise at the centre of a "star"
connection or because the patch faces are actually baffles.
- In the serial case these internal edges are also rather dubious in
terms of modelling. However, when they are split across multiple
processors there can only be a single processor-to-processor
connectivity.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1637Finite Area Method: ZeroGradient Boundary condition changed2020-04-21T15:38:36ZMatti RauterFinite Area Method: ZeroGradient Boundary condition changed<!--
*** 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 ...<!--
*** 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
I use the zeroGradient boundary condition for outlets in thin film simulations (with faSavageHutterFoam from the avalanche module).
This strategy worked with v1812 but does not after an update to v1912.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Outlets, modeled as grad(Us) = 0, grad(h) = 0 in shallow water/thin film simulations will show distortions.
Run the appended case with OpenFOAM-v1912. It relies on the avalanche module.
<!-- How one can reproduce the issue - this is very important -->
### Example case
This example is taken from section 6.2 in https://www.researchgate.net/publication/323184565_A_finite_area_scheme_for_shallow_granular_flows_on_three-dimensional_surfaces
[outlet_testcase.zip](/uploads/0776a4aaabcd76d0494c66a8bd252b5c/outlet_testcase.zip)
## Result of the example with OpenFOAM-v1812
![OpenFOAM-v1812](/uploads/449d69d2694ab0e8ffdbaed438c20a1c/OpenFOAM-v1812.png)
## Result of the example with OpenFOAM-v1912
Note the high peak of the height at the outlet.
![OpenFOAM-v1912](/uploads/eac1d1a7395e246c4b0903d7c14ad3d4/OpenFOAM-v1912.png)
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
The height grows monotonically near the outlet.
<!-- What actually happens -->
### What is the expected *correct* behavior?
The height should reach a steady state near the outlet similar to the rest of the domain.
<!-- What you should see instead -->
### 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
<!--
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 : v1912
- Operating system : Ubuntu (Linux Mint)
- Hardware info :
- Compiler : gcc
### Possible fixes
I expect the change in the zeroGradient boundary condition.
<!--
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/1431finite area non-orthogonal treament errors vs finite volume operators2020-03-19T15:51:29ZSergio Ferrarisfinite area non-orthogonal treament errors vs finite volume operatorsThe treatment of non-orthogonality in fam::laplcian operator differs from fvm:laplacian.
In this simple fixed BC temperature 2D slab, the same mesh is used for fam and fvm. While
in fvm the gradx(T)is smooth in fam presents non-uniformit...The treatment of non-orthogonality in fam::laplcian operator differs from fvm:laplacian.
In this simple fixed BC temperature 2D slab, the same mesh is used for fam and fvm. While
in fvm the gradx(T)is smooth in fam presents non-uniformity, specially close to the patches.
See aGradTx vs vGradTx.
laplacianFaFoam.tar is the fa solver
laplacianFoam is the fv solver.
The case cavity.tar contains the mesh and set up.
[aGradTx](/uploads/07f26b72d0b5cab79c334e8f4e9b7271/aGradTx.png)
[cavity.tar](/uploads/3a5a59a3b65fc071f00b99e64551df5b/cavity.tar)
[laplacianFaFoam.tar](/uploads/753a45d2a662a9bfd3a29b92a7afefbe/laplacianFaFoam.tar)
![vGradTx](/uploads/fabe63aa3fdef2f6c56fc1435a08873e/vGradTx.png)
The issue seems to be related to how the non-orthogonality is treated in the fam::laplacian,
special care should be taken for the non-orthogonality on the boundaries.v1912Sergio FerrarisSergio Ferraris