Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-03-13T13:31:17Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1373laserDTRM infinite loop2020-03-13T13:31:17ZAdminlaserDTRM infinite loop<!--
*** 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
<!-- Summarize the bug encountered concisely -->
A bug was encountered during the use of laserDTRM model in icoReactingMultiphaseInterFoam. When running in parallel, a particle or particles get stuck in the infinite loop at processor patches. The particle jumps from one CPU to another causing increase in the memory usage up to system overload and crash.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
run icoReactingMultiphaseInterFoam on multiple CPUs with beam crossing multiple processor patches. Time to crash shorter when surface of the absorption/reflection is of complex texture.
### 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
-->
unavailable
### What is the current *bug* behaviour?
<!-- What actually happens -->
simulation hangs during the cloud evolution / particles move. The job maintains CPU load up to the moment of memory overload.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The tracking of the particles stuck at patches should be abandoned after a few particle transactions between CPUs.
### Relevant logs and/or images
The bug doesn't produce error message - stuck at "moving particles ...." message.
<!--
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 :1812, 1906
- Operating system : ubuntu 18.04 LTS
- Hardware info : 2xEpyc7601, 1TB memory; also tested on Intel Xeon arch.
- 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
-->
Introduce transaction counter.
Issue similar to [3056 bug](https://bugs.openfoam.org/view.php?id=3056 )
solution from attached file works for OF.org:
[0001-particle-Added-logic-to-break-closed-loops.patch](/uploads/4572f30ce474e37c4296df9bdce3267a/0001-particle-Added-logic-to-break-closed-loops.patch)
\#\# Reattaching the author to the issue ticket: @dawid \#\#https://develop.openfoam.com/Development/openfoam/-/issues/1404correctBoundaryConditions documentation2020-03-13T13:30:55ZAdmincorrectBoundaryConditions documentationIt is difficult to know the correct usage of the GeometricField member function correctBoundaryConditions as the documentation is sparse. My understanding is that it should be called for a volume field if that field is not modified by a ...It is difficult to know the correct usage of the GeometricField member function correctBoundaryConditions as the documentation is sparse. My understanding is that it should be called for a volume field if that field is not modified by a call to a solve function but by other means such as an assignment statement. But my understanding may not be correct as I can see places in the OpenFOAM code where correctBoundaryConditions is not called despite volume variables being changed by assignments. For example, in the interPhaseChangeFoam
solver:
1) pEqn.H
near the end p_rgh is in some cases updated as
p_rgh = p - rho*gh;
2) alphaEqn.H
alpha1 is updated as
alpha1 = 0.5*alpha1 + 0.5*alpha10;
Some clarification of the correct usage of correctBoundaryConditions would be helpful. In particular, when it should be called and when not.
\## Reattaching the author to the issue ticket: @pacificesi ##Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1382provide config switch to NOT treat errors as exceptions with function objects2020-03-13T13:29:29ZMark OLESENprovide config switch to NOT treat errors as exceptions with function objects- apparently annoys people that the function objects are too forgiving.
We could provide a switch to let people chose to have errors, not exceptions when loading function objects- apparently annoys people that the function objects are too forgiving.
We could provide a switch to let people chose to have errors, not exceptions when loading function objectsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1386Lamb vector2020-03-13T13:28:56ZAdminLamb vectorWhen trying to compute the Lamb vector function object as suggested in the guide with:
postProcess -func lambVector
I receive the following error:
Cannot find functionObject file lambVector
Moreover, the tutorial suggested in the gui...When trying to compute the Lamb vector function object as suggested in the guide with:
postProcess -func lambVector
I receive the following error:
Cannot find functionObject file lambVector
Moreover, the tutorial suggested in the guide to test the Lamb vector does not exist in the path:
$FOAM_TUTORIALS/incompressible/pimpleFoam/LES/motorBike
\## Reattaching the author to the issue ticket: @Ricky\-11 ##Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1388Interpolation scheme for electric current / heat flux2020-03-13T13:20:48ZAdminInterpolation scheme for electric current / heat flux### Functionality to add/problem to solve
An electric current is calculated as
```math
J = \sigma\cdot\nabla\varphi.
```
The gradient of the electric potential can not be calculated using the Gauss theorem with LINEAR interpolation of...### Functionality to add/problem to solve
An electric current is calculated as
```math
J = \sigma\cdot\nabla\varphi.
```
The gradient of the electric potential can not be calculated using the Gauss theorem with LINEAR interpolation of the potential . A special interpolation scheme is necessary. As described below, the potential at the face needs to be weighted by the conductivity of both cells.
![gradient](/uploads/a3f4ad605e37e98d3d0c97aaae1c5002/gradient.png)
### Target audience
The mentioned interpolation scheme is necessary for computing the gradient of
* electric potential (i.e. electric current)
* temperature (i.e. heat flux)
### What does success look like, and how can we measure that?
I use the mentioned interpolation scheme for several years. It is already validated and published.
### Links / references
Weber, N.; Beckstein, P.; Galindo, V.; Starace, M.; Weier, T.: Electro-vortex flow simulation using coupled meshes, Computers and Fluids 168(2018) 101-109
It is Eqn. 16/17 in the [Arxiv version. ](https://arxiv.org/pdf/1707.06546.pdf)
### Funding
I can provide the source code.
\## Reattaching the author to the issue ticket: @dl6tud ##Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/1396AMI zone inside overset zone2020-03-13T13:18:56ZAdminAMI zone inside overset zone### Functionality to add/problem to solve
Is it possible to run an AMI zone within an overset mesh zone? My case involves a cycloidal propeller, in which five blades will rotate together as a single overset mesh zone, and then each sing...### Functionality to add/problem to solve
Is it possible to run an AMI zone within an overset mesh zone? My case involves a cycloidal propeller, in which five blades will rotate together as a single overset mesh zone, and then each single blade will independently vary its pitch as an embedded AMI within the enclosing overset mesh.
\## Reattaching the author to the issue ticket: @burgreen ##https://develop.openfoam.com/Development/openfoam/-/issues/1398Holes are detected in wrong places by the overset algorithm in ``twoSimpleRot...2020-03-13T13:18:30ZAdminHoles are detected in wrong places by the overset algorithm in ``twoSimpleRotors`` tutorial<!--
*** 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
The overset algorithm detects the wrong ``cellType``. Basically, it marks some cells as holes when the interpolated cells are near the wall.
### Steps to reproduce
Run the ``twoSimpleRotors`` tutorial for few time steps and visualize the ``cellType`` in paraview.
### 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
-->
Run the ``twoSimpleRotors`` there are no modifications needed to produce this issue.
### What is the current *bug* behaviour?
<!-- What actually happens -->
Holes are detected in wrong places which leads to zero velocity.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
It should be as shown in the [user guide](https://vimeo.com/223790883)
<figure class="video_container">
<iframe src="https://vimeo.com/223790883" frameborder="0" allowfullscreen="true"> </iframe>
</figure>
### 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.
-->
Here are a collection of six snapshots for ``cellType`` field and two for the velocity field;
* t1
![test1](/uploads/b9a856a0ec9c7ae2e9aa344dd65967af/test1.png)
* t2
![test2](/uploads/51b676d235e83d1b2408bbbf16554878/test2.png)
* t3
![test3](/uploads/5acea4afaac26fe6c6f84f95c13725cb/test3.png)
* t3, velocity field
![test3_U](/uploads/ef1e0494e59b8b4639e4c822bd4fc161/test3_U.png)
* t4
![test4](/uploads/f7e421478a1bfd85a0ed1179f5e9f105/test4.png)
* t5
![test5](/uploads/22ce12218f32cda2fd635eecab93d7bd/test5.png)
* t6
![test6](/uploads/556d2b871a61c616682bfb8bd6c477a8/test6.png)
* t6, velocity field
![test6_U](/uploads/10967ca1af7694e5edfff0f7b9bf7efa/test6_U.png)
### 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 : v1906
- Operating system : ubuntu 18.04LTS WSL on Win10
- 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
-->
I'm not sure but it seems that this issue didn't exist for the version you used to produce the video attached above.
## Reattaching the author to the issue ticket: @hikassem ##https://develop.openfoam.com/Development/openfoam/-/issues/1408Decoupling between the ``background mesh`` and ``front mesh`` if there is no ...2020-03-13T13:17:39ZAdminDecoupling between the ``background mesh`` and ``front mesh`` if there is no hole present [overset]<!--
*** 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
<!-- Summarize the bug encountered concisely -->
I'm sorry for reporting again about ``overset`` but it happens that I'm running few tests nowadays.
The algorithm doesn't set any ``interpolated`` cells on the background mesh when there is no ``holes`` in the model.
This leads to complete decoupling between the ``background mesh`` and ``front mesh``.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Since there is not geometry needed, simple empty overlapping meshes of any type or shape can reproduce this issue.
In order to see the issue clearly, I would suggest selecting actuation disk on the ``front mesh`` or the front and back together.
By inspecting the case in ``paraview``, you will not found any interpolated cells on the background mesh. Also, both velocity and pressure fields on the background mesh are disturbed by the disk (of course in case, the disk is selected from the front mesh cells only). Using ``overSimpleFoam`` is enough to see this behavior.
### 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
-->
![wakeInside](/uploads/0322e6124579bf0f5ed67ab6edc737ba/wakeInside.png)
### 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 : v1906, commit 506990e079af
- Operating system : Ubuntu 18.04LTS
- 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
-->
If this feature is not supported, maybe just through a warning or fatal error would be enough for the user to understand the limitation of the method.
A solution for this issue could be by selecting few layers inwards around the ``oversetPatch`` to ensure the coupling. Or just marking few cells in the background as a hole before adding the interpolation layers. Probably, it is more trick than that specially if the front mesh is moving.
\## Reattaching the author to the issue ticket: @hikassem ##https://develop.openfoam.com/Development/openfoam/-/issues/1409reactingMultiphaseEulerFoam crashes when one field is initially patched with ...2020-03-13T13:17:15ZAdminreactingMultiphaseEulerFoam crashes when one field is initially patched with 0 phase fraction<!--
*** 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
ReactingMultiPhaseEulerFoam crashes when one of the fields is initially patched with 0 phase fraction.
### Steps to reproduce
Please unpack and simply run the attached scripts. Allrun1 replicates the first behavior and Allrun2, the second. Please see below for a description of the behaviors.
### Example case
Attached is a simple two-phase test case (air and water) of a gas-stirred cylindrical tank initially half filled with water and air is injected through a small nozzle on the centre of the bottom patch.
### What is the current *bug* behaviour?
(1) When one of the fields is initially patched with 0 alpha, reactingMultiphaseEulerFoam crashes after the first pimple iteration while going to turbulence object. This behavior is replicated with Allrun1 script.
(2) If we put a small positive value (0.001) instead of 0, the solver runs stable for a few iterations and crashes eventually. This behavior is replicated with Allrun2 script.
### What is the expected *correct* behavior?
The solver should run stably in both cases.
### Relevant logs and/or images
### 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 : v-1906
- Operating system : Ubuntu 16.04 LTS[gasStirredTank.tar.gz](/uploads/85c7bcf5caa8f06ff3b5a811c7fc12e4/gasStirredTank.tar.gz)
- Hardware info :
- Compiler : gcc
### Possible fixes
\## Reattaching the author to the issue ticket: @kpishar ##https://develop.openfoam.com/Development/openfoam/-/issues/1436porousSimpleFoam - straightDuctImplicit tutorial fails at mesh generation2020-03-13T13:14:43ZAdminporousSimpleFoam - straightDuctImplicit tutorial fails at mesh generationThe docker image does not have the foamyHexMesh application inside the $FOAM_APPBIN directory. I am assuming it is not compiled since the source directory already have the source files in it.
\## Reattaching the author to the issue tick...The docker image does not have the foamyHexMesh application inside the $FOAM_APPBIN directory. I am assuming it is not compiled since the source directory already have the source files in it.
\## Reattaching the author to the issue ticket: @orcun.kozaka ##https://develop.openfoam.com/Development/openfoam/-/issues/1445courant number calculation and setDeltaT before mesh.update() in solvers2020-03-13T13:14:18ZAdmincourant number calculation and setDeltaT before mesh.update() in solversIn several dynamic mesh enabled solvers, Courant number calculation and setDeltaT happen before mesh.update().
It doesn't make sense to me, specially in adaptive mesh refinement (AMR) cases. In such cases, after mesh.update(), the pre-c...In several dynamic mesh enabled solvers, Courant number calculation and setDeltaT happen before mesh.update().
It doesn't make sense to me, specially in adaptive mesh refinement (AMR) cases. In such cases, after mesh.update(), the pre-calculated courant number is invalidated.
In my experience, every AMR case have failed due to sudden increase of courant number. I had to move mesh.update() prior to "include CourantNo.H" for the case to successfully run
\## Reattaching the author to the issue ticket: @maksjood ##https://develop.openfoam.com/Development/openfoam/-/issues/1460snappyHexMesh castellation phase continues refining upon multiple runs2020-03-13T13:12:50ZAdminsnappyHexMesh castellation phase continues refining upon multiple runs### Summary
Hello,
I'm not sure if this is a bug, but it is at least behavior I didn't expect.
I have some models where I'm attempting to refine parts of a blockMesh multiple times using the castellation phase of snappyHexMesh and s...### Summary
Hello,
I'm not sure if this is a bug, but it is at least behavior I didn't expect.
I have some models where I'm attempting to refine parts of a blockMesh multiple times using the castellation phase of snappyHexMesh and some geometry. I've noticed that if I run the castellation phase multiple times in a row (no changes to snappyHexMeshDict), snappy will continue finding and refining internal cells during the shell refinement phase. Upon continued runs, eventually the internal cells it finds to refine dwindles and it no longer performs refinement.
Why is additional refinement found during subsequent runs with no change in settings? I don't know if snappy was meant to be run in this way, but I was hoping to be able to do some upfront proximity refinement on certain surfaces before including all geometry to mesh and snap.
### Steps to reproduce
This can reproduced on the snappyHexMesh flange tutorial. Disable snapping in the snappyHexMeshDict. Run the allrun script, note how many cells are in the mesh, then manually run the `snappyHexMesh -overwrite` command again. You'll see that snappy found 2 extra cells to refine. Any additional runs do not refine anything further, which is what I expected to happen the first time.
I have some models though that go through multiple iterations of the above, the tutorial is just an easy example.
### Example case
snappyHexMesh flange tutorial
### What is the current *bug* behaviour?
snappy finds additional cells to refine during the castellation phase when run multiple times in a row.
### What is the expected *correct* behavior?
snappy shouldn't find additional cells to refine during the castellation phase when run multiple times in a row.
### Relevant logs and/or images
```
Shell refinement iteration 0
----------------------------
Marked for refinement due to distance to explicit features : 0 cells.
Marked for refinement due to refinement shells : 0 cells.
Determined cells to refine in = 0.12 s
Selected for internal refinement : 2 cells (out of 19314)
Edge intersection testing:
Number of edges : 66888
Number of edges to retest : 216
Number of intersected edges : 12407
Refined mesh in = 0.04 s
After refinement shell refinement iteration 0 : cells:19328 faces:66888 points:28292
Cells per refinement level:
0 0
1 1180
2 17072
3 107
```
### Environment information
- OpenFOAM version : v1906
- Operating system : RHEL
- Compiler : gcc
\## Reattaching the author to the issue ticket: @graups ##https://develop.openfoam.com/Development/openfoam/-/issues/1478No Fields converted with "ensightWrite" FO with region different than region02020-03-13T13:11:24ZAdminNo Fields converted with "ensightWrite" FO with region different than region0*In my process:*
1- I am mapping a VolScalarField (the pressure "p") from region0 on a targetMesh (coarser than region0) on the fly using the "mapFields" FO as:
meshInterp1
{
type mapFields;
libs ...*In my process:*
1- I am mapping a VolScalarField (the pressure "p") from region0 on a targetMesh (coarser than region0) on the fly using the "mapFields" FO as:
meshInterp1
{
type mapFields;
libs ("libfieldFunctionObjects.so");
writeControl timeStep;
writeInterval 1;
mapRegion targetMesh;
mapMethod cellVolumeWeight;
consistent no;
fields (p);
patchMap ();
cuttingPatches (CONTOUR GAMMA_S GAMMA_E);
}
* Then:*
2- I want to use the "ensightWrite" FO on the fly during the execution to convert the pressure field from the OpenFOAM format to the Ensight one as:
ensightWrite_P
{
type ensightWrite;
libs ("libutilityFunctionObjects.so");
writeControl timeStep;
writeInterval 1;
format binary;
directory "postProcessing/EnSight/";
nodeValues yes;
fields ( p );
region targetMesh;
overwrite true;
}
It seems the fields is not converted, only the mesh is present in the Ensigth directory but no fields data:
PIMPLE: iteration 1
smoothSolver: Solving for Ux, Initial residual = 1, Final residual = 5.60474e-06, No Iterations 6
smoothSolver: Solving for Uy, Initial residual = 1, Final residual = 5.1773e-06, No Iterations 5
GAMG: Solving for p, Initial residual = 1, Final residual = 0.00404502, No Iterations 4
time step continuity errors : sum local = 0.00019636, global = -5.23346e-05, cumulative = -5.23346e-05
GAMG: Solving for p, Initial residual = 0.00782886, Final residual = 7.54917e-08, No Iterations 10
time step continuity errors : sum local = 2.98405e-07, global = 3.4694e-08, cumulative = -5.22999e-05
smoothSolver: Solving for epsilon, Initial residual = 0.0426054, Final residual = 7.6249e-06, No Iterations 6
smoothSolver: Solving for k, Initial residual = 1, Final residual = 7.86417e-06, No Iterations 10
ExecutionTime = 0.41 s ClockTime = 1 s
mapFields mapFields write:
p: interpolated and written
ensightWrite ensightWrite write: ( )
but it seems working when I want to field on the "region0" as
ensightWrite_P
{
type ensightWrite;
libs ("libutilityFunctionObjects.so");
writeControl timeStep;
writeInterval 1;
format binary;
directory "postProcessing/EnSight/";
nodeValues yes;
fields ( p );
// region targetMesh;
overwrite true;
}
it gives:
PIMPLE: iteration 1
smoothSolver: Solving for Ux, Initial residual[pitzDailyFO_ensightWrite_Issue.tar.gz](/uploads/a7fa8c9fce78c6653e3f737c39858538/pitzDailyFO_ensightWrite_Issue.tar.gz) = 0.979549, Final residual = 6.32759e-06, No Iterations 11
smoothSolver: Solving for Uy, Initial residual = 0.663667, Final residual = 3.98739e-06, No Iterations 11
GAMG: Solving for p, Initial residual = 0.0514127, Final residual = 0.000190129, No Iterations 4
time step continuity errors : sum local = 0.0001831, global = 4.22034e-05, cumulative = -1.00965e-05
GAMG: Solving for p, Initial residual = 0.013377, Final residual = 5.64195e-08, No Iterations 11
time step continuity errors : sum local = 1.58111e-07, global = -1.82685e-08, cumulative = -1.01148e-05
smoothSolver: Solving for epsilon, Initial residual = 0.0120984, Final residual = 5.31586e-06, No Iterations 5
smoothSolver: Solving for k, Initial residual = 0.359881, Final residual = 3.64655e-06, No Iterations 9
ExecutionTime = 0.45 s ClockTime = 1 s
mapFields mapFields write:
p: interpolated and written
ensightWrite ensightWrite write: ( p )
End
It seems there is a problem with "region" argument in the "ensightWrite" FO
[pitzDailyFO_ensightWrite_Issue.tar.gz](/uploads/04a4b6fdfea001f927059fcff428328c/pitzDailyFO_ensightWrite_Issue.tar.gz)
\## Reattaching the author to the issue ticket: @nicolas.zerbib ##https://develop.openfoam.com/Development/openfoam/-/issues/1487I can't compile my own solver: illegal instruction constexpr v19062020-03-13T13:10:15ZAdminI can't compile my own solver: illegal instruction constexpr v1906Hi everyone, I'm trying to compile my own solver in Windows 10, Ubuntu 18.04 but i can't.
The error is " illegal instruction constexpr..."
I've seeing this post: https://develop.openfoam.com/Development/OpenFOAM-plus/issues/938
and when...Hi everyone, I'm trying to compile my own solver in Windows 10, Ubuntu 18.04 but i can't.
The error is " illegal instruction constexpr..."
I've seeing this post: https://develop.openfoam.com/Development/OpenFOAM-plus/issues/938
and when I modify the etc/bashrc file:
# [WM_COMPILER_TYPE] - Compiler location:
# = system | ThirdParty
export WM_COMPILER_TYPE=system
# [WM_COMPILER] - Compiler:
# = Gcc | Gcc4[8-9] | Gcc5[1-5] | Gcc6[1-5] | Gcc7[1-4] | Gcc8[12] |
# Clang | Clang3[7-9] | Clang[4-6]0 | Icc | Cray | Arm | Pgi
export WM_COMPILER=Gcc
(or export WM_COMPILER=Gcc74)
the ubuntu shell says "No completion added for /opt/OpenFOAM/OpenFOAM-v1906/platforms/linux64Gcc73DPInt32Opt/bin
... incorrect platform, or not yet compiled?"
What should I do to fix this?
Thanks,
\## Reattaching the author to the issue ticket: @RoderickZ ##https://develop.openfoam.com/Development/openfoam/-/issues/1620nearWallFields function object fails2020-03-13T12:44:54ZMatej FormannearWallFields function object failsnearWallFiedls (version 1912) fails and particular geometry reporting error message:
```
--> FOAM FATAL ERROR:
object of type N4Foam14PatchFunction1INS_6VectorIdEEEE is unallocated
From function T* Foam::autoPtr<T>::operator->() [w...nearWallFiedls (version 1912) fails and particular geometry reporting error message:
```
--> FOAM FATAL ERROR:
object of type N4Foam14PatchFunction1INS_6VectorIdEEEE is unallocated
From function T* Foam::autoPtr<T>::operator->() [with T = Foam::PatchFunction1<Foam::Vector<double> >]
in file /scratch/pss/2010560/OpenFOAM/OpenFOAM.master.int32DP/src/OpenFOAM/lnInclude/autoPtrI.H at line 222.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libOpenFOAM.so
#1 Foam::error::abort() in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libOpenFOAM.so
#2 Foam::uniformFixedValueFvPatchField<Foam::Vector<double> >::write(Foam::Ostream&) const in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libfiniteVolume.so
#3 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::Boundary::writeEntries(Foam::Ostream&) const in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/bin/simpleFoam
#4 Foam::Ostream& Foam::operator<< <Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>(Foam::Ostream&, Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&) in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/bin/simpleFoam
#5 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::writeData(Foam::Ostream&) const in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/bin/simpleFoam
#6 Foam::fileOperation::writeObject(Foam::regIOobject const&, Foam::IOstreamOption::streamFormat, Foam::IOstreamOption::versionNumber, Foam::IOstreamOption::compressionType, bool) const in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libOpenFOAM.so
#7 Foam::regIOobject::writeObject(Foam::IOstreamOption::streamFormat, Foam::IOstreamOption::versionNumber, Foam::IOstreamOption::compressionType, bool) const in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libOpenFOAM.so
#8 Foam::functionObjects::nearWallFields::write() in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libfieldFunctionObjects.so
#9 Foam::functionObjects::timeControl::write() in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libOpenFOAM.so
#10 Foam::functionObjectList::execute() in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/lib/libOpenFOAM.so
#11 ? in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/bin/simpleFoam
#12 __libc_start_main in /lib64/libc.so.6
#13 ? in /nisprod/openfoam/release/latest/OpenFOAM-v1912/platforms/linux64Gcc48DPInt32Opt/bin/simpleFoam
```
Apparently fails only with velocity (vector) and runs ok on e.g. pressure field.
checkMesh does not report any unusual error on a mesh coming from SHM.https://develop.openfoam.com/Development/openfoam/-/issues/1587#include directive not working in snappyHexMeshDict with collated file handler2020-03-12T10:38:47ZMortesins#include directive not working in snappyHexMeshDict with collated file handler<!--
*** 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
The #include directive does not work properly inside snappyHexMeshDict when running with the collated file handler. It throws the following error:
```
[1] --> FOAM FATAL ERROR:
[1] Not implemented
[1]
[1] From function virtual Foam::Istream& Foam::ITstream::readRaw(char*, std::streamsize)
[1] in file db/IOstreams/Tstreams/ITstream.C at line 344.
```
### Steps to reproduce
1) Starting from the motorbike tutorial, move the refinementSurfaces settings to an external file. So the snappyHexMeshDict will look like this:
```
refinementSurfaces
{
#include "motorBikeRefinementDict"
}
```
and a new file called motorBikeRefinementDict should contain the following:
```
motorBike
{
// Surface-wise min and max refinement level
level (5 6);
// Optional specification of patch type (default is wall). No
// constraint types (cyclic, symmetry) etc. are allowed.
patchInfo
{
type wall;
inGroups (motorBikeGroup);
}
}
```
2) Change the file handler to be collated. NOTE: there is no issue with the uncollated format.
### Example case
I've attached:
[snappyHexMeshDict](/uploads/aae5cbd4178b3b0b076b4c285ccd861e/snappyHexMeshDict)
[motorBikeRefinementDict](/uploads/bc4dd73eba353d2d54bbe59faa5eae4f/motorBikeRefinementDict)
[controlDict](/uploads/787b9b9bbd556a2bc335126f5861187c/controlDict)
### What is the current *bug* behaviour?
Snappy crashes.
### What is the expected *correct* behavior?
The #include directive should be correctly parsed.
### Relevant logs and/or images
```
Create time
Overriding OptimisationSwitches according to controlDict
fileHandler (unregistered)
Overriding fileHandler to collated
I/O : collated (maxThreadFileBufferSize 0)
Threading not activated since maxThreadFileBufferSize = 0.
Writing may run slowly for large file sizes.
Create mesh for time = 0
Read mesh in = 0 s
Overall mesh bounding box : (-5 -4 0) (15 4 8)
Relative tolerance : 1e-06
Absolute matching distance : 2.29783e-05
[1]
[1]
[1] --> FOAM FATAL ERROR:
[1] Not implemented
[1]
[1] From function virtual Foam::Istream& Foam::ITstream::readRaw(char*, std::streamsize)
[1] in file db/IOstreams/Tstreams/ITstream.C at line 344.
[1]
FOAM parallel run aborting
[1]
[1] #0 Foam::error::printStack(Foam::Ostream&)Reading refinement surfaces.
Read refinement surfaces in = 0.33 s
Reading refinement shells.
Refinement level 4 for all cells inside refinementBox
Read refinement shells in = 0 s
Setting refinement level of surface to be consistent with shells.
at ??:?
[1] #1 Foam::error::abort() at ??:?
[1] #2 Foam::ITstream::readRaw(char*, long) at ??:?
[1] #3 Foam::readRawLabel(Foam::Istream&, int*, unsigned long) at ??:?
[1] #4 Foam::Istream& Foam::operator>><int, 2u>(Foam::Istream&, Foam::FixedList<int, 2u>&) at ??:?
[1] #5 Foam::refinementSurfaces::refinementSurfaces(Foam::searchableSurfaces const&, Foam::dictionary const&, int, bool) at ??:?
[1] #6 ? at ??:?
[1] #7 __libc_start_main in /lib64/libc.so.6
[1] #8 ? at ??:?
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 1 in communicator MPI_COMM_WORLD
with errorcode 1.
NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
```
### 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 : CentOS Linux 7
* Compiler : Gcc 4.8.5Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1629ensight parallel conversion of lagrangian fields incorrect2020-03-12T10:38:47ZMark OLESENensight parallel conversion of lagrangian fields incorrect- cross-reference EP#1207
Affects 1812, 1906, 1912- cross-reference EP#1207
Affects 1812, 1906, 1912Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1608weird error in codes when building v1912 with intel icc2020-03-12T10:38:47ZRamon Yipweird error in codes when building v1912 with intel icc<!--
*** 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'm new to OpenFOAM and I'm trying to compile OpenFOAM-v1912 using Icc and IntelMPI, only to find the following confusing error. It seems like an error in codes. But it just makes no sense, because I have successfully compiled it with gcc(v4.8.5) and openmpi(1.10.7), *and it worked just fine*. THANKS A LOT for helping. I'd be more than delighted to hear any suggestions. Ideas about what the problem might be will also be of great help.
> wallBoundedStreamLine/wallBoundedParticleTemplates.C(121): error: no operator "==" matches these operands
### Steps to reproduce
I edited OpenFOAM-v1912/etc/bashrc from
```
...
export WM_COMPILER=Gcc
...
export WM_MPLIB=OPENMPI
...
```
to
```
...
export WM_COMPILER=Icc
...
export WM_MPLIB=INTELMPI
...
```
and I got "ld: cannot find -lmpi" error so I edit OpenFOAM-v1912/wmake/rules/General/Icc/c++
```
CC = icpc -std=c++11
```
to
```
CC = mpiicc -std=c++11
```
then under directory OpenFOAM-v1912/ , I ran
```
./Allwmake -j16
```
Details of the error from the promts:
```
wmake reactingEulerFoam/phaseSystems
wmake reactingEulerFoam/interfacialModels
wmake reactingEulerFoam/interfacialCompositionModels
wmake reactingEulerFoam/derivedFvPatchFields
wmake reactingEulerFoam/reactingMultiphaseEulerFoam/multiphaseSystem
wmake reactingEulerFoam/reactingMultiphaseEulerFoam/multiphaseCompressibleTurbulenceModels
wmake reactingEulerFoam/reactingTwoPhaseEulerFoam/twoPhaseSystem
wmake reactingEulerFoam/reactingTwoPhaseEulerFoam/twoPhaseCompressibleTurbulenceModels
wmake field
mpiicc -std=c++11 -fp-trap=common -fp-model precise -DOPENFOAM=1912 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-unknown-pragmas -diag-disable 327,654,1125,1292,2289,2304,11062,11074,11076 -O3 -DNoRepository -ftemplate-depth-100 -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/finiteVolume/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/fileFormats/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/surfMesh/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/meshTools/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/sampling/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/lagrangian/basic/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/lagrangian/distributionModels/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/thermophysicalModels/basic/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/transportModels -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/transportModels/compressible/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/TurbulenceModels/turbulenceModels/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/TurbulenceModels/incompressible/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/TurbulenceModels/compressible/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/transportModels/compressible/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/thermophysicalModels/basic/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/thermophysicalModels/solidThermo/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/thermophysicalModels/chemistryModel/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/thermophysicalModels/reactionThermo/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/thermophysicalModels/specie/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/fvAgglomerationMethods/pairPatchAgglomeration/lnInclude -IlnInclude -I. -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/OpenFOAM/lnInclude -I/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/OSspecific/POSIX/lnInclude -fPIC -c wallBoundedStreamLine/wallBoundedStreamLine.C -o /share/software/OpenFOAM/OpenFOAM-v1912-ICC/build/linux64IccDPInt32Opt/src/functionObjects/field/wallBoundedStreamLine/wallBoundedStreamLine.o
wallBoundedStreamLine/wallBoundedParticleTemplates.C(121): error: no operator "==" matches these operands
operand types are: Foam::cell == const Foam::label
cell() == mesh().faceOwner()[face()]
^
/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/lagrangian/basic/lnInclude/particle.H(70): note: this candidate was rejected because arguments do not match
bool operator==(const particle&, const particle&);
^
/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/OpenFOAM/lnInclude/labelBits.H(123): note: this candidate was rejected because function is not visible
inline friend bool operator==(const labelBits& a, const labelBits& b)
^
/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/OpenFOAM/lnInclude/objectMapI.H(85): note: this candidate was rejected because arguments do not match
inline bool Foam::operator==(const objectMap& a, const objectMap& b)
^
/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/OpenFOAM/lnInclude/triFaceI.H(406): note: this candidate was rejected because arguments do not match
inline bool Foam::operator==(const triFace& a, const triFace& b)
^
(followed by lots of rejected candidates)
instantiation of "bool Foam::wallBoundedStreamLineParticle::move(TrackCloudType &, Foam::wallBoundedStreamLineParticle::trackingData &, Foam::scalar={Foam::doubleScalar={double}}) [with TrackCloudType=Foam::wallBoundedStreamLineParticleCloud]" at line 212 of "/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/lagrangian/basic/lnInclude/Cloud.C"
instantiation of "void Foam::Cloud<ParticleType>::move(TrackCloudType &, ParticleType::trackingData &, Foam::scalar={Foam::doubleScalar={double}}) [with ParticleType=Foam::wallBoundedStreamLineParticle, TrackCloudType=Foam::wallBoundedStreamLineParticleCloud]" at line 275 of "wallBoundedStreamLine/wallBoundedStreamLine.C"
wallBoundedStreamLine/wallBoundedParticleTemplates.C(138): error: no operator "=" matches these operands
operand types are: Foam::cell = Foam::label
cell() = nbrCelli;
^
detected during:
instantiation of "bool Foam::wallBoundedStreamLineParticle::move(TrackCloudType &, Foam::wallBoundedStreamLineParticle::trackingData &, Foam::scalar={Foam::doubleScalar={double}}) [with TrackCloudType=Foam::wallBoundedStreamLineParticleCloud]" at line 212 of "/share/software/OpenFOAM/OpenFOAM-v1912-ICC/src/lagrangian/basic/lnInclude/Cloud.C"
instantiation of "void Foam::Cloud<ParticleType>::move(TrackCloudType &, ParticleType::trackingData &, Foam::scalar={Foam::doubleScalar={double}}) [with ParticleType=Foam::wallBoundedStreamLineParticle, TrackCloudType=Foam::wallBoundedStreamLineParticleCloud]" at line 275 of "wallBoundedStreamLine/wallBoundedStreamLine.C"
compilation aborted for wallBoundedStreamLine/wallBoundedStreamLine.C (code 2)
make: *** [/share/software/OpenFOAM/OpenFOAM-v1912-ICC/build/linux64IccDPInt32Opt/src/functionObjects/field/wallBoundedStreamLine/wallBoundedStreamLine.o] Error 2
```
### 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: v1912 (codes from https://sourceforge.net/projects/openfoam/files/v1912/OpenFOAM-v1912.tgz)
- ThirdParty from https://sourceforge.net/projects/openfoam/files/v1912/ThirdParty-v1912.tgz
- Intel suite: parallel_studio_xe_2020_cluster_edition
- Intel icc: icc (ICC) 19.1.0.166 20191121
- Intel MPI lib: for Linux* OS, Version 2019 Update 6 Build 20191024
- OS Kernel: Linux version 3.10.0-1062.el7.x86_64 (gcc version 4.8.5 20150623 (Red Hat 4.8.5-36) (GCC) )
- OS: CentOS 7.7.1908
- CPU: 72 * Intel(R) Xeon(R) Gold 6240 CPU @ 2.60GHzhttps://develop.openfoam.com/Development/openfoam/-/issues/1588foamListTimes -processor -rm does not work for collated format2020-03-12T10:38:47ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamListTimes -processor -rm does not work for collated format### Functionality to add/problem to solve
`foamListTimes -processor` shows the current time directories. It also works with `-fileHandler collated`. However the additional `-rm` option does not delete the time directories.### Functionality to add/problem to solve
`foamListTimes -processor` shows the current time directories. It also works with `-fileHandler collated`. However the additional `-rm` option does not delete the time directories.https://develop.openfoam.com/Development/openfoam/-/issues/1613wallHeatFlux function object write frequency field/statistics2020-03-12T08:19:45ZRiccardo RossiwallHeatFlux function object write frequency field/statisticsWhen using the wallHeatFlux function object, the entire field is written to disk at the same frequency of calculated min, max and averaged values, leading to a large amount of space used on disk.
Is it possible to have the wallHeatFlux ...When using the wallHeatFlux function object, the entire field is written to disk at the same frequency of calculated min, max and averaged values, leading to a large amount of space used on disk.
Is it possible to have the wallHeatFlux written to time data in the main folder (not in postprocessing) only with the chosen frequency from the main writeInterval in the simulation and a separate frequency for the statistics (columns file)?