Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-06-19T07:07:20Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1564limitTemperature functionObject does not work with compressibleInterFoam2020-06-19T07:07:20ZPawan GhildiyallimitTemperature functionObject does not work with compressibleInterFoam<!--
*** Please read this first! ***
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
limitTemperature functionObject does not work with compressibleInterFoam
### S...<!--
*** Please read this first! ***
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
limitTemperature functionObject does not work with compressibleInterFoam
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v1906 and dev
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/2621limitTemperature option looks up thermo even if not active2022-11-30T08:26:02ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comlimitTemperature option looks up thermo even if not active<!--
*** 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 -->
Use limitTemperature in e.g. moveDynamicMesh with displacementLaplacian. displacementLaplacian constructs fvOptions. limitTemperature will fail since looks up thermo in constructor - even if not active.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
See above
### What is the current *bug* behaviour?
<!-- What actually happens -->
FatalError since cannot find thermo
### What is the expected *correct* behavior?
<!-- What you should see instead -->
At least obey 'active' flag
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2206|v2112|v2106|v2012|v2006 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :v2206
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
Use isActive flag in constructor.
<!--
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
-->Mattijs 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/2500Linear solver residual tolerances should not always be normalized2022-11-17T15:36:59ZCarsten ThorenzLinear solver residual tolerances should not always be normalized### Functionality to add/problem to solve
In the implementation of the linear solvers, the calculated L2-norm (?) of the residual vector is compared to user supplied absolute and relative tolerances. In the code, before comparison, the ...### Functionality to add/problem to solve
In the implementation of the linear solvers, the calculated L2-norm (?) of the residual vector is compared to user supplied absolute and relative tolerances. In the code, before comparison, the calculated residual is normalized with an estimate of the scale of the problem, which is computed from an initial guess for the solution and the RHS of the equation system. Actually, this turns the "absolute" tolerance into some kind of relative tolerance.
This is helpful (though misleading), if the expected absolute values of the residuals are unknown to the user. It is a disadvantage, if the expected absolute errors are known.
Thus it is proposed to optionally switch of the normalization of the residuals. A proposed patch is attached.
IMHO, the current specification of a tolerance and a relTol in the solver dictionary is weird, because actually both tolerances are compared to normalized residuals in the code. One by some properties of the equation system, the other by the initial residual. The treatment in the code "looks" different, but actually both variants are normalizations. But cleaning this up would require larger changes in the linear solvers, that I didn't want to tackle.
### Target audience
If the expected residuals and tolerances are well known, it is beneficial to use absolute tolerances for the solvers and not normalized ones, because it enhances the performance. Example: Transient tracer transport. In a simulation period with no or few tracer in the system, in the current implementation the normalization factor is near zero. Thus, the normalization of the residuals with "near zero" results in excessive iterations to reach the tolerance. The acquired accuracy is gained at high cost and might be unnecessary, if later in the transient development, at a much higher level of tracer concentrations, the interesting things happen.
### Proposal
Make the normalization of residuals a user choice. The proposed patch is an enhancement in lduMatrix::solver::normFactor . A user specified "residualNormalization" can then be added to the solver dictionary. If omitted, the old behaviour is retained. If set to "none", the normalization method returns "1", i.e. normalization is switched off. The currently implemented method is also available as axbScaling". For future use, other choices can easily be added.
### What does success look like, and how can we measure that?
Problem: The necessary effort (i.e. iterations) for the linear solvers should depend on the dynamics of the physical processes. The current normalization hinders that.
Example:
Unzip the example and run scalarTransportFoam. It is a simple example for a tracer transport, with a tracer injection starting at t=0.1 s. In the time < 0.1 s, only the initial value of tracer is in the system (very small) and is unchanged. Thus the solver should spend minimal effort. In the current implementation, the first initial residual is rescaled to 1 and unexplicably drops until t=0.1 s. The linear solver spends 5-8 unnecessary iterations in each time step. This is unwanted. After the tracer injection started, the number of iterations stays in the same range, while it should be higher then.
With the patch: Uncomment "residualNormalization" in system/fvSolution/solvers and re-run scalarTransportFoam.
Result: The solver spends zero iterations before the injection starts, because the initial residual are very low. After injection (t=0.1s), the iterations increase.
### Links / references
Example:
[o2112_example_scalarTransportFoam.zip](/uploads/dc6ab6eff55251eae6a76053b5a2517c/o2112_example_scalarTransportFoam.zip)
Patches:
[o2112_patches.zip](/uploads/6b0df79bd3107781b4b56ec62d53b6f6/o2112_patches.zip)
### Funding
The requested functionality has been implemented and tested. Both are attached (see above).
The diff of lduMatrixSolver.C is here:
[diff.txt](/uploads/d9e1075ca5bac7253409594edbe3ca44/diff.txt)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2312linearTsubDiameter, Anglart, H., Nylund, O., Kurul, N., & Podowski, M. Z. (1997)2022-05-06T10:01:48ZRobin KamenickylinearTsubDiameter, Anglart, H., Nylund, O., Kurul, N., & Podowski, M. Z. (1997)<!--
*** 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
The definition of bubble diameter in linearTsubDiameter.C seems to be faulty. There are two issues. First, wrongly calculated subcooling temperature. The value is negative if subcooling appears, yet it should be positive. That results in constant maximum diameter at subcooled temperatures and diameter decrease with superheating. The default values of subcooling temperature in OpenFOAM are defined as positive, in contrast with calculated values. Second, the linear interpolation to get the actual diameter is not correct.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
I attach two python codes plotting the actual diameter against subcooling temperature. The original version is coded in anglartNylund_OF.py and the fix in anglartNylund_fix.py.
[anglartNylund_OF.py](/uploads/50f4733f2c5adaf1f723590572b571a4/anglartNylund_OF.py)
[anglartNylund_fix.py](/uploads/e2ca205e61053f3bc5f10d277c3fd999/anglartNylund_fix.py)
In the plot from anglartNylund_OF.py, it is noticeable, that the actual diameter reaches its minimum at 11.5 K subcool (actually superheat) and higher. Although it should reach it just at 13.5 K.
The second file anglartNylund_fix.py give already fixed results.
Let me know if you need to demonstrate the effect of wrongly calculated subcooling within OpenFOAM. However, I believe it is quite clear.
<!-- How one can reproduce the issue - this is very important -->
### Example case
N/A
<!--
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?
Described above
<!-- What actually happens -->
### What is the expected *correct* behavior?
Described above
<!-- What you should see instead -->
### Relevant logs and/or images
N/A
<!--
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|v1912|v2006|v2012|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : OpenFOAM-v2012
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
Change following code
```
void Foam::diameterModels::linearTsub::correct()
{
// Lookup the fluid model
const phaseSystem& fluid =
refCast<const phaseSystem>
(
phase_.mesh().lookupObject<phaseSystem>("phaseProperties")
);
const phaseModel& liquid(fluid.phases()[liquidPhaseName_]);
if (phase_.mesh().foundObject<saturationModel>("saturationModel"))
{
const saturationModel& satModel =
phase_.mesh().lookupObject<saturationModel>("saturationModel");
const volScalarField Tsub
(
liquid.thermo().T() - satModel.Tsat(liquid.thermo().p())
);
d_ = max
(
d1_,
min
(
d2_,
(d1_*(Tsub - Tsub2_) + d2_*(Tsub - Tsub1_))/(Tsub2_ - Tsub1_)
)
);
}
}
```
into
```
void Foam::diameterModels::linearTsub::correct()
{
// Lookup the fluid model
const phaseSystem& fluid =
refCast<const phaseSystem>
(
phase_.mesh().lookupObject<phaseSystem>("phaseProperties")
);
const phaseModel& liquid(fluid.phases()[liquidPhaseName_]);
if (phase_.mesh().foundObject<saturationModel>("saturationModel"))
{
const saturationModel& satModel =
phase_.mesh().lookupObject<saturationModel>("saturationModel");
const volScalarField Tsub
(
satModel.Tsat(liquid.thermo().p()) - liquid.thermo().T()
);
d_ = max
(
d1_,
min
(
d2_,
(d1_*(Tsub - Tsub2_) - d2_*(Tsub - Tsub1_))/(Tsub1_ - Tsub2_)
)
);
}
}
```
Thus, flip saturation and liquid temperature at linearTsubDiameter.C:129 and change the equation on at linearTsubDiameter.C:138
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->https://develop.openfoam.com/Development/openfoam/-/issues/2067linesample function object does not work correctly if line crosses processor ...2021-10-05T10:53:40ZJeff Defoelinesample function object does not work correctly if line crosses processor boundaries### Summary
The linesample function object does not include all the data it should when the function object is executed in parallel and the line crosses processor boundaries. Specifically, it seems that a given processor will not be "re...### Summary
The linesample function object does not include all the data it should when the function object is executed in parallel and the line crosses processor boundaries. Specifically, it seems that a given processor will not be "revisited" so that if a line begins, for example, on processor0, then enters processor1, then returns to processor0, only the portion of the line up to the point where it re-enters processor0 will actually be written to the output .xy file in the postProcessing/linesample folder.
### Steps to reproduce
1. Decompose any case
2. Identify processor boundaries using postProcess -parallel -func processorField and then visualize in paraview.
3. Define a linesample function object in controlDict which has more than 1 separate segment within a given processor's mesh region
4. Execute the function object (doesn't matter if it is executed during solver run or via <solver> -postProcess -parallel).
### Example case
I have a case of ~100k cells that exhibits this problem, I have attached it. It includes decomposed (4 processors) mesh and fields for a single step (1350). Recomposing the case and executing simpleFoam -postProcess -latestTime creates the line samples as intended. Executing mpirun -np 4 simpleFoam -postProcess -parallel -latestTime demonstrates the bug for the "line1" postProcessing output. [sigma0.5_dsCelltoUsCellRatio0.5_ifaceLoc1.5_phi0.577_incidence-8_steadyDone_example.tar.xz](/uploads/4702e3d1bfc67deff46de35e8dd80dbe/sigma0.5_dsCelltoUsCellRatio0.5_ifaceLoc1.5_phi0.577_incidence-8_steadyDone_example.tar.xz)
### What is the current *bug* behaviour?
Linesample data saved stops once the line "reenters" a previously-visited processor region.
### What is the expected *correct* behavior?
Complete line is written.
### Relevant logs and/or images
No errors given. Image showing line location and how it crosses processor bounds twice within paraview attached. ![Screenshot_from_2021-04-16_22-19-04](/uploads/9dfa2c98909c0274695f9582d9fb56a4/Screenshot_from_2021-04-16_22-19-04.png)
### Environment information
OpenFOAM version : v2012
Operating system : ubuntu, also tested on other distributions
Hardware info : tested on multiple x86_64 systems
Compiler : gcc
### Possible fixes
I am not an OpenFOAM coding expert, so I don't know how to fix this.https://develop.openfoam.com/Development/openfoam/-/issues/236link/compilation error2016-09-19T05:32:30ZAdminlink/compilation errorI have got a compilation error on my Linux (Suse tumbleweed) machine (all the environmental variables are set correctly , etc.)
/home/walter/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/src/finiteVolume/fields/fvsPatchField...I have got a compilation error on my Linux (Suse tumbleweed) machine (all the environmental variables are set correctly , etc.)
/home/walter/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/src/finiteVolume/fields/fvsPatchFields/basic/calculated/calculatedFvsPatchFields.o: file not recognized: File truncated
collect2: error: ld returned 1 exit status
make: *** [/home/walter/OpenFOAM/OpenFOAM-v1606+/wmake/makefiles/general:157: /home/walter/OpenFOAM/OpenFOAM-v1606+/platforms/linux64GccDPInt32Opt/lib/libfiniteVolume.so] Error 1
Any clues ?
Thank You.https://develop.openfoam.com/Development/openfoam/-/issues/2424linking of twoPhaseProperties missing for windows version2022-04-01T09:12:47ZPrashant Sonakarlinking of twoPhaseProperties missing for windows versioncross reference: EP#1864
On Windows OpenFOAM 2112 version we get error as,
```
--> FOAM FATAL IO ERROR: (openfoam-2112)
Unknown patchField type constantAlphaContactAngle for patch type wall
Valid patchField types :
120
(
```
Could b...cross reference: EP#1864
On Windows OpenFOAM 2112 version we get error as,
```
--> FOAM FATAL IO ERROR: (openfoam-2112)
Unknown patchField type constantAlphaContactAngle for patch type wall
Valid patchField types :
120
(
```
Could be reproduced on tutorials/multiphase/interFoam/laminar/capillaryRise
Workaround:
- Load library by -lib twoPhaseProperties
- or via including it in controlDict
@markhttps://develop.openfoam.com/Development/openfoam/-/issues/2695Links in snappyHexMesh section in online userguide not working2023-03-14T17:10:27ZJohan RoenbyLinks in snappyHexMesh section in online userguide not workingGo here:
https://www.openfoam.com/documentation/user-guide/4-mesh-generation-and-conversion#x14-570004.4.7
and try to click "4.4 Mesh generation with the snappyHexMesh utility" or any of its subsections.
I tried in Chrome and Firefox ...Go here:
https://www.openfoam.com/documentation/user-guide/4-mesh-generation-and-conversion#x14-570004.4.7
and try to click "4.4 Mesh generation with the snappyHexMesh utility" or any of its subsections.
I tried in Chrome and Firefox where nothing happens when I click the links.https://develop.openfoam.com/Development/openfoam/-/issues/2628Link to source files doesn't work2024-01-10T11:06:28ZTorquil SørensenLink to source files doesn't workWhen using the documentation at https://www.openfoam.com/documentation/guides/latest/api, whenever I click on a link to a source file (*.C), I get a "file not found" web page. E.g, consider the following documentation page:
https://www....When using the documentation at https://www.openfoam.com/documentation/guides/latest/api, whenever I click on a link to a source file (*.C), I get a "file not found" web page. E.g, consider the following documentation page:
https://www.openfoam.com/documentation/guides/latest/api/semiPermeableBaffleMassFractionFvPatchScalarField_8C.html
Under "Detailed Description", there is a link "semiPermeableBaffleMassFractionFvPatchScalarField.C" to https://develop.openfoam.com/Development/OpenFOAM-plus/blob/OpenFOAM-v2112/src/thermoTools/derivedFvPatchFields/semiPermeableBaffle/semiPermeableBaffleMassFraction/semiPermeableBaffleMassFractionFvPatchScalarField.C
But this link doesn't work. I am sent to a "404 page not found" error page.
The same happens when I click on any such link to a *.C-file on any of the documentation pages.
Thankfully, the link further up "Go to the source code of this file" does work.https://develop.openfoam.com/Development/openfoam/-/issues/1584link to the verification of the tutorial case surfaceMounrtedCube2020-02-12T17:31:43ZSon Volink to the verification of the tutorial case surfaceMounrtedCubeThe link to the verification of the case surfaceMountedCube is stated here:
https://develop.openfoam.com/Development/openfoam/blob/develop/tutorials/incompressible/pimpleFoam/LES/surfaceMountedCube/README
The link is
openfoam.com/docu...The link to the verification of the case surfaceMountedCube is stated here:
https://develop.openfoam.com/Development/openfoam/blob/develop/tutorials/incompressible/pimpleFoam/LES/surfaceMountedCube/README
The link is
openfoam.com/documentation/cpp-guide/html/verification-validation-turbulent-surface-mounted-cube.html
but cannot be found in the internet.
Son.v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1077Link to wrong source file on the van Driest delta doxygen page2019-01-09T12:56:36ZAdminLink to wrong source file on the van Driest delta doxygen pageHere
[https://www.openfoam.com/documentation/cpp-guide/html/guide-turbulence-les-delta-vandriest.html](https://www.openfoam.com/documentation/cpp-guide/html/guide-turbulence-les-delta-vandriest.html)
under Further information, the link ...Here
[https://www.openfoam.com/documentation/cpp-guide/html/guide-turbulence-les-delta-vandriest.html](https://www.openfoam.com/documentation/cpp-guide/html/guide-turbulence-les-delta-vandriest.html)
under Further information, the link goes to the `cubeRootVolDelta` class, but should instead go to the `vanDriestDelta` class.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1489LiquidEvaporationBoil spalding number defined on molar basis2019-12-24T10:34:28ZAdminLiquidEvaporationBoil spalding number defined on molar basisIn OpenFOAM-2.4.0 at **src/lagrangian/intermediate/submodels/Reacting/PhaseChangeModel/LiquidEvaporationBoil/LiquidEvaporationBoil.C**
line 318:
dMassPC[lid] += pi d Sh Dab rhos log(1.0 + Xr) dt;
where d is the droplet diameter, Sh is...In OpenFOAM-2.4.0 at **src/lagrangian/intermediate/submodels/Reacting/PhaseChangeModel/LiquidEvaporationBoil/LiquidEvaporationBoil.C**
line 318:
dMassPC[lid] += pi d Sh Dab rhos log(1.0 + Xr) dt;
where d is the droplet diameter, Sh is the Sherwood number (Sh(Re,Sc)), Dab the vapor diffusivity assuming properties at the film, rhos the density at the film and Xr (line313):
// molar ratio
const scalar Xr = (Xs - Xc)/max(SMALL, 1.0 - Xs);
The units of dMassPC are in kg. However, the dimensionless group Xr is expressed in terms of molar fractions.
In literature, Xr is better known as the Spalding mass number (BM) where the ratio is expressed in terms of mass fractions rather than molar fractions [1,2]
I wonder if there is an implementation reason, which I do not see immediately, or if this is an implementation issue that should be fixed in order to correctly predict the evaporation rate.
Thank you in advance for your support and reply.
Alessandro
[1] Sergei S. Sazhin, Advanced models of fuel droplet heating and evaporation, Progress in Energy and Combustion Science, Volume 32, Issue 2, 2006.
[2] Patrick Jenny, Dirk Roekaerts, Nijso Beishuizen, Modeling of turbulent dilute spray combustion, Progress in Energy and Combustion Science, Volume 38, Issue 6, 2012.
\## Reattaching the author to the issue ticket: @pappo1890 ##https://develop.openfoam.com/Development/openfoam/-/issues/630LList constructors not explicit2018-01-04T09:15:12ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comLList constructors not explicitFollowing compiles ok:
vectorList n(vector::zero)
goes through linked list constructor (LList with single arg) and back to straight List.Following compiles ok:
vectorList n(vector::zero)
goes through linked list constructor (LList with single arg) and back to straight List.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/364lnInclude directory sometimes empty2018-05-29T05:39:49ZMark OLESENlnInclude directory sometimes emptyUncertain to the origins, but could be related to interrupted builds.
As discussed (@andy) probably reasonable to use '-u' whenever there is an explicit use of wmakeLnInclude.Uncertain to the origins, but could be related to interrupted builds.
As discussed (@andy) probably reasonable to use '-u' whenever there is an explicit use of wmakeLnInclude.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2437Loading external library (preCICE coupling library)2022-04-23T07:49:26ZPaul BrousseauLoading external library (preCICE coupling library)Hi,
We are trying to use the coupling-codes-library preCICE with Openfoam-v2112, compiled from source and without `thirdParty`, on a cluster with this distribution:
```
Distributor ID: CentOS
Description: CentOS Linux release 7.8.2003 ...Hi,
We are trying to use the coupling-codes-library preCICE with Openfoam-v2112, compiled from source and without `thirdParty`, on a cluster with this distribution:
```
Distributor ID: CentOS
Description: CentOS Linux release 7.8.2003 (Core)
Release: 7.8.2003
Codename: Core
```
PreCICE developers seem to think that our Openfoam compilation is the cause of the problem. Indeed this error occurs when loading the external library in the `controlDict`:
```
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in /lib64/libpthread.so.0
#3 ? in /opt/ohpc/pub/libs/gnu8/openmpi3/trilinos/12.14.1/lib/libteuchoscore.so.12
#4 ? in /lib64/ld-linux-x86-64.so.2
#5 ? in /lib64/ld-linux-x86-64.so.2
#6 ? in /lib64/ld-linux-x86-64.so.2
#7 ? in /lib64/ld-linux-x86-64.so.2
#8 ? in /lib64/libdl.so.2
#9 ? in /lib64/ld-linux-x86-64.so.2
#10 ? in /lib64/libdl.so.2
#11 dlopen in /lib64/libdl.so.2
#12 Foam::dlOpen(Foam::fileName const&, bool) at ??:?
#13 Foam::dlOpen(Foam::fileName const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&) at ??:?
#14 Foam::dlLibraryTable::openLibrary(Foam::fileName const&, bool) at ??:?
#15 Foam::dlLibraryTable::open(Foam::fileName const&, bool) at ??:?
#16 bool Foam::dlLibraryTable::open<Foam::HashTable<Foam::autoPtr<Foam::functionObject> (*)(Foam::word const&, Foam::Time const&, Foam::dictionary const&), Foam::word, Foam::Hash<Foam::word> >*>(Foam::dictionary const&, Foam::word const&, Foam::HashTable<Foam::autoPtr<Foam::functionObject> (*)(Foam::word const&, Foam::Time const&, Foam::dictionary const&), Foam::word, Foam::Hash<Foam::word> >* const&, bool) at ??:?
#17 Foam::functionObject::New(Foam::word const&, Foam::Time const&, Foam::dictionary const&) at ??:?
#18 Foam::functionObjectList::read() at ??:?
#19 Foam::Time::run() const at ??:?
#20 ? at ??:?
#21 __libc_start_main in /lib64/libc.so.6
#22 ? at ??:?
Exception en point flottant
```
In fact, simply loading the preCICE library (and not using it) makes OF crashes. Of course, OF works well alone.
Do you have any guess on where to look and how to debug this ?
Thanks !
Paulhttps://develop.openfoam.com/Development/openfoam/-/issues/1914Loading the OpenFOAM bashrc by default makes the Ubuntu 20.10 desktop unale t...2024-01-09T12:16:04ZGerasimos ChourdakisLoading the OpenFOAM bashrc by default makes the Ubuntu 20.10 desktop unale to load (X11-only)I stumbled upon a very weird issue that I can consistently reproduce on the same system. After installing OpenFOAM v2006 on Ubuntu 20.10 (see #1902) and adding `source "/usr/lib/openfoam/openfoam2006/etc/bashrc"` to my `~/.bashrc`, my de...I stumbled upon a very weird issue that I can consistently reproduce on the same system. After installing OpenFOAM v2006 on Ubuntu 20.10 (see #1902) and adding `source "/usr/lib/openfoam/openfoam2006/etc/bashrc"` to my `~/.bashrc`, my desktop fails to launch in X11, while it loads normally on Wayland.
There is no error, the system simply returns to the login screen after a few seconds. Removing this line from my `~/.bashrc` or making it an alias (so that I load it on demand) fixes the issue.
Any clue why this could happening? Can you reproduce it?https://develop.openfoam.com/Development/openfoam/-/issues/1532Local Time Stepping for High Aspect Ratio Cells2022-04-26T16:10:39ZLiamLocal Time Stepping for High Aspect Ratio CellsLocal Time stepping an extremely effective method to obtain steady state solutions to a variety of cases. However, in cases with high aspect ratio cells, the local time-step becomes extremely small. This occurs in a number of situations,...Local Time stepping an extremely effective method to obtain steady state solutions to a variety of cases. However, in cases with high aspect ratio cells, the local time-step becomes extremely small. This occurs in a number of situations, specifically in cases where a wall resolved simulation is required. As the mesh must be refined to Y+ < 1, the aspect ratio becomes very high and the simulation begins to converge very slowly.
It has been shown in literature, and in other CFD codes, that taking into account the aspect ratio of the cell can speed up the convergence of the computation significantly (by an order of magnitude). In my own experience, certain cases (airfoils/de Lave nozzles) with high Reynolds number and thus very small Y+ = 1 distance, had an acceleration of over 100 times making these simulations optimum for parametric studies or optimization.
Implementing this feature which takes into account the aspect ratio of the cell in computing the local time-step would alleviate the number of iterations required to converge the solution in these cases. Literature on this can be found:
https://arc.aiaa.org/doi/pdf/10.2514/6.2001-2557
Additionally, this has been implemented into ANSYS Fluent under the name of "Convergence Acceleration for Stretched Meshes (CASM)".
http://www.pmt.usp.br/ACADEMIC/martoran/NotasModelosGrad/ANSYS%20Fluent%20Theory%20Guide%2015.pdf (PDF Pg. 699)
https://support.ansys.com/staticassets/ANSYS/Conference/Dallas/downloads/fluid-dynamics-14.0-update.pdf (PDF Pg. 14)
http://www.pmt.usp.br/academic/martoran/notasmodelosgrad/ANSYS%20Fluent%20Users%20Guide.pdf (PDF Pg. 1499)
An appropriate test case, for example, would be: NACA0012 with a wall-resolved mesh and the appropriate turbulence model for a wall-resolved RAS simulation. Running this at a high Re number would help high-light the effectiveness. Run the simulation with and without this new feature. The results should be effectively identical however using this feature the simulation should required significantly fewer iterations.v2206https://develop.openfoam.com/Development/openfoam/-/issues/569locationInMesh specified in shmDict being ignored in favor of locationsInMesh2019-07-03T19:47:41ZAdminlocationInMesh specified in shmDict being ignored in favor of locationsInMeshI am having issues with snappy in 1706 - locationsInMesh is being used despite shmDict specifying locationInMesh.
We mesh automotive geometries, where we want a MRF cellZone for brake discs. These brake ducts have dozens of independent...I am having issues with snappy in 1706 - locationsInMesh is being used despite shmDict specifying locationInMesh.
We mesh automotive geometries, where we want a MRF cellZone for brake discs. These brake ducts have dozens of independent volume channels where a centroid can be outside the volume (total=100s per car), so specifying all locationsInMesh can't be automated - we use the original functionality of defining bounds to these channels via STL geometry. In all versions before 1706 this works fine.
However, in 1706, despite specifying locationInMesh and then providing the geometry for cellZones, locationsInMesh is what shows up in shm's log. Strangely, the faceZones are created, and are not empty. The MRF cellZones are also created, but no cells are assigned to them. I checked the extended code guide, where it shows both locationInMesh and locationsInMesh can be used, so I suspect this could be a bug?
**snappyHexMeshDict:**
> allowFreeStandingZoneFaces true;
locationInMesh (-1.5 -0.5 1.5);
internal_fluid_l_mrf_fr_wheel
{
level (8 8);
faceZone internal_l_mrf_fr_wheel;
faceType internal;
cellZone fluid_l_mrf_fr_wheel;
cellZoneInside inside;
}
**log from snappy** (anomolies to previous versions in boxes)
![snappyLog](/uploads/7efb9df21a47eaeab50e2c7e7e3446d2/snappyLog.png)
I've attached a small test case, just run the run_snappy.sh to reproduce (runs in minutes.) Log from when I run it locally is also attached.
[cellZoneProblem_testCase.zip](/uploads/9f16affbb2b99d49d8f1926f41885c11/cellZoneProblem_testCase.zip)[log.mesh.allMeshing](/uploads/efbf9d6753d975c35e08f9626878174d/log.mesh.allMeshing)https://develop.openfoam.com/Development/openfoam/-/issues/1043logical ops with odd return values.2018-10-17T15:40:45ZMark OLESENlogical ops with odd return values.In ops.H we have various operations defined, but things like `andOp`, `lessOp` etc should be returning bool.In ops.H we have various operations defined, but things like `andOp`, `lessOp` etc should be returning bool.Mark OLESENMark OLESEN