Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-12-22T14:47:51Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2068update dependencies OpenSUSE Leap 15.22021-12-22T14:47:51ZRamkumarupdate dependencies OpenSUSE Leap 15.2Hi.. i am using OpenSUSE Leap 15.2 and would like to compile OpenFOAM on that.. but when i see the dependencies list, they are all provided for Leap 15.1 only and are being incompatible/not found during installation..
and my build fails...Hi.. i am using OpenSUSE Leap 15.2 and would like to compile OpenFOAM on that.. but when i see the dependencies list, they are all provided for Leap 15.1 only and are being incompatible/not found during installation..
and my build fails due to this in the middle.
could u plz update the dependencies and instructions for OpenSUSE Leap 15.2? as this release was made in July of 2020?Mark OLESENMark OLESENhttps://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/2066surfaceFieldValue is not exporting fields using sampledSurface2021-05-12T02:21:17Zzein elserfysurfaceFieldValue is not exporting fields using sampledSurface
### Summary
I am trying to save the velocity, pressure and rho on a rectangular surface. The surface is imported to OpenFOAM as STL file in the triSurface/constant.
These lines are added to the the contolDict file
```
surfaceFiel...
### Summary
I am trying to save the velocity, pressure and rho on a rectangular surface. The surface is imported to OpenFOAM as STL file in the triSurface/constant.
These lines are added to the the contolDict file
```
surfaceFieldValue1
{
type surfaceFieldValue;
libs ("libfieldFunctionObjects.so");
log true;
surfaceFormat foam;
writeControl writeTime;
timeStart 0;
writeInterval 1 ;
writeFields yes; // yes | no
writeArea yes;
regionType sampledSurface;
name sampledSurface;
sampledSurfaceDict
{
type sampledTriSurfaceMesh;
surface c-rect0.125c.stl;
source cells; // sample cells or boundaryFaces
interpolate true;
}
operation none;
fields (p);
}
```
The output log file does not show any problems with reading the function
`surfaceFieldValue surfaceFieldValue1:
operation = none
surfaceFormat = foam
`
The files output in the postProcessing folder is not including the surface directory for saved data
only folder name (surfaceFieldValue1) is generated contain one file (surfaceFieldValue.dat)
What could be the problem?is there a limit for STL file size? but also not error are shownhttps://develop.openfoam.com/Development/openfoam/-/issues/2065noise utility in parallel2021-04-16T11:56:15ZPrashant Sonakarnoise utility in parallelThe noise utility can operate without processor directories, which seem to have issues with v2012 onward
@mark @MattijsThe noise utility can operate without processor directories, which seem to have issues with v2012 onward
@mark @MattijsAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2064rhoCentralDyMFoam + maxwellSlipU = Crash2021-07-07T11:11:53ZMartin HeinrichrhoCentralDyMFoam + maxwellSlipU = Crash### Summary
Using `rhoCentralDyMFoam` to simulate a case with dynamic mesh and `maxwellSlipU` boundary condition results in immediate crash at the first time step.
### Steps to reproduce
Take the movingCone tutorial case for `rhoCentr...### Summary
Using `rhoCentralDyMFoam` to simulate a case with dynamic mesh and `maxwellSlipU` boundary condition results in immediate crash at the first time step.
### Steps to reproduce
Take the movingCone tutorial case for `rhoCentralDyMFoam` and change one of the slip boundary conditions for U to `maxwellSlipU`. Start the simulation.
### Example case
Here [movingCone.zip](/uploads/6e94b61f2b2068d2f465390c794fd27f/movingCone.zip) is said movingCone tutorial case with maxwellSlipU boundary condition. Just create the mesh with `blockMesh` and use `rhoCentralDyMFoam` to start the simulation.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2006, v2012
- Operating system : Linux
- Compiler : GCC
### Possible fixes
The reason for the crash is as following: at the beginning of the time loop, mesh.update() is called, where the velocity boundary field is updated: U.correctBoundaryConditions(). There, the maxwellSlipU boundary condition is called looking for the volTensorField tauMC. However, this volTensorField is created inside the time loop of rhoCentralDyMFoam after (!) mesh.update() is called. Therefore, it cannot be found.
A simple fix would be to create the volTensorField tauMC in createFields.H and then update it at its current position. Therefore, it would be present when mesh.update() calls the maxwellSlipU boundary condition at the very first time step.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2061Discrepancy with phi(mass flowrate) calculation at the patch with buoyantSimp...2021-07-07T11:11:28ZAngirekula VenuDiscrepancy with phi(mass flowrate) calculation at the patch with buoyantSimpleFoam solver.<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
The problem is related to the way OpenFOAM evaluates the phi(mass flowrate) at the patch with buoyantSimpleFoam solver. In my system, I implemented a codedFixedValue BC for inlet velocity, which enters into the space with some angle from the patch normal. However, the value of phi at the patch produced by the OF is less than the Original value. Upon observation, it seems that only the velocity component perpendicular to the patch was considered to generate the phi. Which disturbs the conservation of heat in the system.
### Steps to reproduce
I have implemented the velocity profile at the inlet patch in such way that all velocity vectors are entering into the space radially with 70deg from the patch normal, as shown in the attached image.
### ![Inlet_vectors](/uploads/43c8d3b0cefea6ebdcb3eab514a070aa/Inlet_vectors.png)Theoretically mass flowrate calculations:
- Volumetric flowrate of patch = 0.02831 m3/sec
- Inlet Temperature = 13 deg C
- Corresponding Density,rho = 1.238 kg/m3
- Supply mass flowrate = 0.03485 kg/sec
But from the OF, with 'flowRatePatch' utility, Mass flowrate = 0.01194 kg/sec.
Which is in accord with direct summation of 'phi' values on the patch. Nevertheless, there is large difference between the actual supply mass flowrate and OF generated flowrate.
Upon further investigation, based on "[compressibleCreatePhi.H](https://openfoam.com/documentation/guides/latest/api/compressibleCreatePhi_8H.html)" we found the calculation of phi
` surfaceScalarField phi
(
IOobject
(
"phi",
runTime.timeName(),
mesh,
IOobject::READ_IF_PRESENT,
IOobject::AUTO_WRITE
),
linearInterpolate(rho*U) & mesh.Sf()
);`
The calculation of phi on the face :
- The surface area vector, Sf ( 0,0,4.032e-05)
- The translated velocity vector,U ( 0.93872955,-0.042532896,-0.34202014)
- Mass flowrate = (Sf.U)*rho = (0 + 0 + 1.379e-05)*1.238
##Observations & Queries:
1. Why the phi calculations does not taking the contribution of components other than patch normal velocity.
2. Based in the above calculations, there is large difference between the actual supply mass flowrate and OF generated flowrate.
3. The generated low phi values have also impacted the heat balance of the system.
<!-- 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
-->
### Relevant logs and/or images
[ExampleCase.tar.xz](/uploads/e327b5339d8b7453ab327a349a010c55/ExampleCase.tar.xz)
<!--
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
- Operating system : Ubuntu 18.04Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2059sixDoFRigidBodyState functions does not work for overInterDyMFoam solver2022-08-02T16:23:18ZHua ZensixDoFRigidBodyState functions does not work for overInterDyMFoam solver<!--
*** 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 -->
sixDoFRigidBodyState functions does not work for overInterDyMFoam solver
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
1. the tutorial: tutorials/multiphase/overInterDyMFoam/floatingBody
2. in controlDict add the following in the functions:
sixDoFRigidBodyState
{
type sixDoFRigidBodyState;
libs (sixDoFRigidBodyState);
angleFormat degrees;
}
3. run the case with Allrun script.
### Example case
As above
<!--
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 -->
The solver fail to run.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
--> FOAM FATAL ERROR: (openfoam-2012)
Attempt to cast type dynamicOversetFvMesh to type dynamicMotionSolverFvMesh
From To& Foam::refCast(From&) [with To = const Foam::dynamicMotionSolverFvMesh; From = const Foam::objectRegistry]
in file /home/user/openfoam/BuildEnv/debian-build/bionic-2012.latest/scratch/src/OpenFOAM/lnInclude/typeInfo.H at line 139.
FOAM aborting
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::error::exitOrAbort(int, bool) at ??:?
#2 Foam::functionObjects::sixDoFRigidBodyState::write() at ??:?
#3 Foam::functionObjectList::execute() at ??:?
#4 Foam::Time::run() const at ??:?
#5 ? in /usr/lib/openfoam/openfoam2012/platforms/linux64GccDPInt32Opt/bin/overInterDyMFoam
#6 __libc_start_main in /lib/x86_64-linux-gnu/libc.so.6
#7 ? in /usr/lib/openfoam/openfoam2012/platforms/linux64GccDPInt32Opt/bin/overInterDyMFoam
Aborted (core dumped)
<!--
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 :v2012
- Operating system :Ubuntu 18.04
- Hardware info :
- Compiler :System
### 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
-->Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2058Windows OpenFOAM version not writing field files with name including ":"2024-01-10T10:58:10ZSandeepWindows OpenFOAM version not writing field files with name including ":"<!--
*** 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###
Field file names with ":" are not written in result folders
### Steps to reproduce
Run any simulation on windows with proudmanAcousticPower function object.
### Example case
Please check attached zip file as example for same
### What is the current *bug* behaviour?
It writes empty field file with name "proudmanAcousticPower", with 0kb size
### What is the expected *correct* behavior?
It should write two files "proudmanAcousticPower:L_P" and "proudmanAcousticPower:P_A"
### 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.
-->[proudmanAcousticPower.zip](/uploads/33bad9f2537c121066bd2339479115ae/proudmanAcousticPower.zip)
### 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 : OpenFOAM-v2012
- Operating system : Windows
- 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
-->Pawan GhildiyalPawan Ghildiyalhttps://develop.openfoam.com/Development/openfoam/-/issues/2057mapFieldsPar not execute on windows OS with source path in forward slashes2021-12-10T13:14:16ZYogesh DeshmukhmapFieldsPar not execute on windows OS with source path in forward slashes<!--
*** 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 -->
while executing mapFieldPar on windows 10 OS with openFOAM2012 gives error , if source path content forward slashes
### Steps to reproduce
Create two openFAOM directories which can be mapped. while giving path such as source path with forward slashes.
<!-- How one can reproduce the issue - this is very important -->
### Example case
Example case attached.
Unzip the attachment.
See two log files namely backward_shlash.log and forward_shlash.log inside mapField_Window_Forward_Slash_Issue\run_win folder.
"backward_shlash.log" this log file contains log with source path given with backward slashes.
"forward_shlash.log" this log file contains log with source path given with forward slashes.
<!--
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?
mapFiledsPar fail to execute
<!-- What actually happens -->
### What is the expected *correct* behavior?
mapFiledsPar should get execute
<!-- What you should see instead -->
user need to manually change the path which is very cumbersome.
### Relevant logs and/or images
See two log files namely backward_shlash.log and forward_shlash.log inside mapField_Window_Forward_Slash_Issue\run_win folder.
<!--
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 : v2012
- Operating system : Windows 10
- 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
-->
[mapField_Window_Forward_Slash_Issue.zip](/uploads/3576b46b2759a544d3843da67ad27796/mapField_Window_Forward_Slash_Issue.zip)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2054Question about GAMG solver strategy (only V cycles currently)2023-07-19T16:41:29ZMINHAO XUQuestion about GAMG solver strategy (only V cycles currently)### Functionality to add/problem to solve
I checked the source code of GAMG solver and found that there is only V cycle for multi-grid. From some literature it said that F and W cycly may convergence faster thant normal V cycle. My quest...### Functionality to add/problem to solve
I checked the source code of GAMG solver and found that there is only V cycle for multi-grid. From some literature it said that F and W cycly may convergence faster thant normal V cycle. My question is: why not add F and W cycle as an alternative? What are your worries?
(Brief scope)
### Target audience
GAMG are mainly used in solving matrics of pressure field and as I know it is always hard to convergence and costs much time in the whole solving proccess. So everyone who uses GAMG solver may nenifit from the changes.
(Who will benefit from the changes?)
(What type of cases?)
### Proposal
Add W and F cycle of multi-grid series solver.
(How are we going to solve the problem?)
### What does success look like, and how can we measure that?
add alternative cycles and api to let user choose own cycles.
(What are the success factors and acceptance criteria? e.g. test cases, error margins)
### Links / references
https://en.wikipedia.org/wiki/Multigrid_method
(Links to literature, supporting information)
### Funding
(Does the functionality already exist/is sponsorship available?)https://develop.openfoam.com/Development/openfoam/-/issues/2053Phase-constrained ScalarTransport only diffusive and not phase-constrained2022-01-31T15:19:13ZFranz DPhase-constrained ScalarTransport only diffusive and not phase-constrained<!--
*** 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
Using the scalarTransport function object with interFoam results in the scalar being "stuck in the air" (i.e. leaving the phase and not propagating any further). Furthermore, there is no convective transport of the scalar.
The issue is described e.g. in this post as well: https://www.cfd-online.com/Forums/openfoam-solving/234344-interfoam-scalar-transport-single-phase.html#post798013
### 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?
Scalar which should be phase-constrained leaves the phase. No convective transport.
Setting the diffusion coefficient D=0 will result in the scalar not being transported at all.
### What is the expected *correct* behavior?
Convective + Diffusive transport of scalar, scalar should not leave the defined phase.
### Relevant logs and/or images
See this post:
https://www.cfd-online.com/Forums/openfoam-solving/234344-interfoam-scalar-transport-single-phase.html#post798013
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version :
Operating system :
Compiler :
-->
- OpenFOAM version : v1912,v2006,v2012
- Operating system : Ubuntu
- Hardware info : various.
- Compiler : gcc
### Possible fixes
Maybe see https://www.cfd-online.com/Forums/openfoam-solving/234344-interfoam-scalar-transport-single-phase.html#post798013
And https://www.cfd-online.com/Forums/openfoam-solving/188437-foam-error-printstack-foam-ostream-interfoam-parallel-2.html#post797806
<!--
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
-->Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2052IsoAdvector unphysical alpha separation at sharp, high curvature boundary layers2024-01-09T12:13:52ZMartins KlevsIsoAdvector unphysical alpha separation at sharp, high curvature boundary layersI am using this library on a case that involves argon bubbles rising in liquid gallium. I have an issue where the alpha field "leaks" near the edges of the bubbles, and subsequently forms smaller bubbles roughly the size of a mesh cell. ...I am using this library on a case that involves argon bubbles rising in liquid gallium. I have an issue where the alpha field "leaks" near the edges of the bubbles, and subsequently forms smaller bubbles roughly the size of a mesh cell. This was way more intense with MULES, however using isoAdvector still doesn't solve it.
There are sharp gradients at the edges of the bubbles, however this separation shouldn't happen in my setup.
Here are some isoFaces that showcase this behaviour.
![iso_1_1](/uploads/9106fc5e1f56fb1d53a35ff18e516972/iso_1_1.png)
![iso_1_2](/uploads/2e62d63e33d28f81b2a529971e87134c/iso_1_2.png)
![iso_2_1](/uploads/6956d6bd343286690c5d4b669246ef79/iso_2_1.png)
![iso_2_2](/uploads/5508c6d85f9b369353d533c8cb79b1a8/iso_2_2.png)
![iso_3_1](/uploads/694c650c38aa4ddc653412d7e5a522ec/iso_3_1.png)
The isoFaces look weird to me. It looks like a second surface layer is forming at the "leakage" zone.
I have tweaked all of the main solver parameters for alpha and p_rgh fields, and it doesn't seem to help. Lowering the Courant number also doesn't help. My p_rghfinal is 1e-10 and soFaceTol is 1e-6 and surfCellTol is 1e-6. The artefact sizes seem to correlate with cell sizes. I have tested this in v6 and v2012.
Any help would be greatly appreciated.Henning ScheuflerHenning Scheuflerhttps://develop.openfoam.com/Development/openfoam/-/issues/2051Is Foam::multiphaseMixture::surfaceTensionForce() depends on phase order in t...2021-11-29T11:01:03ZRAHUL VADRABADEIs Foam::multiphaseMixture::surfaceTensionForce() depends on phase order in transportProperties?I am [debugging](https://github.com/Rvadrabade/Debugging-OpenFOAM-with-Visual-Studio-Code) multiphaseInterFoam solver to understand the underlying physics. However, it is observed that the order of phases in `constant/transportProperties...I am [debugging](https://github.com/Rvadrabade/Debugging-OpenFOAM-with-Visual-Studio-Code) multiphaseInterFoam solver to understand the underlying physics. However, it is observed that the order of phases in `constant/transportProperties.phases` affects the accurate calculation of surface tension force (`Foam::multiphaseMixture::surfaceTensionForce()`).
In spite of having contact angle boundary defined for air phase [alpha.air] with [original tutorial](https://develop.openfoam.com/Development/openfoam/-/blob/master/tutorials/multiphase/multiphaseInterFoam/laminar/damBreak4phase/constant/transportProperties), the `if(isA<alphaContactAngleFvPatchScalarField>(gbf[patchi]))` condition in `Foam::multiphaseMixture::correctContactAngle()` [ [multiphaseMixture.C ](https://develop.openfoam.com/Development/openfoam/-/blob/master/applications/solvers/multiphase/multiphaseInterFoam/multiphaseMixture/multiphaseMixture.C#L426) L:426] is always false.
Further, if the `air` phase defined first in constant/transportProperties.phases then Foam::multiphaseMixture::correctContactAngle() works as expected see attachment **damBreak4phaseModifiedCase**.
The effect of accurate calculation of surface tension force considering the contact angle might be very small. However, I would like to know if this behavior is as per the design of the multiphaseInterFoam solver and is as expected or there is scope for improvement?
[damBreak4phaseModifiedCase.zip](/uploads/f62f471485356710d6a890482bb5ff52/damBreak4phaseModifiedCase.zip)
[damBreak4phaseOriginalCase.zip](/uploads/3d9b0b5aa27c1f9f714c9bbacaa9e417/damBreak4phaseOriginalCase.zip)Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2047primitiveMesh::edgeFaces produces different results whether using cached or u...2021-07-01T09:37:08ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comprimitiveMesh::edgeFaces produces different results whether using cached or uncached data<!--
*** 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 -->
primitiveMesh::edgeFaces comes in two versions:
- calculate edgeFaces for all edges of the mesh. This is ok.
- calculate edgeFaces only for a single edge (i.e. uncached). This produces false positives for faces with difficult edge connectivity.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run attached test program on motorBike tutorial.
### What is the current *bug* behaviour?
<!-- What actually happens -->
For some edges the uncached version returns 3 faces whereas the proper one returns 2 faces.
### 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 : v2012
### 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
-->
We're looping through pointFaces to see the common faces. However we do not check the edge is an edge (i.e. using consecutive vertices) on all the faces.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2046splitMeshRegions : keep cellZones together2021-08-11T15:15:31ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsplitMeshRegions : keep cellZones together### Functionality to add/problem to solve
splitMeshRegions currently always puts each cellZone into its separate region. Allow keeping cellZones together.
### Target audience
Generating multi-region cases (e.g. cht) from a single mes...### Functionality to add/problem to solve
splitMeshRegions currently always puts each cellZone into its separate region. Allow keeping cellZones together.
### Target audience
Generating multi-region cases (e.g. cht) from a single mesh.
### Proposal
Add additional option.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/2045fvOptions SemiImplicitSource issue2024-01-09T12:14:22Zsung won choifvOptions SemiImplicitSource issueI am simulating a conjugate heat transfer problem using chtMultiRegionTwoPhaseEulerFoam, a simple case of a solid being cooled by a fluid. However no matter how much I increase the value of heat flux for the solid in fvOptions, the outle...I am simulating a conjugate heat transfer problem using chtMultiRegionTwoPhaseEulerFoam, a simple case of a solid being cooled by a fluid. However no matter how much I increase the value of heat flux for the solid in fvOptions, the outlet water temperature or the temperature of the solid just does not change. it seems to be openfoam is just ignoring fvOptions file. Maximum value of temperature at the solid and outlet water temperature remains the same as the initial value and just does not change no matter how much I change heat flux(or Power) value in fvOptions. Thanks for any advice. Regards (Please see the attached file[solidQuench37T-UP.zip](/uploads/43e6e1275839edb3ce8f7e2c7c006684/solidQuench37T-UP.zip). This model is using V-2012))https://develop.openfoam.com/Development/openfoam/-/issues/2044Add Function suggestion: Add Fujitsu-MPI for A64FX.2021-03-31T06:57:59ZTomoki, KaratsuAdd Function suggestion: Add Fujitsu-MPI for A64FX.Hello, @mark.
Thank you for your cooperation in adding the Fujitsu compiler before. This time I would like to add a process to recognize the Fujitsu MPI library on A64FX.
Can I submit the PR this community? If I don't have the right to ...Hello, @mark.
Thank you for your cooperation in adding the Fujitsu compiler before. This time I would like to add a process to recognize the Fujitsu MPI library on A64FX.
Can I submit the PR this community? If I don't have the right to submit a PR, could you incorporate the following fixes?
```
diff --git a/etc/bashrc b/etc/bashrc
index 763f165..a6daac7 100644
--- a/etc/bashrc
+++ b/etc/bashrc
@@ -90,7 +90,7 @@ export WM_COMPILE_OPTION=Opt
# [WM_MPLIB] - MPI implementation:
# = SYSTEMOPENMPI | OPENMPI | SYSTEMMPI | MPI | MPICH | MPICH-GM |
-# HPMPI | CRAY-MPICH | FJMPI | QSMPI | SGIMPI | INTELMPI | USERMPI
+# HPMPI | CRAY-MPICH | FJMPI | FJMPI-A64FX | QSMPI | SGIMPI | INTELMPI | USERMPI
# Specify SYSTEMOPENMPI1, SYSTEMOPENMPI2 for internal tracking (if desired)
# Can also use INTELMPI-xyz etc and define your own wmake rule
export WM_MPLIB=SYSTEMOPENMPI
diff --git a/etc/config.sh/mpi b/etc/config.sh/mpi
index 69617b1..7531cc8 100644
--- a/etc/config.sh/mpi
+++ b/etc/config.sh/mpi
@@ -297,6 +297,15 @@ FJMPI)
_foamAddLib /opt/FJSVpnidt/lib
;;
+FJMPI-A64FX)
+ export FOAM_MPI=fjmpi-a64fx
+ export MPI_ARCH_PATH="$MPI_ROOT"
+
+ export OPAL_PREFIX="$MPI_ARCH_PATH"
+
+ _foamAddPath "$MPI_ARCH_PATH"/bin
+ _foamAddLib "$MPI_ARCH_PATH"/lib64
+ ;;
QSMPI)
export FOAM_MPI=qsmpi
diff --git a/wmake/rules/General/mplibFJMPI-A64FX b/wmake/rules/General/mplibFJMPI-A64FX
index e69de29..6e2ae4f 100644
--- a/wmake/rules/General/mplibFJMPI-A64FX
+++ b/wmake/rules/General/mplibFJMPI-A64FX
@@ -0,0 +1,7 @@
+#------------------------------------------------------------------------------
+
+PFLAGS = -DMPICH_SKIP_MPICXX -DOMPI_SKIP_MPICXX
+PINC = -isystem $(MPI_ARCH_PATH)/include/mpi/fujitsu/
+PLIBS = -L$(MPI_ARCH_PATH)/lib64 -lmpi
+
+#------------------------------------------------------------------------------
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2043Renumbering mesh results in high non-orthogonality and skewness2021-04-15T08:57:40ZGhost UserRenumbering mesh results in high non-orthogonality and skewnessHello,
When I run the `checkMesh` utility in my case with the attached Grid `mesh.x`, it reports the following values of non-orthogonality and skewness (See the `checkMesh.beforeRenumbering` attached file for details):
**Before running...Hello,
When I run the `checkMesh` utility in my case with the attached Grid `mesh.x`, it reports the following values of non-orthogonality and skewness (See the `checkMesh.beforeRenumbering` attached file for details):
**Before running renumberMesh**:
```
Mesh non-orthogonality Max: 36.0957 average: 9.08335
Non-orthogonality check OK.
Face pyramids OK.
Max skewness = 2.03538 OK.
```
But when I run the renumberMesh utility, then checkMesh, I get the following (see `checkMesh.afterRenumbering` attached file):
**After running renumberMesh**:
```
Mesh non-orthogonality Max: 78.4614 average: 9.84955
*Number of severely non-orthogonal (> 70 degrees) faces: 26.
Non-orthogonality check OK.
<<Writing 26 non-orthogonal faces to set nonOrthoFaces
Face pyramids OK.
Max skewness = 3.322 OK.
Coupled point location match (average 0) OK.
Failed 1 mesh checks.
```
As you can see, the **max skewness becomes 3.322**, and the **max non-orthogonality becomes 78.4614**.
I wonder if this is a side-effect of renumbering the cells or is it a bug?
Thank you
**Note**:
to convert the mesh.x to OpenFOAM format, use: `plot3dToFoam -2D 0.01 -noBlank mesh.x`
**Attached files**:
[mesh.x](/uploads/398f669511ad3547d37385db6383b66b/mesh.x)
[checkMesh.beforeRenumbering](/uploads/1e6e09b3c8fbfab13039646c3db28f60/checkMesh.beforeRenumbering)
[checkMesh.afterRenumbering](/uploads/358d8b8b7eb0e0df2df265b343716c1b/checkMesh.afterRenumbering)https://develop.openfoam.com/Development/openfoam/-/issues/2039cannot use vector with 'calc' directive2021-03-29T14:30:14ZMark OLESENcannot use vector with 'calc' directiveNoted by @svilfaye
```
#calc "vector(1, 2, 3);
// or
#calc "doubleVector(1, 2, 3);
```
fail to compileNoted by @svilfaye
```
#calc "vector(1, 2, 3);
// or
#calc "doubleVector(1, 2, 3);
```
fail to compileMark OLESENMark OLESENhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/60script updates2021-03-29T10:24:25ZMark OLESENscript updates- scripts need updates for newer mesa, paraview etc.
@Prashant- scripts need updates for newer mesa, paraview etc.
@PrashantMark OLESENMark OLESEN