Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-01-13T14:27:25Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1553rRb definition in SchnerrSauer phase change model2020-01-13T14:27:25ZRiccardo RossirRb definition in SchnerrSauer phase change modelI'm dealing with a cavitation problem and started digging in the source code of phase change models available with the interPhaseChangeFoam solver.
While checking the rRb definition in the Schnerr and Sauer model:
return pow
(
...I'm dealing with a cavitation problem and started digging in the source code of phase change models available with the interPhaseChangeFoam solver.
While checking the rRb definition in the Schnerr and Sauer model:
return pow
(
((4*constant::mathematical::pi*n_)/3)
*limitedAlpha1/(1.0 + alphaNuc() - limitedAlpha1),
1.0/3.0
);
I've noticed the volume fraction of the liquid is used instead of the vapor one as in the definition of bubble radius from theory.
I feel like this would be too obvious to be an error/bug, so I was wondering what am I missing.https://develop.openfoam.com/Development/openfoam/-/issues/1552ReactingOneDim model diffusion number calculation not parallel consistent2020-02-02T17:18:48ZAndrew HeatherReactingOneDim model diffusion number calculation not parallel consistentThe `DiNum` value computed in the `solidRegionDiffNo` function is not parallel consistent and can lead to run failures, see:
https://develop.openfoam.com/Development/openfoam/blob/master/src/regionModels/pyrolysisModels/reactingOneD...The `DiNum` value computed in the `solidRegionDiffNo` function is not parallel consistent and can lead to run failures, see:
https://develop.openfoam.com/Development/openfoam/blob/master/src/regionModels/pyrolysisModels/reactingOneDim/reactingOneDim.C#L609v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1551yplus accommodetion for pisoFoam in LES wall model2020-01-13T10:31:50ZHaijing Panyplus accommodetion for pisoFoam in LES wall modelI'm doing LES model, but don't want to cost too much time on the first calculating, so I select the wall function, now it works normally, but I don't know how to choose a suitable wallfunction for my case and how to see whether the calcu...I'm doing LES model, but don't want to cost too much time on the first calculating, so I select the wall function, now it works normally, but I don't know how to choose a suitable wallfunction for my case and how to see whether the calculation is correct according to the yplus from each interaction.
I choose kqRwallFunction for k, nutUspaldingWallFunction and nutkWallFunction for nut, kEqn and Smagorinsky for LES model, so there are four cases now, and all of them are calculating now.
would any suggestion about my cases is welcome, thank youhttps://develop.openfoam.com/Development/openfoam/-/issues/1550BUG: compressible/rhoCentralFoam/LadenburgJet60psi always returns 0 residual ...2020-01-13T07:35:13ZKutalmış BerçinBUG: compressible/rhoCentralFoam/LadenburgJet60psi always returns 0 residual for rho*```
cd $FOAM_TUTORIALS/compressible/rhoCentralFoam/LadenburgJet60psi
blockMesh
rhoCentralFoam > log
```
Inspection of `log`, the first iteration:
```
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0...```
cd $FOAM_TUTORIALS/compressible/rhoCentralFoam/LadenburgJet60psi
blockMesh
rhoCentralFoam > log
```
Inspection of `log`, the first iteration:
```
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoUx, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoUy, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoUz, Initial residual = 0, Final residual = 0, No Iterations 0
smoothSolver: Solving for Ux, Initial residual = 2.72671585531381e-10, Final residual = 5.52189393354249e-17, No Iterations 2
smoothSolver: Solving for Uy, Initial residual = 8.9793398319517e-10, Final residual = 3.88308482399956e-17, No Iterations 2
smoothSolver: Solving for Uz, Initial residual = 2.46779639576239e-05, Final residual = 4.26968989376592e-17, No Iterations 2
diagonal: Solving for rhoE, Initial residual = 0, Final residual = 0, No Iterations 0
smoothSolver: Solving for e, Initial residual = 5.10620283617839e-10, Final residual = 2.0953930462529e-16, No Iterations 2
ExecutionTime = 0.04 s ClockTime = 0 s
```
Last iteration:
```
deltaT = 2.63043719245516e-09
Time = 2e-05
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoUx, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoUy, Initial residual = 0, Final residual = 0, No Iterations 0
diagonal: Solving for rhoUz, Initial residual = 0, Final residual = 0, No Iterations 0
smoothSolver: Solving for Ux, Initial residual = 5.96253571018462e-09, Final residual = 6.04621493842968e-17, No Iterations 2
smoothSolver: Solving for Uy, Initial residual = 1.94043363575857e-08, Final residual = 4.05549649159743e-17, No Iterations 2
smoothSolver: Solving for Uz, Initial residual = 1.22670886698518e-07, Final residual = 3.52512229257255e-17, No Iterations 2
diagonal: Solving for rhoE, Initial residual = 0, Final residual = 0, No Iterations 0
smoothSolver: Solving for e, Initial residual = 1.12199018788273e-08, Final residual = 2.11044025910839e-16, No Iterations 2
ExecutionTime = 78.01 s ClockTime = 78 s
```
@Prashant , would you please mind to run this tutorial in one of the old versions, if you have an installation, e.g. 1706? It runs fairly quickly.
#1531v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1549BUG: wrong bounding of sensitivity contituents in case of many control boxes2020-01-09T21:04:43ZVaggelis PapoutsisBUG: wrong bounding of sensitivity contituents in case of many control boxes<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
When more than one volumetric B-Splines control boxes are present, the sensitivity constituents corresponding to the non-active design variables are not bounded(zeroed) correctly. The resultant sensitivities, used in the optimization, are bounded correctly, so this is more a bug pertaining to the output file of the sensitivities rather than a functional one.
Things work as intended in the presence of a single volumetric B-Splines control box.Vaggelis PapoutsisVaggelis Papoutsishttps://develop.openfoam.com/Development/openfoam/-/issues/1548Not a valid INTELMPI installation directory2020-01-09T08:03:32ZHaijing PanNot a valid INTELMPI installation directoryI'm using paralleling computing in the HPC, but now I found I can't login normally and there is an error hint about it. However, I don't do any modification and it can work normally before this unexpected problem coming. Could anyone giv...I'm using paralleling computing in the HPC, but now I found I can't login normally and there is an error hint about it. However, I don't do any modification and it can work normally before this unexpected problem coming. Could anyone give me some suggestions about how to deal with it, thank you.![image](/uploads/29fbf0aa68dbec0e38bc6ea30463b8b9/image.png)https://develop.openfoam.com/Development/openfoam/-/issues/1546OpenFOAM v1912 mpirun killed due to memory shortage2020-01-16T17:56:48ZpanagiotisOpenFOAM v1912 mpirun killed due to memory shortageWhen I run an external aero case (70M cells) with porosity in OF v1906 **it runs normally**.
When I switch to OF v1912 it crashes in the beginning and gives the following error:
"Starting time loop
Time = 1
--------------------------...When I run an external aero case (70M cells) with porosity in OF v1906 **it runs normally**.
When I switch to OF v1912 it crashes in the beginning and gives the following error:
"Starting time loop
Time = 1
--------------------------------------------------------------------------
mpirun noticed that process rank 111 with PID 21978 on node node001 exited on signal 9 (Killed).
--------------------------------------------------------------------------
Some error occured in calculation.(error code=137)"
Info from cluster:
"Out of memory: Kill process 21978 (porousSimpleFoa) score 8 or sacrifice child
[4825555.767487] Killed process 21978 (porousSimpleFoa) total-vm:1900080kB, anon-rss:537616kB, file-rss:8280kB"https://develop.openfoam.com/Development/ThirdParty-common/-/issues/49issues with ptscotch and mingw2020-06-26T08:12:25ZMark OLESENissues with ptscotch and mingwAppears that we might need the following in the Makefile:
```
CCD = gcc -I$(MPI_ARCH_PATH)/include
```
@PawanAppears that we might need the following in the Makefile:
```
CCD = gcc -I$(MPI_ARCH_PATH)/include
```
@PawanMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1545Binary file compatibility not working with collated file format2021-07-06T16:47:55ZMortesinsBinary file compatibility not working with collated file format<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
The binary file compatibility that handles the reading of different precision or label sizes does not work when using the collated file format.
### Steps to reproduce
-Create a mesh in DP with the collated file format.
-Run a solver in SP.
### What is the current *bug* behaviour?
A ```FOAM FATAL IO ERROR``` occurs when trying to read the mesh and the binary crashes. Note that the same case with the uncollated file format works.
### What is the expected *correct* behavior?
The binary in SP should be able to read the DP mesh.
### Relevant logs and/or images
```
Create mesh for time = 0
[9]
[9]
[9] --> FOAM FATAL IO ERROR:
[9] Expected a ')' while reading binaryBlock, found on line 2: word '�ʩ���
[9]
[9] file: /path_to_case/processors128/constant/polyMesh/points at line 2.
[9]
[9] From function bool Foam::Istream::readEnd(const char*)
[9] in file db/IOstreams/IOstreams/Istream.C at line 134.
[9]
FOAM parallel run exiting
[9]
```
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1912
- Operating system : CentOS Linux 7
- Hardware info :
- Compiler : Gcc 4.8.5Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1544pressure function object v19122020-01-08T10:41:47ZPacific ESIpressure function object v1912<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
The v1912 pressure function object fails if hydrostatic pressures are applied for incompressible cases. The reason is that the pressure field created in calcPressure and that is the only parameter to function addHydrostaticContribution always has dimensions dimPressure and can never be kinematic pressure. Function rhoScale is called from addHydrostaticContribution and checks the dimensions of the pressure field to decide whether to multiply a second field by the volScalarField rho (if dimPressure) or the by the scalar rhoInf. It can never multiply by rhoInf as the pressure always has dimensions dimPressure. It tries to retrieve a volScalarField called rhoInf and crashes as the field does not exist.
It would also help to list g and hRef in the documentation as optional parameters for the function object when hydrostaticMode applies.
<!-- Summarize the bug encountered concisely -->
### 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?
The software crashes when a volScalarField called rhoInf is not found.
<!-- What actually happens -->
### What is the expected *correct* behavior?
<!-- What you should see instead -->
It should not crash!
### 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 : v1912
- Operating system : Centos 7
- Hardware info :
- Compiler : gcc 8.3
### Possible fixes
1. In the 2-parameter rhoScale function check whether rhoInfInitialised_ is true. If so, use rhoInf, otherwise use rho.
Or, more in keeping with the current code:
2. Have 2 input parameters to addHydrostaticContribution(p,result) where p is the unmodified input pressure field and result is the pressure field created in calcPressure. In addHydrostaticContribution use p as the first parameter to rhoScale while rgh is added or subtracted from result and returned.
<!--
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/1543checkMesh pyramid volume2021-07-06T16:47:06ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh pyramid volume### Functionality to add/problem to solve
checkMesh -writeAllFields does not output pyramid volume
### Target audience
This would be useful for debugging snappyHexMesh behaviour### Functionality to add/problem to solve
checkMesh -writeAllFields does not output pyramid volume
### Target audience
This would be useful for debugging snappyHexMesh behaviourMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1542checkMesh aspect ratio2024-01-10T16:47:46ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcheckMesh aspect ratio### Functionality to add/problem to solve
checkMesh calculates an aspect ratio in the global coordinate system. More relevant would probably using a cell-local coordinate system.
### Proposal
Use the cell-local coordinate system calc...### Functionality to add/problem to solve
checkMesh calculates an aspect ratio in the global coordinate system. More relevant would probably using a cell-local coordinate system.
### Proposal
Use the cell-local coordinate system calculation from e.g. the cellDeterminant check and determine the aspect ratio in that.
### What does success look like, and how can we measure that?
Make e.g. cavity with a lot of grading. See if the reported aspect ratio changes if the case is rotated (e.g. using `transformPoints -rotate`)https://develop.openfoam.com/Development/openfoam/-/issues/1541paraview 5.6.3 in 1912 compilation fail2020-01-23T16:24:40ZMatej Formanparaview 5.6.3 in 1912 compilation failOn VirtualBox, new latest Ubuntu installation following all prerequisites, having OpenFOAM-v1912 compiled,
in ThirdParty-v1912 running:
```
./makeParaView
```
returns:
```
./makeParaView: 64: local: -DWM_DP: bad variable name
./makePar...On VirtualBox, new latest Ubuntu installation following all prerequisites, having OpenFOAM-v1912 compiled,
in ThirdParty-v1912 running:
```
./makeParaView
```
returns:
```
./makeParaView: 64: local: -DWM_DP: bad variable name
./makeParaView: 64: -DOPENFOAM: bad variable name
```https://develop.openfoam.com/Development/openfoam/-/issues/1540BUG: continuation of updateMethods with empty activeDesignVariables2020-01-03T09:43:15ZVaggelis PapoutsisBUG: continuation of updateMethods with empty activeDesignVariables<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
When activeDesignVariables are not set explicitly, all design variables
are treated as active. These are allocated properly when starting from
0 but not when starting from an intermediate optimisation cycle
(e.g. running 5 optimisation cycles, stopping and restarting).
The bug affects the BFGS, DBFGS, LBFGS, SR1, SQP and conjugateGradient updateMethods.
### Steps to reproduce
1. Copy an optimisation case using BFGS, say $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/sbend/turbulent/opt/BFGS/op1
2. Comment out the *activeDesignVariables* in *optimisationDict*.
3. Run for a number of optimisation cycles using *adjointOptimisationFoam*, say 5.
4. Change the *endTime* to 10, to run another 5 optimisation cycles and re-run *adjointOptimisationFoam*. The solver will crash upon trying to compute the update of the design variables since the *activeDesignVariables* list will be empty.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1538BUG: writeMorpherCPs expects a controlBoxes entry2020-01-03T09:43:42ZVaggelis PapoutsisBUG: writeMorpherCPs expects a controlBoxes entry<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
The *writeMorpherCPs* preProcessing utility expects a *controlBoxes* entry in volumetricBSplinesMotionSolverCoeffs, within dynamicMeshDict. NURBS3DVolume no longer expects this entry (defeatured before release) but *writeMorpherCPs* was not updated accordingly.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1537BUG: Wrong FatalIOError message in displacementMethod and optMeshMovement2020-01-03T09:44:02ZVaggelis PapoutsisBUG: Wrong FatalIOError message in displacementMethod and optMeshMovement<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
The core of the FatalIOError message, including the table of contents of the base class, is not printed by displacementMethod::New and optMeshMovement::New due to exiting the FatalIOError call with exit(FatalError) instead of exit(FatalIOError).
### Steps to reproduce
Enter a non-valid displacementMethod (in dynamicMeshDict) or meshMovement type (in optimisationDict) in any of the tutorials under $FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation.
### What is the current *bug* behaviour?
No error message content is printed, only the Fatal Error line.
### What is the expected *correct* behavior?
The full FatalError message, including the toc of the base class should be printed.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1535Thermal resistance in turbulentTemperatureRadCoupledMixed boundary conditions...2021-10-18T18:22:52ZLieven VerveckenThermal resistance in turbulentTemperatureRadCoupledMixed boundary conditions not working properly### Summary
When defining thicknessLayers and kappaLayers in the turbulentTemperatureRadCoupledMixed boundary conditions, energy conservation over the interface is broken, resulting in wrong temperatures at the interface and inside the ...### Summary
When defining thicknessLayers and kappaLayers in the turbulentTemperatureRadCoupledMixed boundary conditions, energy conservation over the interface is broken, resulting in wrong temperatures at the interface and inside the domain. Exactly the same settings in combination with turbulentTemperatureCoupledBaffleMixed produce the correct results.
### Steps to reproduce
Run a multi-region heat transfer case using chtMultiRegion(Simple)Foam with turbulentTemperatureRadCoupledMixed in combination with one or more thermal resistance layers at the interface. Radiation is switched off.
### Example case
Attached, a simple 2-region conduction case is added. The regions are 'leftSolid' and 'rightSolid'. Both have a length of 1m. A 1kW heat flux is imposed at heatFluxWall in leftSolid, a fixed temperature of 300K is imposed at fixedTWall in rightSolid. At the interface (leftSolid_to_rightSolid and rightSolid_to_leftSolid) a thermal resistance with kappa 0.1 and thickness 0.001 is added. Four different 0-folders are added for comparison, switch between turbulentTemperatureRadCoupledMixed and turbulentTemperatureCoupledBaffleMixed and switching the resistance on and off.
Analytically, the temperatures including thermal resistance are:
fixedTWall = 300
rightSolid_to_leftSolid = 312.5
leftSolid_to_rightSolid = 322.5
heatFluxWall = 335
turbulentTemperatureCoupledBaffleMixed reproduces these values, turbulentTemperatureRadCoupledMixed does not.
[resistance.tar.gz](/uploads/b6f1798442502445cfdea4bbd698c43b/resistance.tar.gz)
### What is the current *bug* behaviour?
See example case. turbulentTemperatureCoupledBaffleMixed reproduces the correct temperatures, turbulentTemperatureRadCoupledMixed does not.
### Relevant logs and/or images
Output of the last iteration when running the test case.
*Output with turbulentTemperatureCoupledBaffleMixed:*
Solving for solid region leftSolid
DICPCG: Solving for h, Initial residual = 9.282926e-10, Final residual = 9.282926e-10, No Iterations 0
Min/max T:**322.5 335**
Solving for solid region rightSolid
DICPCG: Solving for h, Initial residual = 8.370484e-10, Final residual = 8.370484e-10, No Iterations 0
Min/max T:300 312.5
ExecutionTime = 0.99 s ClockTime = 2 s
*Output with turbulentTemperatureRadCoupledMixed:"
Solving for solid region leftSolid
DICPCG: Solving for h, Initial residual = 2.955242e-10, Final residual = 2.955242e-10, No Iterations 0
Min/max T:**322.375 334.875**
Solving for solid region rightSolid
DICPCG: Solving for h, Initial residual = 9.524563e-10, Final residual = 9.524563e-10, No Iterations 0
Min/max T:300 312.5
ExecutionTime = 1.03 s ClockTime = 1 s
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1906
- Operating system : CentOS 7
- Hardware info :
- Compiler :
### Possible fixes
I suspect the bug is related to the definition of TcNbr at line 206 in turbulentTemperatureRadCoupledMixedFvPatchScalarField.C, which is independent of contactRes_. In turbulentTemperatureCoupledBaffleMixed, there is a dependency on constantRes_.https://develop.openfoam.com/Development/openfoam/-/issues/1533ENH: LambVector FO is expensive to compute2021-12-21T18:46:13ZKutalmış BerçinENH: LambVector FO is expensive to compute**Problem statement:**
`LambVector` expression is $`(\nabla \times \mathbf{u}) \times \mathbf{u}`$, which revealed to be expensive to compute.
**Problem solution:**
Equivalent expressions, and potential simplifications, e.g. for incompr...**Problem statement:**
`LambVector` expression is $`(\nabla \times \mathbf{u}) \times \mathbf{u}`$, which revealed to be expensive to compute.
**Problem solution:**
Equivalent expressions, and potential simplifications, e.g. for incompressible flow computations, may reduce the computational cost of `LambVector`.
Most of the time the divergence of `LambVector` is the actual field of interest rather than the `LambVector` itself.
Nevertheless, the divergence of `lambVector` is computed by an external `div` FO. Instead, $`\nabla \cdot ((\nabla \times \mathbf{u})\times \mathbf{u})`$ may be further reduced to a simpler form.v2112Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/48Compilation of paraview5.6.3 does not start.2020-07-22T11:05:07Zsariew8Compilation of paraview5.6.3 does not start.$ ~/OpenFOAM/ThirdParty-common$ ./makeParaView \
./makeParaView: 64: local: -DWM_DP: bad variable name \
./makeParaView: 64: ./makeParaView: -DOPENFOAM: bad variable name
did i make another mistakes?$ ~/OpenFOAM/ThirdParty-common$ ./makeParaView \
./makeParaView: 64: local: -DWM_DP: bad variable name \
./makeParaView: 64: ./makeParaView: -DOPENFOAM: bad variable name
did i make another mistakes?Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1530chtMultiRegionTwoPhaseEulerFoam: missing L parameters for restart2020-01-21T20:24:12ZPawan GhildiyalchtMultiRegionTwoPhaseEulerFoam: missing L parameters for restartI) Restarting the case from solution , ask for missing parameters L from Bromley model .
2)Switching the DebugSwitches i.e below one to 2 , lead solver failing with error. Please check with tutorial for
chtMultiRegionTwoPhaseEulerFo...I) Restarting the case from solution , ask for missing parameters L from Bromley model .
2)Switching the DebugSwitches i.e below one to 2 , lead solver failing with error. Please check with tutorial for
chtMultiRegionTwoPhaseEulerFoam
DebugSwitches
{
compressible::alphatWallBoilingWallFunction 2;
} Sergio FerrarisSergio Ferraris