Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-12-07T19:03:27Zhttps://develop.openfoam.com/Development/openfoam/-/issues/785verbatim string (inbetween #{ .. #} , for e.g. code sections) is limited to 8...2023-12-07T19:03:27ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comverbatim string (inbetween #{ .. #} , for e.g. code sections) is limited to 8000 chars.Larger code sections might not fit inside a single verbatim string. Since it is a static char array there is no real limit on its size.
- workaround: move sections of code into included file
- solution: increase size (but this permanentl...Larger code sections might not fit inside a single verbatim string. Since it is a static char array there is no real limit on its size.
- workaround: move sections of code into included file
- solution: increase size (but this permanently increases memory usage)
- or : assign to stringMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/570Velocity fluctuation in porousSimpleFoam2017-08-16T05:19:51ZAdminVelocity fluctuation in porousSimpleFoamWhile using 'porousSimpleFoam' solver its expected to show constant superficial velocity along the flow.
But its showing some variation or oscillation at the entrance, at higher velocities the its showing at more regions.
Tried with a ve...While using 'porousSimpleFoam' solver its expected to show constant superficial velocity along the flow.
But its showing some variation or oscillation at the entrance, at higher velocities the its showing at more regions.
Tried with a very low relaxation factor also, it doesn't works.
But the pressure drop is showing convincing values.https://develop.openfoam.com/Development/openfoam/-/issues/942velocity damping description not up-to-date2019-12-18T16:20:17Zvilfayeauvelocity damping description not up-to-dateHi,
I'd just realized that the velocity damping header file description is not up-to-date
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/fvOptions/constraints/derived/velocityDampingConstraint/velocityDampingCon...Hi,
I'd just realized that the velocity damping header file description is not up-to-date
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/fvOptions/constraints/derived/velocityDampingConstraint/velocityDampingConstraint.H
It should be:
`
damp
{
type velocityDampingConstraint;
active true;
velocityDampingConstraintCoeffs
{
UMax 25;
selectionMode all;
// Optional: name of velocity field (default: U)
//UName U;
}
}
`
Best,
SebastienKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/4vector field required in documentation section2023-08-19T21:13:18ZPrashant Sonakarvector field required in documentation sectionmovingWallVelocityFvPatchVectorField.H should have velocity "vector" initialization value.movingWallVelocityFvPatchVectorField.H should have velocity "vector" initialization value.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2444vectorField normalise2022-04-30T14:48:23ZMark OLESENvectorField normalise- further to today's discussions, should add in a normalise() method to vectorField and GeometricFields.
Default implementation would be a no-op. For a specialised `vectorField` would forward to calling vector::normalise on each entry. ...- further to today's discussions, should add in a normalise() method to vectorField and GeometricFields.
Default implementation would be a no-op. For a specialised `vectorField` would forward to calling vector::normalise on each entry. FieldFields - same thing.
@kuti expressed the wish to have an optional tolerance parameter. Which is ok, except that we would probably want to unroll the function calls to determine the mag directly (within the loop) instead of forwarding to vector::normalise for that.
Not really sure if we want to have a top-level normalise function (eg, taking a field and returning a tmp). Could get a bit weird, not sure we need it.
Main benefits:
- simpler to write ; Eg, `fld.normalise()` vs. `field /= mag(fld)`
- while _not_ forgetting to handle divide by zero. Eg, `fld.normalise()` vs. `field /= mag(fld) + VSMALL`
- code efficiency. More efficient to loop over and re-assign the existing field instead of allocating a tmp (for the mag) adding VSMALL and then dividing (another tmp) to replace the original field.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/230Various threads at CFD-Online that don't have an answer yet for the Docker-ba...2020-06-18T21:16:37ZAdminVarious threads at CFD-Online that don't have an answer yet for the Docker-based installations@Pawan I've finally managed to make a first pass at the list of threads in the [OpenFOAM installation sub-forum](http://www.cfd-online.com/Forums/openfoam-installation/) since late April 2016 and here are the threads that I've found so f...@Pawan I've finally managed to make a first pass at the list of threads in the [OpenFOAM installation sub-forum](http://www.cfd-online.com/Forums/openfoam-installation/) since late April 2016 and here are the threads that I've found so far that didn't get an answer in the past few months:
* http://www.cfd-online.com/Forums/openfoam-installation/171197-openfoam-plus-not-even-starting-ubuntu-14-04-lts.html
* http://www.cfd-online.com/Forums/openfoam-installation/174194-openfoam-plus-v1606-not-running-windows.html#post608637 - the last post sort-of needs an answer or some possible feedback, not sure
* http://www.cfd-online.com/Forums/openfoam-installation/175116-openfoam-plus-v1606-installation-mac-os-el-captain-using-docker.html#post612446
* http://www.cfd-online.com/Forums/openfoam-installation/168799-openfoam-plus-error-running-parafoam.html#post592188
By the way, due to how the forum indexes words, the correct'ish way to search for the threads that have `[OpenFOAM plus]` on their titles is with this:
```
[OpenFOAM plus*
```
This is at least applicable for the threads that I've managed to find and edit their titles accordingly.
\## Reattaching the author to the issue ticket: @wyldckat ##Pawan GhildiyalPawan Ghildiyalhttps://develop.openfoam.com/Development/openfoam/-/issues/815vanDriestDelta documentation - the default value of Cdelta2019-11-14T18:32:54ZKutalmış BerçinvanDriestDelta documentation - the default value of CdeltaHi,
Please see the two remarks below for `vanDriestDelta` implementation:
1. As can be seen in `vanDriestDelta.C` lines: [87-91], the van Driest function formulation (doi: 10.2514/8.3713, 1956) is slightly different from its original ...Hi,
Please see the two remarks below for `vanDriestDelta` implementation:
1. As can be seen in `vanDriestDelta.C` lines: [87-91], the van Driest function formulation (doi: 10.2514/8.3713, 1956) is slightly different from its original form. A *minimum switch* was introduced by de Villiers (http://bit.ly/1unTPaB, 2006) as shown in pages: [124, 260]. IMHO, it would be nice of you as well as useful to some users if his heuristic modification/work is noted and cited in the Extended Code Guide, which is currently absent.
2. In addition, `vanDriestCoeffs`'s `Cdelta` is (most of the time) kept equal to `0.158` by default in the tutorials as can be found in `tutorials/incompressible/pimpleFoam/LES/channel395DFSEM/constant/turbulenceProperties` of v1712, for instance. However, as shown in de Villiers, the unnumbered equation in page 260, `Cdelta` is actually `Cs`. This may suggest, at least for `channel395DFSEM` tutorial, that `Cdelta` needs to equate `Cdelta=Cs=0.065` rather than `0.158`. Not sure if it is of practical importance though. Just an observation :)
Kind regards,Kutalmış BerçinKutalmış Berçin2018-12-31https://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/198Validaion of 'type humidityTemperatureCoupledMixed'2019-09-20T13:24:55ZAdminValidaion of 'type humidityTemperatureCoupledMixed'Dear developer
I'm interested in the simulation for heat and mass transfer and expect the case, windshieldCondensation, to be applied to various fields.
For the case, /tutorials/heatTransfer/chtMultiRegionFoam/windshieldCondensati...Dear developer
I'm interested in the simulation for heat and mass transfer and expect the case, windshieldCondensation, to be applied to various fields.
For the case, /tutorials/heatTransfer/chtMultiRegionFoam/windshieldCondensation,
in the process to 60 sec, I consider that vapor in 'cabin' will condense on 'windshield_to_cabin'.
But the heat flux on 'windshield_to_cabin' dose not equal to that of 'exterior' even if this solver deals with unsteady state process.
I want you to explain this result.
[log.wallHF.tar.gz](/uploads/f70ac9f8a20a18e19a1085d7eef9c6aa/log.wallHF.tar.gz)https://develop.openfoam.com/Development/openfoam/-/issues/2540valgrind complains about memory leackage in simpleFoam when running in parallel2022-11-17T07:30:47ZVaggelis Papoutsisvalgrind complains about memory leackage in simpleFoam when running in parallelI am trying to hunt down a memory leakage problem within an in-house class that appears when running in parallel but not in serial.
In the process of doing so, I discovered mpirunDebug (there seems to be a nice script for everything yo...I am trying to hunt down a memory leakage problem within an in-house class that appears when running in parallel but not in serial.
In the process of doing so, I discovered mpirunDebug (there seems to be a nice script for everything you need :) )
When executing it however, valgrind reports multiple leakage errors related to UPstream.
I then switched to the pitchDaily case ran with simpleFoam and I get similar errors (case attached case [pitzDaily.tar.gz](/uploads/479cbb9918e45fa42b5f22f76c660261/pitzDaily.tar.gz))
I have tested in the following environments
1)
- OpenFOAM version: v2206
- OS: CentOS Linux release 7.5.1804
- Compiler: gcc (OpenFOAM) 9.3.0
- valgrind: valgrind-3.13.0
- mpi: OpenMPI 1.10.7
Log file from processor0: [processor0_env1.log](/uploads/c712588770fffca4f6b24fe5900a0c01/processor0_env1.log)
2)
- OpenFOAM version: v2206 (binary pack)
- OS: Ubuntu 22.04
- Compiler: gcc (Ubuntu 11.2.0-19ubuntu1) 11.2.0
- valgrind: valgrind-3.18.1
- mpi: OpenMPI 4.1.2
Log file from processor0: [processor0_env2.log](/uploads/56d72025391906fa0087d1bb89c8529b/processor0_env2.log)
As you will see, some errors are common, some exist only in the first environment but all seem to be related to UPStream somehow.
I am assuming these are false positives from valgrind. Any idea what is causing them or how they can be suppressed? They tend to pollute the outcome to a degree that makes tracking the real issue (if any) quite challenging.
Any help is appreciated.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1983v2012 new polyline extrudeMesh doesn't support spline2023-01-27T16:18:17ZGuanyang Xuev2012 new polyline extrudeMesh doesn't support spline### Functionality to add/problem to solve
In `src/mesh/extrudeModel/polyline/polyline.H` spline is mentioned as supported.
```c
Description
Extrudes by transforming points along a polyline provided as a
series of points and edge segmen...### Functionality to add/problem to solve
In `src/mesh/extrudeModel/polyline/polyline.H` spline is mentioned as supported.
```c
Description
Extrudes by transforming points along a polyline provided as a
series of points and edge segments. Supports all blockMesh edge
types, e.g. line, arc, spline. The surface points are rotated to
follow the path.
```
However when I added a spline to the path it shows
```
--> FOAM FATAL ERROR: (openfoam-2012)
Not implemented
From Foam::scalar Foam::CatmullRomSpline::length() const
in file blockEdges/splineEdge/CatmullRomSpline.C at line 136.
FOAM aborting
```
So basically in `src/mesh/blockMesh/blockEdges/splineEdge/CatmullRomSpline.C`
```c
Foam::scalar Foam::CatmullRomSpline::length() const
{
NotImplemented;
return 1;
}
```
The length of the spline is not implemented yet and makes it impossible to extrude.
### Target audience
When using lines and arcs, the discontinuity in curvature(2nd order derivative) results in sudden change on cell size.
See attached image: red<green<blue, the sudden change exceeds the ideal expansion ratio.
![mesh](/uploads/14edd53eac9716bcf22cb0d4d20eec7d/mesh.png)
Splines are ~~naturally C2 continuous~~ (not true for Catmull, see http://www.mvps.org/directx/articles/catmull/) and should guarantee a smooth transition of cell size.
### Proposal
I don't know how to evaluate the length of Catmull Rom spline and can't find it online. But if the parametric equation is known then it's doable.
Seems like only lines and arcs are implemented and all other curves are left out. Is it possible to implement cubic spline as the length is well known?
### What does success look like, and how can we measure that?
Implement the length of the spline and extrudeMesh should not show error message.
### Links / references
N/A
### Funding
N/Ahttps://develop.openfoam.com/Development/openfoam/-/issues/1900v2006 atmWallConditions produce double value entries2020-12-08T09:38:07ZMark Van Cv2006 atmWallConditions produce double value entries<!--
*** 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 -->
When running a case utilizing some of the new atmBoundaryLayer wall functions (I verified this for atmOmegaWallFunction and atmNutkWallFunction but others might present the same issue), the patches defined by these functions contain double value field entries causing an error upon opening in ParaView (5.8.1 on Windows 10).
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run any case using either the atmNutkWallFunction or atmOmegaWallFunction boundary definitions.
### Example case
<!--
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?
<!-- What actually happens -->
The boundary fields defined with either of these wall functions contain duplicate <value> entries, causing errors when opening the case in ParaView. In case of the atmNutkWallFunction for example:
```
boundaryField
{
bottom
{
type atmNutkWallFunction;
value nonuniform List<scalar>
19200
(
...
)
;
boundNut false;
z0 0.003;
value nonuniform List<scalar>
19200
(
...
)
;
};
```
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The value entry should be written only once per boundary patch.
### 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 : v2006
- Operating system : WSL 20.04 (Ubuntu 20.04 shell on Windows 10 1909)
- Hardware info : N/A
- Compiler : gcc 6.3.0
### 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
-->
[atmNutkWallFunctionFvPatchScalarField.C L201](https://develop.openfoam.com/Development/openfoam/blob/OpenFOAM-v2006/src/atmosphericModels/derivedFvPatchFields/wallFunctions/atmNutkWallFunction/atmNutkWallFunctionFvPatchScalarField.C#L201)
[atmOmegaWallFunctionFvPatchScalarField.C L199](https://develop.openfoam.com/Development/openfoam/-/blob/OpenFOAM-v2006/src/atmosphericModels/derivedFvPatchFields/wallFunctions/atmOmegaWallFunction/atmOmegaWallFunctionFvPatchScalarField.C#L199)
A possible workaround might be to change `nutkWallFunctionFvPatchScalarField::write(os);` and `omegaWallFunctionFvPatchScalarField::write(os);` to `fvPatchField<scalar>::write(os);`.
I extracted this potential fix from [atmAlphatkWallFunctionFvPatchScalarField.C](https://develop.openfoam.com/Development/openfoam/-/blob/OpenFOAM-v2006/src/atmosphericModels/derivedFvPatchFields/wallFunctions/atmAlphatkWallFunction/atmAlphatkWallFunctionFvPatchScalarField.C#L288).v2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1597v1912 over*DyMFoam tutorials fail on multi-node parallel2020-10-06T21:23:24ZGreg Burgreenv1912 over*DyMFoam tutorials fail on multi-node parallelDo the v1912 tutorial cases overInterDyMFoam/floatingBody and overPimpleDyMFoam/simpleRotor work for you guys for a multi-node parallel run?
They both work fine for me serial and on a single parallel node. Once I try multi-node parallel...Do the v1912 tutorial cases overInterDyMFoam/floatingBody and overPimpleDyMFoam/simpleRotor work for you guys for a multi-node parallel run?
They both work fine for me serial and on a single parallel node. Once I try multi-node parallel processing, I am getting either scrambled garbage for the field variables (floatingBody) or returns segFault or sigFpe on a random iteration (simpleRotor). It appears that data is not being properly transferred across compute nodes.
I am using Scotch decomposition and OpenMPI-4.0.0.
```
PIMPLE: iteration 1
[2] [5] #0 #0 Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&) at at ??:?
[2] #1 Foam::sigFpe::sigHandler(int)??:?
[5] #1 Foam::sigFpe::sigHandler(int) at ??:?
[2] #2 ? at ??:?
[5] #2 ? in /lib64/libc.so.6
[2] #3 Foam::divide(Foam::Field<double>&, double const&, Foam::UList<double> const&) in /lib64/libc.so.6
[5] #3 Foam::divide(Foam::Field<double>&, double const&, Foam::UList<double> const&) at ??:?
[2] #4 void Foam::divide<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>&, Foam::dimensioned<double> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
[5] #4 at ??:?
```v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/970v1806 - sampledSurface - Missing functionality - "average"2018-12-21T18:06:28ZAdminv1806 - sampledSurface - Missing functionality - "average"In the current version of OpenFOAM, previously existing functionality of the **sampledSurface** to also calculate **average** of a given field over the sampled surface has **ceased** to exist.
This has resulted in breaking custom in-ho...In the current version of OpenFOAM, previously existing functionality of the **sampledSurface** to also calculate **average** of a given field over the sampled surface has **ceased** to exist.
This has resulted in breaking custom in-house solvers and function objects which depend on this function.
Could someone please recommend changes required to be made to the custom code, so as to minimise disruption of downstream code, and so that I can maintain the base concept used in the custom solvers. It would be highly inefficient if I have to re-concenptualise the solver to work around this missing functionality.
Thank you.
Regards,
Philippose RajanMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/836v1712 cfmesh compile errors2018-05-28T13:07:23ZAdminv1712 cfmesh compile errorsSee thread here: https://www.cfd-online.com/Forums/openfoam-community-contributions/199262-openfoam-1712-cfmesh-compile-error.html
Compiling OpenFOAM v1712 works except for cfmesh. I got the same errors as the two people in the above th...See thread here: https://www.cfd-online.com/Forums/openfoam-community-contributions/199262-openfoam-1712-cfmesh-compile-error.html
Compiling OpenFOAM v1712 works except for cfmesh. I got the same errors as the two people in the above thread. I have not tried to troubleshoot this.
I did a quick search of the issues and didn't find anything regarding cfmesh, but sorry if this has already been reported.
OS: CentOS 7.5
OF: v1712https://develop.openfoam.com/Development/openfoam/-/issues/877utility to rename existing fields2018-06-19T15:59:09ZMark OLESENutility to rename existing fieldsUseful, for example, to change a `UMean` to `U` field for further calculation (ref: EP523)
- if required in the future, could have a generalized rename utility (with regular expressions and placeholders etc), but for the current require...Useful, for example, to change a `UMean` to `U` field for further calculation (ref: EP523)
- if required in the future, could have a generalized rename utility (with regular expressions and placeholders etc), but for the current requirements a simple small set of pre-defined methods should be sufficient.
- The method `mean`
s/^(.+)Mean/$1/;
# Renames existing target as $1.orig
- The method `orig`
s/^(.+)\.orig/$1/;
These predefined actions are obviously less flexible than regex support, but presumably also user friendlier.
@PrashantMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1887Using the -case argument with extrudeMesh to specify the case directory does ...2020-11-02T09:15:54ZGerhard HolzingerUsing the -case argument with extrudeMesh to specify the case directory does not apply to paths stated in extrudeMeshDict<!--
*** 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 -->
The utility extrudeMesh fails to read a triSurface file, when I provide the case directory using the '-case' command line flag. The path to the triSurfaceFile is provided in the extrudeMeshDict as 'constant/triSurface/filename'.
Using a working directory which is the case directory, all is well. However, if I call extrudeMesh from the case's parent directory, and provide the case directory using the '-case' argument, the triSurface file can not be found.
Maybe, this is a bug of the VTK-file reader; and not of extrudeMesh itself. However, the unexpected behaviour of extrudeMesh described here is the symptom I encountered. The root-problem may be well something else.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Go to the 'overRhoSimpleFoam/hotCylinder' tutorial case.
Change to 'cylinderMesh', and call 'extrudeMesh' -> all is well
Go back up (call 'cd ..'), clear the case (call './Allclean'), and call 'extrudeMesh -case cylinderMesh' -> error: 'Cannot read file "constant/triSurface/cylinder.vtk"'
### Example case
<!--
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
-->
Use the 'overRhoSimpleFoam/hotCylinder' tutorial case.
### What is the current *bug* behaviour?
<!-- What actually happens -->
extrudeMesh fails to read the provided triSurface file, which is provided in extrudeMeshDict.
If I change the entry in the file extrudeMeshDict from 'constant/triSurface/cylinder.vtk' to 'cylinderMesh/constant/triSurface/cylinder.vtk', then extrudeMesh finds the file.
`Extruding surfaceMesh read from file "cylinderMesh/constant/triSurface/cylinder.vtk"`
### What is the expected *correct* behavior?
<!-- What you should see instead -->
I would expect extrudeMesh to take the path from extrudeMeshDict, i.e. 'constant/triSurface/cylinder.vtk', and form a path from the specified case directory.
The output of extrudeMesh lists the correct case directory:
`Case : /home/gerhard/OpenFOAM/OpenFOAM-v2006/tutorials/compressible/overRhoSimpleFoam/hotCylinder/cylinderMesh`
I would expect, that the path to the triSurface file is treated as a relative path, which is combined with the provided case directory.
### Relevant logs and/or images
```
gerhard@host:~/OpenFOAM/OpenFOAM-v2006/tutorials/compressible/overRhoSimpleFoam/hotCylinder$ ls
Allclean Allrun Allrun.pre cylinderAndBackground cylinderMesh
gerhard@host:~/OpenFOAM/OpenFOAM-v2006/tutorials/compressible/overRhoSimpleFoam/hotCylinder$ extrudeMesh -case cylinderMesh
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v2006 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : _b45f8f6f58-20200629 OPENFOAM=2006
Arch : "LSB;label=32;scalar=64"
Exec : extrudeMesh -case cylinderMesh
Date : Oct 20 2020
Time : 14:09:57
Host : host
PID : 20346
I/O : uncollated
Case : /home/gerhard/OpenFOAM/OpenFOAM-v2006/tutorials/compressible/overRhoSimpleFoam/hotCylinder/cylinderMesh
nProcs : 1
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 5, maxFileModificationPolls 20)
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Create mesh for time = 0
Selecting extrudeModel linearNormal
Selected extrudeModel for linearNormal using coeffs
{
thickness 0.7;
}
Extruding from surface using model linearNormal
Not collapsing any edges after extrusion
Extruding surfaceMesh read from file "constant/triSurface/cylinder.vtk"
--> FOAM FATAL ERROR:
Cannot read file "constant/triSurface/cylinder.vtk"
From bool Foam::fileFormats::VTKsurfaceFormat<Face>::read(const Foam::fileName&) [with Face = Foam::face]
in file surfaceFormats/vtk/VTKsurfaceFormat.C at line 98.
FOAM exiting
gerhard@host:~/OpenFOAM/OpenFOAM-v2006/tutorials/compressible/overRhoSimpleFoam/hotCylinder$
```
### 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 : 2006
- Operating system : Ubuntu-18.04
- Hardware info :
- Compiler : gcc
### 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/926Use vtm output for OpenFOAM to VTK translation2018-12-21T18:07:47ZMark OLESENUse vtm output for OpenFOAM to VTK translationThe current foamToVTK and vtkWrite (function object) write legacy files on a per-processor basis. This should be adjusted to use the vtm (multi-block) format that incorporates a vtu file for the internal mesh and vtp files for the bounda...The current foamToVTK and vtkWrite (function object) write legacy files on a per-processor basis. This should be adjusted to use the vtm (multi-block) format that incorporates a vtu file for the internal mesh and vtp files for the boundary patches.
The realization might entail collection on the master, or aggregates.
The output shall contain all relevant fields within each timestep file. v1812Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2946Use UPtrList for managing objective functions2023-12-21T11:54:41ZMark OLESENUse UPtrList for managing objective functionsStumbled across these when examining other code...
The incompressiblePrimalSolver uses a List of pointers for the objective functions. I think that a UPtrList would make more sense. The primary reason being to encapsulate the pointer de...Stumbled across these when examining other code...
The incompressiblePrimalSolver uses a List of pointers for the objective functions. I think that a UPtrList would make more sense. The primary reason being to encapsulate the pointer dereference, as well as other methods (eg, test(), get(), ...).
The code that may need to be modified in any case is the use of lookupClass. This is usually OK, but there is no absolute guarantee about the iteration order.
Here's a code snippet using `sorted` instead, which generates a UPtrList as an intermediate type (a couple of allocations fewer than sending back a HashTable).
```
Foam::UPtrList<Foam::objective>
Foam::incompressiblePrimalSolver::getObjectiveFunctions() const
{
DynamicList<objective*> objectives;
for (auto& adjoint : mesh_.sorted<adjointSolver>())
{
if (adjoint.primalSolverName() == solverName_)
{
PtrList<objective>& managerObjectives =
adjoint.getObjectiveManager().getObjectiveFunctions();
for (objective& obj : managerObjectives)
{
objectives.push_back(&obj);
}
}
}
return UPtrList<objective>(objectives);
}
```Vaggelis PapoutsisVaggelis Papoutsishttps://develop.openfoam.com/Development/openfoam/-/issues/1922User-coded BC for uniformFixedValue2021-12-03T15:42:55ZCarlos Peña-MonferrerUser-coded BC for uniformFixedValue`uniformFixedValue` allows options such as `table`, `tableFile`, `csvFile` or `polynomial`. Is there any supported way for accessing and manipulating these values from a user-coded BC like `codedFixedValue`?
Thank you.`uniformFixedValue` allows options such as `table`, `tableFile`, `csvFile` or `polynomial`. Is there any supported way for accessing and manipulating these values from a user-coded BC like `codedFixedValue`?
Thank you.Mark OLESENMark OLESEN