Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-12-23T09:30:56Zhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/58build optimized version of PETSc by default?2020-12-23T09:30:56Zstefano zampinibuild optimized version of PETSc by default?Currently, https://develop.openfoam.com/Development/ThirdParty-common/-/blob/master/makePETSC configures PETSc in debug mode.
We should add `--with-debugging=0` unless some openFOAM debug build variable is on. PETSc will be up to 10x fas...Currently, https://develop.openfoam.com/Development/ThirdParty-common/-/blob/master/makePETSC configures PETSc in debug mode.
We should add `--with-debugging=0` unless some openFOAM debug build variable is on. PETSc will be up to 10x faster in non-debug mode. @mark ?Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1968interfaceTrackingFvMesh does not implement two-step constructor2020-12-22T15:06:52ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.cominterfaceTrackingFvMesh does not implement two-step constructor<!--
*** 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 -->
Unallocated motionSolver in interfaceTrackingFvMesh
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
run
incompressible/pimpleFoam/laminar/contactAngleCavity
### What is the current *bug* behaviour?
<!-- What actually happens -->
log.pimpleFoam: unallocated autoPtr of type N4Foam12motionSolverE
### 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 : develop
@Prashant @andyMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1687Linear algebra profiling in standard output2020-12-22T08:04:18ZSimone BnaLinear algebra profiling in standard outputHi,
after a discussion with @mark and Ivan Spisso @ivanspisso (chairman of the HPC technical committee), we think it can be useful for a user to see in the output some more information about the execution time of each preconditioner/s...Hi,
after a discussion with @mark and Ivan Spisso @ivanspisso (chairman of the HPC technical committee), we think it can be useful for a user to see in the output some more information about the execution time of each preconditioner/solver pair of the PISO/PIMPLE/SIMPLE loop and not only its total execution. This solution would show if there are rooms for improvements by changing the solver/preconditioner or tuning its parameters.
What I propose is something like this:
Time = 0.000625
Courant Number mean: 0.0135897 max: 0.241523
DILUPBiCGStab: Solving for Ux, Initial residual = 0.012631, Final residual = 0.00040317, No Iterations 5, Preconditioner time = 0.02 s, Solver time = 1.23 s
DILUPBiCGStab: Solving for Uy, Initial residual = 0.0295468, Final residual = 0.00096396, No Iterations 5, Preconditioner time = 0.02 s, Solver time = 1.25 s
DILUPBiCGStab: Solving for Uz, Initial residual = 0.109576, Final residual = 0.00700867, No Iterations 5, Preconditioner time = 0.02 s, Solver time = 1.24 s
petsc-cg: Solving for p, Initial residual = 0.538072, Final residual = 9.9628e-05, No Iterations 1164, Preconditioner time = 0.14 s, Solver time = 1.76 s
time step continuity errors : sum local = 8.47465e-10, global = -8.77385e-24, cumulative = -2.99506e-21
petsc-cg: Solving for p, Initial residual = 0.49318, Final residual = 9.97012e-05, No Iterations 1161, Preconditioner time = 0.13 s, Solver time = 2.24 s
time step continuity errors : sum local = 8.44322e-10, global = -2.7257e-22, cumulative = -3.26763e-21
ExecutionTime = 455.77 s ClockTime = 470 s
The idea is to add to each solver line, after the number of iterations, the time spent in the preconditioner and in the solver.
Since this solution has a higher overhead and has an impact on the standard output log, it can be "activated" optionally by the user.
I think that the profiling already implemented in OpenFOAM is more suited for a developer than a user, and it is not possible to see how much time is spent in each linear algebra solver. From the implementation point of view, Mark suggested to add two ClockTime values to the SolverPerformance class.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1917adjust Sine Function12020-12-22T07:59:46ZMark OLESENadjust Sine Function1The `sine` Function1 currently takes `frequency` as cycles per second, and thus multiplies by 2 PI. For some times cycles (eg, seasonal variations), this is quite unnatural.
- propose supporting `frequency` or `period`, where period is ...The `sine` Function1 currently takes `frequency` as cycles per second, and thus multiplies by 2 PI. For some times cycles (eg, seasonal variations), this is quite unnatural.
- propose supporting `frequency` or `period`, where period is in seconds.
- ~~potentially useful to add an optional phase shift, for cases where a time shift may be less appropriate.~~
- clip min/max limits. Eg ensures we maintain min levels
@orgogozov2012Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1950better resolution of distance surface edges2020-12-22T07:59:28ZMark OLESENbetter resolution of distance surface edgesAs noted in EP1041 the known issues with _ragged_ edges when using distanceSurface for sampling have an interesting side effect of penetrating through obstacles as well. In the given example it was with a thin walled pipe.As noted in EP1041 the known issues with _ragged_ edges when using distanceSurface for sampling have an interesting side effect of penetrating through obstacles as well. In the given example it was with a thin walled pipe.v2012Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1924support limits on Function12020-12-22T07:59:15ZMark OLESENsupport limits on Function1As mentioned in #1917 and EP1364, it can sometimes be useful to limit either the values created by a Function1, or clamp the time range when evaluating it.As mentioned in #1917 and EP1364, it can sometimes be useful to limit either the values created by a Function1, or clamp the time range when evaluating it.v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1962setAlphaField crashes boundary condition related2020-12-21T19:21:45ZStephansetAlphaField crashes boundary condition related### Summary
setAlphaField crashes if used in combination with the inletOutlet boundary condition. Most likely also with others, but these are really common for alpha fields. This error does not exist in the v1812 and was hence introduce...### Summary
setAlphaField crashes if used in combination with the inletOutlet boundary condition. Most likely also with others, but these are really common for alpha fields. This error does not exist in the v1812 and was hence introduced by some change. Tested in v2006
### Steps to reproduce
Change one of the boundary conditions to inletOutlet
`Reading field alpha.water
--> FOAM FATAL ERROR:
request for surfaceScalarField phi from objectRegistry region0 failed
available objects of type surfaceScalarField are
1(mag(delta))
From const Type& Foam::objectRegistry::lookupObject(const Foam::word&, bool) const [with Type = Foam::GeometricField<double, Foam::fvsPatchField, Foam::surfaceMesh>]
in file /home/bloerb/OpenFOAM/OpenFOAM-v2006/src/OpenFOAM/lnInclude/objectRegistryTemplates.C at line 463.
FOAM aborting
`Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1965Attempt to cast type zeroGradient to type nutWallFunction2020-12-21T14:15:42ZRichard LoveAttempt to cast type zeroGradient to type nutWallFunction<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
When trying to simulate turbulent flow over open terrain using a k-epsilon model and RAS turbulence with inlet and outlet as type patch, the solver begins to solve for ux, uy, uz and it then fails with the warning 'FOAM FATAL ERROR:
Attempt to cast type zeroGradient to type nutWallFunction
However when the patch types in constant are changed to wall, the solution begins to run. As I am trying to simulate turbulent flow over terrain, these patch types are not suitable
![SimulationFail](/uploads/89dff3d7c72be324041e1528d3403596/SimulationFail.png)
If there is any more information you require, please get in touch at love-r3@ulster.ac.uk
### Steps to reproduce
The boundary file setup is seen at this link https://www.cfd-online.com/Forums/openfoam-solving/232526-attempt-cast-type-zerogradient-type-nutwallfunction.html.
It is being simulated through a simple cuboid blockMesh with an STL file connected via snappyHexMesh, however it does not run, even without the STL
[blockMeshDict](/uploads/c54f08fb6b054b745534c1d24765669d/blockMeshDict)
[fvSchemes](/uploads/bfb95abd1186f0eed24e22fc08c634bb/fvSchemes)
[fvSolution](/uploads/70590e40f1c178ddc7e3d73271465095/fvSolution)
[controlDict](/uploads/d187d57856b4434bc44876caba6e54b7/controlDict)[turbulenceProperties](/uploads/ace56000d2f453002e6c84d7d0060e02/turbulenceProperties)
[transportProperties](/uploads/8322db7b9ce95ed211e41a7053d4bf7d/transportProperties)
[RASProperties](/uploads/a704d4b90b9d423c13384072029988b4/RASProperties)
### 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?
It creates an error when I try and have nut type as 'zeroGradient' inside the nut file when inlet/outlet/top is type patch
### What is the expected *correct* behavior?
It should run without cancelling when the polymesh/boundary is type patch
### Relevant logs and/or images
dimensions [0 2 -1 0 0 0 0];
internalField uniform 0;
boundaryField
{
#include "include/ABLConditions"
inlet
{
type zeroGradient;
//value uniform 0.0;
}
outlet
{
type zeroGradient;
//value uniform 0;
}
top
{
type zeroGradient;
//value uniform 0;
}
DuneField
{
type nutkAtmRoughWallFunction;
z0 $z0;
value uniform 0;
}
}
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v7
Operating system : ubuntu
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :7
- Operating system :ubuntu
- Hardware info :
- Compiler :
### Possible fixes
<!--
'--> FOAM FATAL ERROR:
Attempt to cast type zeroGradient to type nutWallFunction
From function To& Foam::refCast(From&) [with To = const Foam::nutWallFunctionFvPatchScalarField; From = const Foam::fvPatchField<double>]
in file /home/ubuntu/OpenFOAM/OpenFOAM-7/src/OpenFOAM/lnInclude/typeInfo.H at line 114'
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/1961adapt/integrate PDRfitMesh2020-12-21T08:22:52ZMark OLESENadapt/integrate PDRfitMesh- serves as a pre-processor for PDRblockMesh. Scans the obstacles and helps determine an initial cell distribution for creating a PDRblockMeshDict
cross-ref: EP1247
@Pratap- serves as a pre-processor for PDRblockMesh. Scans the obstacles and helps determine an initial cell distribution for creating a PDRblockMeshDict
cross-ref: EP1247
@PratapMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1387Iso surface truncated by new "topo" method2020-12-20T14:06:24ZAdminIso surface truncated by new "topo" methodDuring the same run in an external aerodynamics application, I have tried to use the new isoSurfaceTopo method to extract and visualize turbulent structures via Lambda2, which resulted in a troncated iso-surface near the object, as shown...During the same run in an external aerodynamics application, I have tried to use the new isoSurfaceTopo method to extract and visualize turbulent structures via Lambda2, which resulted in a troncated iso-surface near the object, as shown in the picture attached (orange is Lambda2 via standard isoSurface and blue Lambda2 via isoSurfaceTopo).
![isoSurfaceTopoComparison](/uploads/332d5bd542ea4b4ce71eba275065dfe9/isoSurfaceTopoComparison.png)
\## Reattaching the author to the issue ticket: @Ricky-11 ##
\## Reattached image ##Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1920Issue with SRFSimpleFoam2020-12-18T15:52:52ZLorenzo CozziIssue with SRFSimpleFoamDear developers,
I am running a benchmark OpenFOAM case to compare its results with a reference run performed with Starccm+, adopting the same polyhedral mesh. The steady-state case involves the impeller of a centrifugal pump and the me...Dear developers,
I am running a benchmark OpenFOAM case to compare its results with a reference run performed with Starccm+, adopting the same polyhedral mesh. The steady-state case involves the impeller of a centrifugal pump and the mesh includes just one blade and conformal periodicity surfaces. Boundary conditions have been imposed to be coherent with the ones of Starccm+. The solver adopted is SRFSimpleFoam.
The problem is that the case seems to converge in less that 3000 steps, but the results that I get are totally surrealistic. Just to give you an idea, the pump is predicted to work as a turbine with static pressure reducing its value moving downstream in the meridional flow-path. Also the pressure field has a range spanning from really low to really high values.
I tried several settings in terms of fvSchemes and fvSolution without any improvement.
As I am not sure what is the exact issue afflicting the run (cyclicAMI, SRF model, etc.), I have uploaded all the case on Dropbox, you can find the link here: [link](https://www.dropbox.com/s/pb2vst6nvzolj10/impellerSRFSimpleFoam_SHARE.tar?dl=0)
I hope you can find a way to fix the solver behavior for this case,
thanks in advance.
Lorenzohttps://develop.openfoam.com/Development/openfoam/-/issues/1960scaledFixedValue error with pimpleFoam2020-12-17T15:46:15ZCarlos Peña-MonferrerscaledFixedValue error with pimpleFoam<!--
*** 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 -->
Crash at second iteration when testing `scaledFixedValue` BC in `pitzDaily`.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run `$WM_PROJECT_DIR/tutorials/incompressible/pimpleFoam/RAS/pitzDaily` with the following change on `0/U`:
```
- inlet
- {
- type fixedValue;
- value uniform (10 0 0);
- }
+ inlet
+ {
+ type scaledFixedValue;
+
+ scale table
+ (
+ ( 0 0)
+ ( 1.0 1.0)
+ (100.0 1.0)
+ );
+
+ refValue
+ {
+ type fixedValue;
+ value uniform (10 0 0);
+ }
+ }
```
### 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.
-->
```
Courant Number mean: 6.1914e-05 max: 0.00111829
deltaT = 0.000145287
Time = 0.000265769
PIMPLE: iteration 1
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigSegv::sigHandler(int) at ??:?
#2 ? in <path>/OpenFOAM-v2006/platforms/linuxPPC64leGccDPInt64Opt/lib/libOpenFOAM.so
#3 ? in <path>/OpenFOAM-v2006/platforms/linuxPPC64leGccDPInt64Opt/lib/libOpenFOAM.so
#4 Foam::Function1Types::TableBase<double>::value(double) const at ??:?
#5 Foam::PatchFunction1Types::UniformValueField<double>::value(double) const at ??:?
#6 Foam::scaledFixedValueFvPatchField<Foam::Vector<double> >::operator==(Foam::fvPatchField<Foam::Vector<double> > const&) at ??:?
#7 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::Boundary::operator==(Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::Boundary const&) at ??:?
#8 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::operator==(Foam::tmp<Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> > const&) at ??:?
#9 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::storeOldTime() const at ??:?
#10 Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh>::storeOldTimes() const at ??:?
#11 Foam::fvMatrix<Foam::Vector<double> >::fvMatrix(Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&, Foam::dimensionSet const&) at ??:?
#12 Foam::fv::EulerDdtScheme<Foam::Vector<double> >::fvmDdt(Foam::GeometricField<Foam::Vector<double>, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
#13 ? at ??:?
#14 ? at ??:?
#15 ? in /lib64/libc.so.6
#16 __libc_start_main in /lib64/libc.so.6
Segmentation fault
```
### 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 : centos
- Hardware info :
- Compiler : gccKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1853BUG: volFieldValue: writes empty fields2020-12-16T18:16:52ZKutalmış BerçinBUG: volFieldValue: writes empty fields<!--
*** 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 -->
`volFieldValue` FO writes empty fields when the input entry is `writeFields=true`.
It is due to the `weightField` being empty when there are no weights, which caused the entire output to be empty instead of simply being unweighted.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
- Download/extract [cavity.zip](/uploads/bc44ba559eeaeb8d8f704038ab1bdf70/cavity.zip)
- ./Allrun
- Inspect `p_all` in the time directories.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
`volFieldValue` FO should write non-empty fields.
### 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 : 18c68e6b74v2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/354runTimePostProcessing : Error Message : when run finishes2020-12-16T10:27:02ZPawan GhildiyalrunTimePostProcessing : Error Message : when run finishesHi
Case: tutorials/incompressible/pisoFoam/LES/motorBike/motorBike
Version : OpenFOAM-dev
OS: OpenSUSE:42.1 leap
VTK: 7.1.0
OpenMPI: 1.10.4
systemGCC: 4.8.5
Issue: After finishing the run following...Hi
Case: tutorials/incompressible/pisoFoam/LES/motorBike/motorBike
Version : OpenFOAM-dev
OS: OpenSUSE:42.1 leap
VTK: 7.1.0
OpenMPI: 1.10.4
systemGCC: 4.8.5
Issue: After finishing the run following message is thrown for both single processor and for multiprocessor. However the image file is dumped in normal way and is fine .
```
simpleFoam: symbol lookup error: /home/buzz2/pawan/OpenFOAM/ThirdParty-plus/platforms/linux64Gcc/VTK-7.1.0/lib/libvtkCommonExecutionModel-7.1.so.1: undefined symbol: _ZN33vtkFilteringInformationKeyManager13ClassFinalizeEv
simpleFoam: symbol lookup error: /home/buzz2/pawan/OpenFOAM/ThirdParty-plus/platforms/linux64Gcc/VTK-7.1.0/lib/libvtkCommonDataModel-7.1.so.1: undefined symbol: _ZN49vtkInformationQuadratureSchemeDefinitionVectorKeyD1Ev
simpleFoam: symbol lookup error: /home/buzz2/pawan/OpenFOAM/ThirdParty-plus/platforms/linux64Gcc/VTK-7.1.0/lib/libvtkCommonDataModel-7.1.so.1: undefined symbol: _ZN49vtkInformationQuadratureSchemeDefinitionVectorKeyD1Ev
simpleFoam: symbol lookup error: /home/buzz2/pawan/OpenFOAM/ThirdParty-plus/platforms/linux64Gcc/VTK-7.1.0/lib/libvtkCommonDataModel-7.1.so.1: undefined symbol: _ZN49vtkInformationQuadratureSchemeDefinitionVectorKeyD1Ev
simpleFoam: symbol lookup error: /home/buzz2/pawan/OpenFOAM/ThirdParty-plus/platforms/linux64Gcc/VTK-7.1.0/lib/libvtkCommonDataModel-7.1.so.1: undefined symbol: _ZN49vtkInformationQuadratureSchemeDefinitionVectorKeyD1Ev
simpleFoam: symbol lookup error: /home/buzz2/pawan/OpenFOAM/ThirdParty-plus/platforms/linux64Gcc/VTK-7.1.0/lib/libvtkCommonDataModel-7.1.so.1: undefined symbol: _ZN49vtkInformationQuadratureSchemeDefinitionVectorKeyD1Ev
simpleFoam: symbol lookup error: /home/buzz2/pawan/OpenFOAM/ThirdParty-plus/platforms/linux64Gcc/VTK-7.1.0/lib/libvtkCommonExecutionModel-7.1.so.1: undefined symbol: _ZN33vtkFilteringInformationKeyManager13ClassFinalizeEv
simpleFoam: symbol lookup error: /home/buzz2/pawan/OpenFOAM/ThirdParty-plus/platforms/linux64Gcc/VTK-7.1.0/lib/libvtkCommonDataModel-7.1.so.1: undefined symbol: _ZN49vtkInformationQuadratureSchemeDefinitionVectorKeyD1Ev
simpleFoam: symbol lookup error: /home/buzz2/pawan/OpenFOAM/ThirdParty-plus/platforms/linux64Gcc/VTK-7.1.0/lib/libvtkCommonDataModel-7.1.so.1: undefined symbol: _ZN49vtkInformationQuadratureSchemeDefinitionVectorKeyD1Ev
-------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code.. Per user-direction, the job has been aborted.
-------------------------------------------------------
--------------------------------------------------------------------------
mpirun detected that one or more processes exited with non-zero status, thus causing
the job to be terminated. The first process to do so was:
Process name: [[63468,1],2]
Exit code: 127
==================================================================================================
```
https://develop.openfoam.com/Development/openfoam/-/issues/1958Refining coarse cells with point on boundary can give illegal mesh2020-12-14T19:01:27ZPrashant SonakarRefining coarse cells with point on boundary can give illegal mesh<!--
*** 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 feature-runtime-selection-geometry has an additional refinement of cells which have a point on the boundary and are coarser than the (face) neighbouring cells. This can cause walking errors.
To be investigated.
### What is the current *bug* behaviour?
- During the refinement stages, code throws error about inconsistent 2:1 refinement.
### 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 : develop
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
commented section for boundary refinement as temporary fix at https://develop.openfoam.com/Development/openfoam/-/blob/develop/src/mesh/snappyHexMesh/snappyHexMeshDriver/snappyRefineDriver.C#L3454Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1947BUG: problem with collated format and writing of NURBS3DVolume control points2020-12-14T18:07:05ZVaggelis PapoutsisBUG: problem with collated format and writing of NURBS3DVolume control points### Summary
adjointOptimisationFoam crashes when attempting to write the volumetric B-Splines control points into an IOdictionary when using the collated file format.
In specific, the if(Pstream::master()) clause in NURBS3DVolume::wri...### Summary
adjointOptimisationFoam crashes when attempting to write the volumetric B-Splines control points into an IOdictionary when using the collated file format.
In specific, the if(Pstream::master()) clause in NURBS3DVolume::writeCpsInDict() is
causing the fileName of the regIOobject not to be allocated in all
processors, giving problems when masterUncollatedFileOperation::masterOp
is called by collatedFileOperation::writeObject for the mkDirOp.
### Steps to reproduce
Running the case under $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/sbend/laminar/opt/unconstrained/BFGS using the collated file format gives
```
--> FOAM FATAL IO ERROR:
Bad token - could not get string
```
A serial execution gives no error.
### Possible fixes
Removing the
`if (Pstream::master())`
clause from line 1915 of NURBS3DVolume.C fixes the issue.v2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1943Accessing field in codedSource with codeCorrect2020-12-14T14:40:37ZCarlos Peña-MonferrerAccessing field in codedSource with codeCorrectHi,
The documentation for [`codedSource`](https://www.openfoam.com/documentation/guides/latest/api/classFoam_1_1fv_1_1codedSource.html#details) mentions the following arguments:
- codeCorrect: field
- codeAddSup: eqn, fieldi
- codeCons...Hi,
The documentation for [`codedSource`](https://www.openfoam.com/documentation/guides/latest/api/classFoam_1_1fv_1_1codedSource.html#details) mentions the following arguments:
- codeCorrect: field
- codeAddSup: eqn, fieldi
- codeConstrain: eqn, fieldi
I can use `eqn` and `fieldi` from codeAddSup, however when trying to use `field` from `codeCorrect` it complains about not being declared. Is there something missing in the following code?
```
codedSource
{
type vectorCodedSource;
selectionMode all;
fields (U);
name testing;
codeCorrect
#{
vectorField& testField = field;
#};
codeAddSup
#{
vectorField& fieldSource = eqn.source();
label fieldLabel = fieldi;
#};
codeConstrain
#{
#};
}
```
Thanks.https://develop.openfoam.com/Development/openfoam/-/issues/1793effective deltaT or old time for lumpedPointMotion2020-12-14T11:32:28ZMark OLESENeffective deltaT or old time for lumpedPointMotionAs discussed off-line with @taka, it would be useful to also record information about the update period to pass through to the FEM code.
Eg, Instead of the forces.out containing this
```
// Time index=421 value=0.08421
points
...
```
...As discussed off-line with @taka, it would be useful to also record information about the update period to pass through to the FEM code.
Eg, Instead of the forces.out containing this
```
// Time index=421 value=0.08421
points
...
```
it would be useful to have it contain
```
// Time index=421 value=0.08421 updateInterval=0.004
```
This is because the OpenFOAM mesh update interval can be controlled by just about anything (timeStep, cpuTime, clockTime) and the FEM code has no convenient way of obtaining this information, other than having its own internal cache.
Taka provided [modify_force.out_file.pdf](/uploads/a6efe90d09c1c381a1d9cc00ff9a1dc7/modify_force.out_file.pdf)
in the explanation.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1949BUG: globalSum needed in the directional derivative of the merit function2020-12-11T17:39:02ZVaggelis PapoutsisBUG: globalSum needed in the directional derivative of the merit function### Summary
When the derivative of the merit function is computed the global (instead of the local) sum of the objective derivative and the correction should be calculated.
This bug does not actually affect the current functionality o...### Summary
When the derivative of the merit function is computed the global (instead of the local) sum of the objective derivative and the correction should be calculated.
This bug does not actually affect the current functionality of the code since, with volumetric B-Splines, all design variables (and their derivatives and corrections) are known by all processors. It will, however, affect cases in which the design variables are distributed, like topology optimisation or when considering the movement of each boundary point as a design variable in shape optimisation.v2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1948BUG: First extrapolated value of the merit function is computed wrongly2020-12-11T17:37:37ZVaggelis PapoutsisBUG: First extrapolated value of the merit function is computed wrongly### Summary
In an adjoint-based optimisation, if the step value (eta) is not set explicitly, it is computed after evaluating the
directional derivative of the merit function, which, in turn, is computed
wrongly, leading to an erroneous ...### Summary
In an adjoint-based optimisation, if the step value (eta) is not set explicitly, it is computed after evaluating the
directional derivative of the merit function, which, in turn, is computed
wrongly, leading to an erroneous value of the extrapolated merit
function value.
Affects only the first optimisation cycle, if line search is enabled, so the bug should appear rather rarely.v2012Andrew HeatherAndrew Heather