Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-08-03T15:39:05Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1769CrankNicolson ddtScheme gives wrong results for even nOuterCorrectors2020-08-03T15:39:05ZHenning ScheuflerCrankNicolson ddtScheme gives wrong results for even nOuterCorrectorsIn order to increase the numerical stability or accuracy of the scheme, we have the possibility to solve the equation multiple times during a time step. A common example for this is the pimple algorithm. However, the combination multiple...In order to increase the numerical stability or accuracy of the scheme, we have the possibility to solve the equation multiple times during a time step. A common example for this is the pimple algorithm. However, the combination multiple nOuterCorrectors with the CrankNicolson scheme leads to wrong results:
**CrankNicolson nOuter 1:**
![CNNouter1_damBreak_U](/uploads/3a5a989261c43afa604bcd820c7e2a84/CNNouter1_damBreak_U.png)
![CNNouter1_damBreak_alpha](/uploads/da84dec4c018050d1536086fc948df65/CNNouter1_damBreak_alpha.png)
**CrankNicolson nOuter 2:**
![CNNouter2_damBreak_U](/uploads/c329af32ac84586bbd566dcfae0aa56d/CNNouter2_damBreak_U.png)
![CNNouter2_damBreak_alpha](/uploads/3eb9ecd54af0243c1a1a917fe3ed3159/CNNouter2_damBreak_alpha.png)
**CrankNicolson nOuter 2 with fix:**
![CNNouter2_damBreak_U_fixed](/uploads/3b38acbf9a994a9d8cac5ac6ff4b867e/CNNouter2_damBreak_U_fixed.png)
![CNNouter2_damBreak_alpha_fixed](/uploads/5967cde4a3db48021b3be137cf304f05/CNNouter2_damBreak_alpha_fixed.png)
Solving the equations with the CrankNicolson time scheme results in wrong values if nOuterCorrectors is an even number. The reason is that (evaluate(ddt0)) in fvmDDt is always true:
```
{
if (evaluate(ddt0))
{
ddt0 = rDtCoef0_(ddt0)*rho*(vf.oldTime() - vf.oldTime().oldTime())
- offCentre_(ddt0());
}
fvm.source() =
(
rDtCoef*rho.value()*vf.oldTime().primitiveField()
+ offCentre_(ddt0.primitiveField())
)*mesh().V();
}
```
as the timeIndex of the geometricField is not update in the above scenario.
A possible solution might be:
```
template<class Type>
template<class GeoField>
bool CrankNicolsonDdtScheme<Type>::evaluate
(
DDt0Field<GeoField>& ddt0
)
{
bool evaluated = ddt0.timeIndex() != mesh().time().timeIndex();
ddt0.timeIndex() = mesh().time().timeIndex();
return evaluated;
}
```
### Reproduce
interFoam -> damBreak
ddtSchemes -> CrankNicolson 0.9;
nOuterCorrectors -> 2;
### Environment information
- OpenFOAM version : v1806
- Operating system : ubuntu
- Hardware info :
- Compiler :https://develop.openfoam.com/Development/openfoam/-/issues/2184Crash using ParticleCollector in parallel2021-09-08T08:44:54ZDarrin StephensCrash using ParticleCollector in parallel
### Summary
When using the ParticleCollector cloud function in parallel the simulation may crash. The crash is dependent on the number of processors used and the memory state of the computer.
### Steps to reproduce
I have been able t...
### Summary
When using the ParticleCollector cloud function in parallel the simulation may crash. The crash is dependent on the number of processors used and the memory state of the computer.
### Steps to reproduce
I have been able to replicate this problem on multiple computers using the splashPanel tutorial (tutorials/lagrangian/reactingParcelFoam/splashPanel). To get the crash behaviour this tutorial needs to be run with at least 10 processors. The small number of cells in the wall region with this number of processors is no the cause of the crash. I have had this problem on much bigger cases that I cannot share.
### Example case
[splashPLanel_parallel.tar.gz](/uploads/48c93fa4e973ecc29ce991c948e03b8d/splashPLanel_parallel.tar.gz)
### What is the current *bug* behaviour?
When the bug is encountered you will get an error message similar to that shown below. Note the processor that the problem occurs on can be different between crashes.
```
[3] --> FOAM FATAL IO ERROR: (openfoam-2012 patch=210618)
[3] Wrong token type - expected scalar value, found on line 3: punctuation '-'
[3]
[3] file: /tmp/06_splashPLanel_parallel/processor3/0/uniform/lagrangian/reactingCloud1/reactingCloud1OutputProperties.cloudFunctionObject.particleCollector1.massTotal at line 3.
[3]
[3] From Foam::Istream& Foam::operator>>(Foam::Istream&, Foam::doubleScalar&)
[3] in file lnInclude/Scalar.C at line 154.
[3]
FOAM parallel run exiting
```
### What is the expected *correct* behavior?
Correct behaviour is the cloud function calculate the massTotal and MassFlowRate without crashing.
### Environment information
- OpenFOAM version : v2106 and at least v2012. Older versions have not been tested.
- Operating system : ubuntu and centos
- Hardware info :
- Compiler : gcc
### Possible fixes
The line number below refer to the v2016 version of src/lagrangian/intermediate/submodels/CloudFunctionObjects/ParticleCollector/ParticleCollector.C.
The problem is caused by some processors getting a -nan for the massTotal and/or massFlowRate. These values get written to the processor uniform/lagrangian/reactingCloud1/reactingCloud1OutputProperties dictionary. This results in a read failure at lines 427 and 430 on the next timestep.
The reason for the nan's. The massTotal and massFlowRate are calculated for each collector's face in the loop on lines 435-459. The scalar lists allProcMass and allProcMassFlowRate are not initialised to any value at declaration. i.e. they get whatever is in the memory location. A gather function is then used on these lists. After the gather, every processor only knows its own data and that of the processors below it. This means only the master process has the complete list. Other processors lists may still have junk numbers from initialisation. The sum operations performed on lines 440 and 445 will sum the local list for each processor. Noting only the master has the correct list. The correct values are reported because of the Info<< usage on line 461. Lines 497 and 498 write the values for the massTotal and massFlowRate into the reactingCloud1OutputProperties dictionary for each processor, potentially causing the read problem on the next timestep.
Proposed solution: There are a couple of ways to fix this. One would be to scatter the list after the gather, making sure all processors have the same information. Since it appears it is only the master that needs this information, an alternative solution is to initialise the allProcMass and allProcMassFlowRate lists to zero at construction. That way the sums (lines 440 and 445) will not result in large (overflow) numbers.https://develop.openfoam.com/Development/openfoam/-/issues/628Crash when directory contains files with spaces or other odd characters in th...2017-12-19T10:50:58ZAdminCrash when directory contains files with spaces or other odd characters in their filenamesparaFoam crash on start with the following error:
`
Created temporary 'run407.OpenFOAM'
I/O : uncollated
fileName::stripInvalid() called for invalid fileName tot6.7kn.0032.jpg
For debug level (= 2) > 1 this is considered fatal
Abo...paraFoam crash on start with the following error:
`
Created temporary 'run407.OpenFOAM'
I/O : uncollated
fileName::stripInvalid() called for invalid fileName tot6.7kn.0032.jpg
For debug level (= 2) > 1 this is considered fatal
Aborted (core dumped)
`
When the current directory contains the files:
`
tot 6.7kn.0000.jpg
tot 6.7kn.0001.jpg
tot 6.7kn.0002.jpg
tot 6.7kn.0003.jpg
etc.
`
(the files where generated by the paraFoam File -> save animation)
When the files are renamed to use underscores, paraFoam starts normally:
`
tot_6.7kn.0000.jpg
tot_6.7kn.0001.jpg
tot_6.7kn.0002.jpg
tot_6.7kn.0003.jpg
etc.
`
When a new animation is made by clicking File -> save animation -> ok
the file name selection dialog correctly merges the image files to: "[+]tot_6.7kn...jpg"
I don't know if this is a recent problem since I normally don't use spaces in filenames. It was found by someone else.
The obvious workaround is to not uses spaces in animation filenames, or deleting old images before starting paraFoam.
`
paraview 5.4.0
OS: Ubuntu 16.04.3 LTS (64 bit)
compiler: gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609 [CORRECTED]
build command: ./makeParaView PARAVIEW_QT_VERSION=4
`
I looked at Development/ThirdParty-plus but i'm not sure if paraFoam is a third party build script and neither project readme's mention paraFoam. Please let me know if this issue should be in ThirdParty-plus.
small detail:
I have 63 images, named 0..62. I don't know why the error is for image 32, it could be the order in which the OS lists the file names but (after renaming to underscores) ls -u *.jpg also lists image 32 somewhere in the middle of the file list.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2078Crash with dynamicMotionSolverFvMeshAMI2024-01-10T10:57:24ZDavid HoraCrash with dynamicMotionSolverFvMeshAMIHi all
I wanted to test the dynamicMotionSolverFvMeshAMI but my simulation of a centrifugal fan crashes immediately because of an unallocated autoPtr. The case has 9.3 million cells and consists of an impeller and a volute. The simulati...Hi all
I wanted to test the dynamicMotionSolverFvMeshAMI but my simulation of a centrifugal fan crashes immediately because of an unallocated autoPtr. The case has 9.3 million cells and consists of an impeller and a volute. The simulation is a restart from a dynamicMotionSolverFvMesh simulation where two revolutions were calculated without problems. Unfortunately I can't reproduce it with a smaller case. I hope the log file helps. Otherwise let me know if you need more information.
Kind regards
David
[pimpleFoam_rerun.log](/uploads/0a899b9c446f6fd1bade038e6d63546f/pimpleFoam_rerun.log)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2167Cray-MPICH2024-01-12T08:27:24ZAndrew RobertsCray-MPICHHi,
I am installing OpenFOAM v2012 on an ARM machine. It seems like WM_MPLIB by default is SYSTEMOPENMPI, but we are changing it to CRAY-MPICH in prefs.sh. However I have noticed a problem.
CRAY-MPICH refers to wmake/rules/General/mpli...Hi,
I am installing OpenFOAM v2012 on an ARM machine. It seems like WM_MPLIB by default is SYSTEMOPENMPI, but we are changing it to CRAY-MPICH in prefs.sh. However I have noticed a problem.
CRAY-MPICH refers to wmake/rules/General/mplibCRAY-MPICH, which I think refers to wmake/rules/General/mplibMPICH
mplibMPICH contains an error I think:
```
PFLAGS = -DMPICH_SKIP_MPICXX -DOMPI_SKIP_MPICXX
PINC = -isystem $(MPI_ARCH_PATH)/include
PLIBS = -L$(MPI_ARCH_PATH)/lib$(WM_COMPILER_LIB_ARCH) -L$(MPI_ARCH_PATH)/lib -lmpi -lrt
```
It should be at this:
```
PFLAGS = -DMPICH_SKIP_MPICXX
PINC = -isystem $(MPI_ARCH_PATH)/include
PLIBS = -L$(MPI_ARCH_PATH)/lib$(WM_COMPILER_LIB_ARCH) -L$(MPI_ARCH_PATH)/lib -lmpich -lrt
```
I think the DOMPI_SKIP_MPICXX flag means MPI should not include C++ headers, but we are not using MPI so I guess I don't need that either!
Kind regards,
Andy
P.S. In version 1812 it was correct like this:
```
PFLAGS = -DMPICH_SKIP_MPICXX
PINC = -isystem $(MPI_ARCH_PATH)/include
PLIBS = -L$(MPI_ARCH_PATH)/lib$(WM_COMPILER_LIB_ARCH) -L$(MPI_ARCH_PATH)/lib -lmpich -lrt
```https://develop.openfoam.com/Development/openfoam/-/issues/1190create module ignores -output option2019-12-09T22:37:28ZMark OLESENcreate module ignores -output optionalso no easy way to pass in preferences
@ivanspissoalso no easy way to pass in preferences
@ivanspissoMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/795createPatch deletes cellSets/cellZones2024-01-16T05:40:42ZAdmincreatePatch deletes cellSets/cellZonesI have a simple porous media in a duct, and use insideCells to create a cellZoneSet, which is then turned into a cellZone by topoSet. checkMesh reports the number of cells and bounding box of this cellZone correctly.
However, after runn...I have a simple porous media in a duct, and use insideCells to create a cellZoneSet, which is then turned into a cellZone by topoSet. checkMesh reports the number of cells and bounding box of this cellZone correctly.
However, after running createPatch -overwrite, the cellZone is empty. Is this desired behavior, or a bug?
I can create a very small test case is needed.
\## Reattaching the author to the issue ticket: @aerogt3 ##Prashant SonakarPrashant Sonakarhttps://develop.openfoam.com/Development/openfoam/-/issues/2193createPatch does not check for repatching same face twice2021-09-07T09:21:31ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcreatePatch does not check for repatching same face twice### Functionality to add/problem to solve
createPatch can create patches from selections of boundary faces (either from faceSets or existing patches). However it does not check that faces are present in more than one selection. Currentl...### Functionality to add/problem to solve
createPatch can create patches from selections of boundary faces (either from faceSets or existing patches). However it does not check that faces are present in more than one selection. Currently the 'last one wins' but it would be nice to have proper checks.
### Proposal
Error if selections overlap.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2386createPatch : do multi-region matching2022-12-23T14:59:42ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcreatePatch : do multi-region matching### Functionality to add/problem to solve
Have automatic detection of overlapping patches and re-patch these faces.
### Target audience
cases with multiple regions
### Proposal
Use AMI methods to detect overlapping faces, create pat...### Functionality to add/problem to solve
Have automatic detection of overlapping patches and re-patch these faces.
### Target audience
cases with multiple regions
### Proposal
Use AMI methods to detect overlapping faces, create patches for these and move the faces across.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/577createZeroDictionary with volume flow rate2019-12-09T22:11:26ZvilfayeaucreateZeroDictionary with volume flow ratehttps://develop.openfoam.com/Development/OpenFOAM-plus/blob/develop/etc/caseDicts/createZeroDirectoryTemplates/boundaryConditions/fluid/incompressible/inletOptions
If you have a look at the source code of createZeroDictionary (see abov...https://develop.openfoam.com/Development/OpenFOAM-plus/blob/develop/etc/caseDicts/createZeroDirectoryTemplates/boundaryConditions/fluid/incompressible/inletOptions
If you have a look at the source code of createZeroDictionary (see above), it requires volumeFlowRate instead of volumetrictFlowRate. Could you fix it?
Thanks
SebastienPrashant SonakarPrashant Sonakarhttps://develop.openfoam.com/Development/openfoam/-/issues/2976cross-compile from opensuse to windows112023-09-14T13:26:21Zfea1ncross-compile from opensuse to windows11The output after running blockMesh is as follows
`--> FOAM FATAL ERROR :`
`Could not find mandatory etc entry (mode=ugo) 'controlDict'`
how to fix this?The output after running blockMesh is as follows
`--> FOAM FATAL ERROR :`
`Could not find mandatory etc entry (mode=ugo) 'controlDict'`
how to fix this?Pawan GhildiyalPawan Ghildiyalhttps://develop.openfoam.com/Development/openfoam/-/issues/2547cross compile minGw64 (using OpenSUSE) - More Information required2023-05-18T06:20:29ZPhilippose Rajancross compile minGw64 (using OpenSUSE) - More Information requiredHello to the OF-Development Team,
I have been trying to cross-compile OpenFOAM-v2206 on OpenSUSE Leap 15.4 for Windows, and I have a couple of questions...:
* The documentation in the Wiki for Windows Cross-Compile does not mention any...Hello to the OF-Development Team,
I have been trying to cross-compile OpenFOAM-v2206 on OpenSUSE Leap 15.4 for Windows, and I have a couple of questions...:
* The documentation in the Wiki for Windows Cross-Compile does not mention anything specific about how the parallel library (msmpi) is handled. Following the instructions in the Wiki for OpenSUSE lands up with a error that "mpi.h" cannot be found. What exactly needs to be done to get msmpi into OpenSUSE during the compile phase?
* While compiling the test application, under "platforms", I get the folder "linux64MingwDPInt32Opt", where as, the Windows Version which can be downloaded from the OpenFOAM Website has the folder "win64MingwDPInt32Opt"... Why is there this difference?
* What else do I need to take care of while cross-compiling OpenFOAM for Windows in OpenSUSE?
I would appreciate any help that could be provided. The reason why I am trying to cross compile OpenFOAM is due to the fact that we have some in-house libraries and solvers which also need to be ported, when switching to the Windows version of OpenFOAM.
Thank you very much.
Regards,
Philipposehttps://develop.openfoam.com/Development/openfoam/-/issues/2169Curle function object misses 1/r and 1/(4 pi)2021-10-31T16:37:58ZYoujiang WangCurle function object misses 1/r and 1/(4 pi)<!--
*** 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
I read that someone reported, there misses 1/(4 pi) in the Curle acoustic analogy implementation. This might have not been fixed. Besides, a dividing by r is also missed. This makes the sound pressure amplitude almost do not change with distance.
The code is at Curle.C line 219, which is not in consistent with the theoretical description.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2012
Operating system : openSUSE
Hardware info : any info that may help?
Compiler : gcc
-->
- OpenFOAM version : v2012
- Operating system : openSUSE
- 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
-->Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/574Curle's analogy2019-12-09T22:11:26ZAdminCurle's analogyI believe there is a mistake in the implemented acoustic analogy in OF-1706. The coefficient on the RHS should be 1/(4*pi) instead of 4*pi.
Probably change:
pDash = 4*mathematical::pi/c0_ * (d/magSqr(d) & dfdt);
to pDash = 1/4/mathemati...I believe there is a mistake in the implemented acoustic analogy in OF-1706. The coefficient on the RHS should be 1/(4*pi) instead of 4*pi.
Probably change:
pDash = 4*mathematical::pi/c0_ * (d/magSqr(d) & dfdt);
to pDash = 1/4/mathematical::pi/c0_ * (d/magSqr(d) & dfdt);https://develop.openfoam.com/Development/openfoam/-/issues/799Current develop branch does not compile in SP2023-12-07T19:03:31ZAdminCurrent develop branch does not compile in SPThrowing the following error:
turbulentFluidThermoModels/derivedFvPatchFields/outletMachNumberPressure/outletMachNumberPressureFvPatchScalarField.C: In member function ‘virtual void Foam::outletMachNumberPressureFvPatchScalarField::writ...Throwing the following error:
turbulentFluidThermoModels/derivedFvPatchFields/outletMachNumberPressure/outletMachNumberPressureFvPatchScalarField.C: In member function ‘virtual void Foam::outletMachNumberPressureFvPatchScalarField::write(Foam::Ostream&) const’:
turbulentFluidThermoModels/derivedFvPatchFields/outletMachNumberPressure/outletMachNumberPressureFvPatchScalarField.C:252:44: error: no matching function for call to ‘Foam::Ostream::writeEntryIfDifferent(const char [3], double, const scalar&)’
os.writeEntryIfDifferent("c1", 0.0, c1_);
^
turbulentFluidThermoModels/derivedFvPatchFields/outletMachNumberPressure/outletMachNumberPressureFvPatchScalarField.C:252:44: note: candidate is:
In file included from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/OpenFOAM/lnInclude/OSstream.H:39:0,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/OpenFOAM/lnInclude/messageStream.H:216,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/OpenFOAM/lnInclude/error.H:51,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/OpenFOAM/lnInclude/UListI.H:26,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/OpenFOAM/lnInclude/UList.H:532,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/OpenFOAM/lnInclude/List.H:43,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/OpenFOAM/lnInclude/wordList.H:48,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/OpenFOAM/lnInclude/patchIdentifier.H:38,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/OpenFOAM/lnInclude/polyPatch.H:42,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/finiteVolume/lnInclude/fvPatch.H:39,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/finiteVolume/lnInclude/fvPatchField.H:47,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/finiteVolume/lnInclude/fixedValueFvPatchField.H:57,
from /scratch/OpenFOAM/OpenFOAM-plus-develop/src/finiteVolume/lnInclude/fixedValueFvPatchFields.H:29,
from turbulentFluidThermoModels/derivedFvPatchFields/outletMachNumberPressure/outletMachNumberPressureFvPatchScalarField.H:133,
from turbulentFluidThermoModels/derivedFvPatchFields/outletMachNumberPressure/outletMachNumberPressureFvPatchScalarField.C:26:
/scratch/OpenFOAM/OpenFOAM-plus-develop/src/OpenFOAM/lnInclude/Ostream.H:219:22: note: template<class T> Foam::Ostream& Foam::Ostream::writeEntryIfDifferent(const Foam::word&, const T&, const T&)
Ostream& writeEntryIfDifferent
^
/scratch/OpenFOAM/OpenFOAM-plus-develop/src/OpenFOAM/lnInclude/Ostream.H:219:22: note: template argument deduction/substitution failed:
turbulentFluidThermoModels/derivedFvPatchFields/outletMachNumberPressure/outletMachNumberPressureFvPatchScalarField.C:252:44: note: deduced conflicting types for parameter ‘const T’ (‘double’ and ‘Foam::scalar {aka float}’)
os.writeEntryIfDifferent("c1", 0.0, c1_);Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/212"Current Release" links are broken in some of the side menus2016-08-18T10:16:53ZAdmin"Current Release" links are broken in some of the side menusThe following pages still refer to the v3.0+ on the side menu:
* http://openfoam.com/download/install-source.php
* http://openfoam.com/download/installation.php
* http://openfoam.com/download/install-binary.php
* http://ope...The following pages still refer to the v3.0+ on the side menu:
* http://openfoam.com/download/install-source.php
* http://openfoam.com/download/installation.php
* http://openfoam.com/download/install-binary.php
* http://openfoam.com/download/install-windows.php
* http://openfoam.com/download/release-history.php
* http://openfoam.com/download/index.php
AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/2110Custom option from shared library does not execute addsup2021-06-07T13:32:48ZThomas EnzingerCustom option from shared library does not execute addsup
### Summary
Custom coded option, placed in an shared library, is loaded and constructed from solver. But addsup are not executed in all time steps.
Exact same code as scalarCodedSource is executed as aspected.
### Steps to reproduce
...
### Summary
Custom coded option, placed in an shared library, is loaded and constructed from solver. But addsup are not executed in all time steps.
Exact same code as scalarCodedSource is executed as aspected.
### Steps to reproduce
Run the example case and take an look to the solver log file. Code for scalarCodedSource and custom coded option are identical and applied to bottomAir region.
### Example case
Minimum example: [example_1.zip](/uploads/b4ee6b26737ee92308cd6f0eaaa73e96/example_1.zip)
Directory *code* contains the wmake project to build the shared library.
Minimum example (attached file) was constructed from v2012 $FOAM_TUTORIALS/heatTransfer/chtMultiRegionFoam/snappyMultiRegionHeater .
### What is the current *bug* behaviour?
The **addSup** method of the option is not executed by the solver.
### What is the expected *correct* behavior?
The **addSup** method of the option is executed by the solver at all timesteps.
### Relevant logs and/or images
```C++
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v2012 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 308af39136-20210426 OPENFOAM=2012 patch=210414
Arch : "LSB;label=32;scalar=64"
Exec : chtMultiRegionFoam
Date : May 31 2021
Time : 23:01:05
Host : e10491f6fb91
PID : 3822
I/O : uncollated
Case : /data
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
...
Adding fvOptions
Creating finite volume options from "constant/fvOptions"
Selecting finite volume options type scalarCodedSource
Source: codedSource1
- selecting all cells
- selected 3952 cell(s) with volume 0.0007786667
Selecting finite volume options type myCustomCodeOption
Source: codedSource2
- selecting all cells
- selected 3952 cell(s) with volume 0.0007786667
Constructor: myCustomCodeOption
*** Reading fluid mesh thermophysical properties for region topAir
...
Solving for fluid region bottomAir
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCGStab: Solving for Ux, Initial residual = 1, Final residual = 9.813842e-11, No Iterations 1
DILUPBiCGStab: Solving for Uy, Initial residual = 1, Final residual = 4.796629e-11, No Iterations 1
DILUPBiCGStab: Solving for Uz, Initial residual = 1, Final residual = 1.290181e-10, No Iterations 1
Using dynamicCode for fvOption::sourceTime at line 20 in "/data/constant/bottomAir/fvOptions.codedSource1"
Could not load > "/data/dynamicCode/platforms/linux64GccDPInt32Opt/lib/libsourceTime_e97fe6ced1b0ca40c9289d9da8b1add0a8482aa2.so"
/data/dynamicCode/platforms/linux64GccDPInt32Opt/lib/libsourceTime_e97fe6ced1b0ca40c9289d9da8b1add0a8482aa2.so: cannot open shared object file: No such file or directory
Creating new library in "dynamicCode/sourceTime/platforms/linux64GccDPInt32Opt/lib/libsourceTime_e97fe6ced1b0ca40c9289d9da8b1add0a8482aa2.so"
Invoking wmake libso /data/dynamicCode/sourceTime
wmake libso /data/dynamicCode/sourceTime
ln: ./lnInclude
dep: codedFvOptionTemplate.C
Ctoo: codedFvOptionTemplate.C
ld: /data/dynamicCode/sourceTime/../platforms/linux64GccDPInt32Opt/lib/libsourceTime_e97fe6ced1b0ca40c9289d9da8b1add0a8482aa2.so
Selecting finite volume options type sourceTime
Source: sourceTime
- selecting all cells
- selected 3952 cell(s) with volume 0.0007786667
Hello scalarCodedSource.
DILUPBiCGStab: Solving for h, Initial residual = 0.9999996, Final residual = 1.079829e-10, No Iterations 1
Min/max T:300 300
GAMG: Solving for p_rgh, Initial residual = 0.8519038, Final residual = 0.008084614, No Iterations 5
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors (bottomAir): sum local = 1.199034e-05, global = 2.856298e-15, cumulative = 2.856298e-15
GAMG: Solving for p_rgh, Initial residual = 0.259271, Final residual = 7.494411e-08, No Iterations 23
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
time step continuity errors (bottomAir): sum local = 2.862262e-06, global = 1.923892e-15, cumulative = 4.78019e-15
...
Solving for fluid region bottomAir
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
DILUPBiCGStab: Solving for Ux, Initial residual = 0.9504684, Final residual = 1.315995e-11, No Iterations 1
DILUPBiCGStab: Solving for Uy, Initial residual = 0.3615856, Final residual = 7.315234e-12, No Iterations 1
DILUPBiCGStab: Solving for Uz, Initial residual = 0.375026, Final residual = 6.384547e-12, No Iterations 1
Hello scalarCodedSource.
DILUPBiCGStab: Solving for h, Initial residual = 0.9992415, Final residual = 8.874669e-11, No Iterations 1
Min/max T:299.9998 300.6861
...
```
### 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 : v2021
- Operating system : archlinux, centos in docker container
- Hardware info : AMD Ryzen, docker container env.
- Compiler : gcc
### Possible fixes
atm.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2593Cut2022-09-26T14:42:26Zomar SallamCutDear all, I am new to this version of OpenFOAM.
Any advice how I can simulate stokes wave with underwater current.
Basically, I am simulating floating structure in waves and underwater current.
Thanks in advance.Dear all, I am new to this version of OpenFOAM.
Any advice how I can simulate stokes wave with underwater current.
Basically, I am simulating floating structure in waves and underwater current.
Thanks in advance.https://develop.openfoam.com/Development/openfoam/-/issues/954cuttingPlane requires huge amount of RAM in single precision2024-01-11T14:06:05ZAdmincuttingPlane requires huge amount of RAM in single precisionDear All,
my transient simulation crashes when it tries to export cuttingPlanes VTK on the fly for lack of RAM memory, when running the solver (pisoFoam) in single precision. Everything runs fine if i run the double precision version.
I...Dear All,
my transient simulation crashes when it tries to export cuttingPlanes VTK on the fly for lack of RAM memory, when running the solver (pisoFoam) in single precision. Everything runs fine if i run the double precision version.
I couldn't explain this behaviour.
Thanks for your help
Marco
\## Reattaching the author to the issue ticket: @okocha ##https://develop.openfoam.com/Development/openfoam/-/issues/1088cyclicACMI cannot be used with transformations2018-12-24T09:00:37ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcyclicACMI cannot be used with transformationscyclicACMI starts adapting area weights before transformation tensors have been calculated.
Below testcase is pipeCyclic tutorial but with cyclicACMI.
[pipeCyclic-wo-blockMeshChange-ACMI-roationalTransform.tgz](/uploads/f660c246f3d3317...cyclicACMI starts adapting area weights before transformation tensors have been calculated.
Below testcase is pipeCyclic tutorial but with cyclicACMI.
[pipeCyclic-wo-blockMeshChange-ACMI-roationalTransform.tgz](/uploads/f660c246f3d3317d9a1f83fb966f5882/pipeCyclic-wo-blockMeshChange-ACMI-roationalTransform.tgz)
run
```mpirun -np 5 checkMesh -allGeometry -allTopology -parallel```
to see the masks.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com