Development issueshttps://develop.openfoam.com/groups/Development/-/issues2024-01-19T19:56:46Zhttps://develop.openfoam.com/Development/openfoam/-/issues/2966more graceful handling of empty surfaces in surfaceFieldValue2024-01-19T19:56:46ZMark OLESENmore graceful handling of empty surfaces in surfaceFieldValueIn some workflows, surfaceFieldValue is used to obtain patch values but the patches themselves may appear or disappear during the course of the simulation. At the moment, any surface with zero faces is treated as an error (which is usual...In some workflows, surfaceFieldValue is used to obtain patch values but the patches themselves may appear or disappear during the course of the simulation. At the moment, any surface with zero faces is treated as an error (which is usually is), but this could/should be extended to emit a warning, ignore or whatever. This would allow support for these particular workflows.
The `functionObjectList::errorHandlingType` (currently private) provides the necessary options (default, warn, ignore, strict). These should be exposed as public and be reused for surfaceFieldValue. This would allow user-defined remedial actions. These error handling and error-codes may also be desirable for sampled surfaces etc (TDB).
cross-ref: 2243v2312Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2965xcrun support for darwin (MacOS)2023-08-19T06:44:26ZMark OLESENxcrun support for darwin (MacOS)Issue has been touched on before, but never handled since it would add even more complexity into the already mess wmake rules. However, since the introduction of `WM_COMPILE_CONTROL` we actually do have a fair bit more flexibility, which...Issue has been touched on before, but never handled since it would add even more complexity into the already mess wmake rules. However, since the introduction of `WM_COMPILE_CONTROL` we actually do have a fair bit more flexibility, which lets us add in `xcrun` support.
cross-ref: EP2234Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2964No base point for face... produces a valid tet decomposition.2023-08-18T07:28:42ZCesar CNo base point for face... produces a valid tet decomposition.I've been trying to run a case by using picFOAM and I'm getting this warning:
--> FOAM Warning :
From function Foam::triFace Foam::tetIndices::faceTriIs(const Foam::polyMesh&) const
in file /apps/easybuild/software/tinkercliff...I've been trying to run a case by using picFOAM and I'm getting this warning:
--> FOAM Warning :
From function Foam::triFace Foam::tetIndices::faceTriIs(const Foam::polyMesh&) const
in file /apps/easybuild/software/tinkercliffs-rome/OpenFOAM/9-foss-2021a/OpenFOAM-9/src/OpenFOAM/lnInclude/tetIndicesI.H at line 76
No base point for face 7468, 3(16 40 200), produces a valid tet decomposition.
When I run the solver it does not show me errors but it seems that it can not solve anything and no results are obtained. Any help will be appreciated. Thankshttps://develop.openfoam.com/Development/openfoam/-/issues/2963add non-blocking communication for cyclic AMI2023-12-21T15:56:08ZMark OLESENadd non-blocking communication for cyclic AMIcross-ref: EP2240cross-ref: EP2240https://develop.openfoam.com/Development/openfoam/-/issues/2962icoFoam fails to install on CentOS 7.8 installation2023-08-18T07:48:03ZTom LehmannicoFoam fails to install on CentOS 7.8 installation<!--
*** 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 -->
### 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 : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version :
- 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/2961OpenFOAM v2306 gives YY_BUF_SIZE declare in scope error2023-10-28T14:01:38ZAziz ÖğütlüOpenFOAM v2306 gives YY_BUF_SIZE declare in scope errorI'm trying to compile openfoam v2306 on Centos 7.9 and I got YY_BUF_SIZE declare in scope error. Compiling process is attached to issue.[compiling_openfoam_v2306.txt](/uploads/cca81faecd94e20e0dc701f607057409/compiling_openfoam_v2306.txt)I'm trying to compile openfoam v2306 on Centos 7.9 and I got YY_BUF_SIZE declare in scope error. Compiling process is attached to issue.[compiling_openfoam_v2306.txt](/uploads/cca81faecd94e20e0dc701f607057409/compiling_openfoam_v2306.txt)https://develop.openfoam.com/Development/openfoam/-/issues/2960Discrepancy in side force front and rear axle split2023-09-18T09:00:18ZFahad IslamDiscrepancy in side force front and rear axle split<!--
*** 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 side force front and rear axle split seems incorrect.
Below is a NACA-0012 aerofoil with the freestream velocity at 5 degrees to the chord. The span is in the Z direction. The red dot is the location of the centre of rotation (CofR). All forces displayed in the image are equivalent to the force output from OpenFOAM.
![image](/uploads/8cd0d2ed68dda12b5df0f449600e0744/image.png)
You can see that the pressure side of the aerofoil is the positive Y side. This should mean that we get a net negative force in Y which is as expected as Cs = -2.097. This also matches up with CmYaw as if we have a negative force which is positioned more forward of the CofR we should expect a positive yaw moment using the right hand rule. This is also as expected and I trust that these values are being reported correctly by OpenFOAM.
However the front and rear axle side force splits do not match up with what we should expect. Firstly, given that the entirety of this wing sits more forward than the CofR you would expect that the force magnitude split would be more biased to the front axle, however, we see that the magnitude of the force on the rear axle is greater than the front. Secondly, if we consider the moments about the CofR and only consider the forces on the front and rear axle. The rear axle side force as reported from OpenFOAM is negative and large and the front axle is also negative but much smaller. This results in a net negative moment with the right hand rule which is counter to what CmYaw is reporting.
Furthermore the front and rear axle split for Cz seems to be working as expected when interrogated in the same manner as the side forces. Below are the Cz force values.
![image](/uploads/daeeb5a48ea8eacbee1135751e74b669/image.png)
The source code (https://www.openfoam.com/documentation/guides/latest/api/forceCoeffs_8H_source.html) reports that the front and rear axle splits are as shown in the image below. I believe that the equations for Cz_f,r are correct, however the equations for Cs_f,r and most likely Cd_f,r are incorrect. This is due to the direction of the moment axis changing depending on whether you are resolving forces about the x, y or z axis.
![image](/uploads/4b2f8e22ca7a0a03ad6d8e78cb235933/image.png)
Consider the diagram below where the forces about the rear axle have been resolved. The direction of positive force is upwards and the direction of positive X is to the right. The displacement vectors have all been calculated in the direction away from the rear axle which is the correct convention when dealing with moments i.e M = OR x F where all quantities are vectors and O is the point about which the moment is being calculated. We do not know which direction M is positive so we keep it consistent with the positive directions of our axes using +ve X as the displacement vector and +ve F as the force vector giving us positive moment anti-clockwise as we look at the diagram when we use the right hand rule. When resolving moments about the rear axle, the equation we end up with for the force on the front axle is, F_f = F/2 - M/Lref. This does not match up with what the script in OpenFOAM is doing and that is because we have not properly considered the direction of M.
![image](/uploads/e6814cf457c4ab9d196b7c74675b792d/image.png)
If M is the pitching moment about the Y-axis, which is going into the page as I have drawn it and forces are acting in the positive Z direction, then using the right hand rule a positive pitching moment about CofR is when the front axle moves in positive Z. This is clockwise in relation to the force diagram which is the opposite of the convention we have drawn M to be, thus the sign of M needs to be flipped. Therefore F_f = F/2 - M/Lref becomes Fz_f = Fz/2 + M_pitch/Lref. And this is exactly what the OpenFOAM script is doing for Cz, as shown above from the source code, which explains why Cz_f,r are behaving as expected.
However, if M is the yaw moment about the Z-axis, which is going out of the page as I have drawn it, and forces are acting in the positive Y direction then the direction of positive M is consistent with my diagram using the right hand rule and then we get Fs_f = Fs/2 - M_yaw/Lref. This is the opposite to what OpenFOAM currently does and ultimately means that the Cs_f and Cs_r values should be swapped around. If that is the case then going back to my aerofoil at the top of the page, if Cs_f and Cs_r were swapped around it would make sense in terms of the magnitude of the front and rear force split and it would be consistent with the direction of the yaw moment.
### Steps to reproduce
This is an issue with the forceCoeffs post processing function.
Run a wing with the spanwise direction in Z and specify the CofR to be more rearward than the wing. Then initialise the run such that the inlet velocity is at an incidence to the wing.
### What is the current *bug* behaviour?
Currently front rear force splits are as follows:
Cz_{f,r} = Cz/2 {+,-} Cm_Pitch
Cs_{f,r} = Cs/2 {+,-} Cm_Yaw
Cd_{f,r} = Cd/2 {+,-} Cm_Roll
### What is the expected *correct* behavior?
The front rear force splits should be as follows:
Cz_{f,r} = Cz/2 {+,-} Cm_Pitch
Cs_{f,r} = Cs/2 **{-,+}** Cm_Yaw
~~Cd_{f,r} = Cd/2 {+,-} Cm_Roll~~
The front and rear axle split for drag should not be dependent on CmRoll as the roll axis is parallel to the drag axis therefore drag can not be contributing to CmRoll and hence CmRoll can not be used to calculate the drag force split between front and rear axle.
I am unsure as to how to adapt the script to obtain Cd_f,r or if it is even possible. I believe front and rear drag is always a 50/50 split as the direction of the vector going from front to rear axle is in the same direction as drag therefore drag from any component or cell will produce the same moment on the front and rear axles resulting in the front and rear drag split being 50/50.
### Environment information
- OpenFOAM version : v2206 (v2212 still has the same source code in question)
### Possible fixes
Line 382 and 386 in the page below need changing depending on which force the front and rear axle split is being calculated for.
https://www.openfoam.com/documentation/guides/latest/api/forceCoeffs_8H_source.html
\label ~bugKutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/2959snappyHexMesh -dryRun fails2023-08-22T07:50:10ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh -dryRun fails<!--
*** 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 -->
`snappyHexMesh -dryRun` should checks (most) settings and give an estimate of expected cell count. It fails on the leak-path detection.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Any case with `locationsOutsideMesh`. Run `snappyHexMesh -dryRun`.
### What is the current *bug* behaviour?
<!-- What actually happens -->
segmentation error
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2306
Fix provided by @Prashant
@Prashanthttps://develop.openfoam.com/Development/openfoam/-/issues/2957Could not load libfieldFunctionObjects.so and user created library2023-08-08T07:38:02ZNicolas CharalambousCould not load libfieldFunctionObjects.so and user created libraryHi,
I have created a user defined object using the wmake in OPENFOAM 20.06. The in Make the files contained the following:
Helicity.C
LIB = $(FOAM_USER_LIBBIN)/helicity
Therefore, the new created object was helicity.so.
I included bo...Hi,
I have created a user defined object using the wmake in OPENFOAM 20.06. The in Make the files contained the following:
Helicity.C
LIB = $(FOAM_USER_LIBBIN)/helicity
Therefore, the new created object was helicity.so.
I included both helicity.so and libfieldFunctionObjects.so in controldict. However,
when running interphaseChangeFoam I am getting the following:
```
--> FOAM Warning :
From void* Foam::dlLibraryTable::openLibrary(const Foam::fileName&, bool)
in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 65
Could not load "libfieldFunctionObjects.so"
/home/ncharala/OpenFOAMv2006/OpenFOAM-v2006/platforms/linux64GccDPInt32Opt/lib/libfieldFunctionObjects.so: undefined symbol: _ZTIN4Foam15functionObjects15fieldExpressionE
--> FOAM Warning :
From void* Foam::dlLibraryTable::openLibrary(const Foam::fileName&, bool)
in file db/dynamicLibrary/dlLibraryTable/dlLibraryTable.C at line 65
Could not load "helicity.so"
```
How can I fix this?
Thank you
Nicolashttps://develop.openfoam.com/Development/openfoam/-/issues/2956Enabling SIGFPE on macOS arm642023-12-22T22:02:38ZGuanyang XueEnabling SIGFPE on macOS arm64### Summary
Enabling `SIGFPE` on macOS arm64
### Example case
Compile and run `applications/test/sigFpe` on ARM Mac it will print `Inf` instead of trapping `SIGFPE`.
### What is the current *bug* behaviour?
Results from `applications/t...### Summary
Enabling `SIGFPE` on macOS arm64
### Example case
Compile and run `applications/test/sigFpe` on ARM Mac it will print `Inf` instead of trapping `SIGFPE`.
### What is the current *bug* behaviour?
Results from `applications/test/sigFpe`
```
trapFpe: Floating point exception trapping - not supported on this platform
Provoking sigFpe (division by zero)
Infinity inf
```
Currently the code implemented by Tatsuya Shimizu https://develop.openfoam.com/Development/openfoam/-/commit/85760cbc347c4d5af01dd166084d452accd0b28e is not working, because:
1. On ARM64, `__fpcr` is the control register and `__fpsr` is the status register, see https://help.totalview.io/current/PDFs/TotalView_Reference_Guide.pdf page 453-454
2. On ARM64, the shift is 8 bits instead of 7 bits.
3. On ARM64, the mask definition is opposite to x86.
4. Even if everything is correct, Apple M1 throws `SIGILL` instead of `SIGFPE`. It terminates the executable and prints `illegal hardware instruction`.
I have fixed problem 1,2,3 in `feexceptErsatz.H`. For Problem 4, I did some dirty hack in `sigFpe.C` to enforce `SIGILL` in the handler. Currently there's no better way to implement this due to hardware/operating system limitations.
### What is the expected *correct* behavior?
After setting FPE masks, the CPU can trigger floating point exceptions, but throw 'SIGILL'. My fix picks up `SIGILL` and handles it as `SIGFPE` (only for macOS ARM64).
### Relevant logs and/or images
Results from `applications/test/sigFpe`
```
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
Provoking sigFpe (division by zero)
Infinity [stack trace]
=============
#1 Foam::sigFpe::sigHandler(int) in /Volumes/OpenFOAM/OpenFOAM-v2306/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#2 _sigtramp in /usr/lib/system/libsystem_platform.dylib
#3 main in Test-sigFpe
#4 start in /usr/lib/dyld
=============
zsh: floating point exception ./Test-sigFpe
```
Results from cavity tutorial case (set viscosity to negative number gives you immediate `SIGFPE`)
```
Starting time loop
Time = 0.005
Courant Number mean: 0 max: 0
smoothSolver: Solving for Ux, Initial residual = 1, Final residual = 3.87689e+220, No Iterations 1000
smoothSolver: Solving for Uy, Initial residual = 0, Final residual = 0, No Iterations 0
[stack trace]
=============
#1 Foam::sigFpe::sigHandler(int) in /Volumes/OpenFOAM/OpenFOAM-v2306/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#2 _sigtramp in /usr/lib/system/libsystem_platform.dylib
#3 Foam::PCG::scalarSolve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in /Volumes/OpenFOAM/OpenFOAM-v2306/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#4 Foam::PCG::solve(Foam::Field<double>&, Foam::Field<double> const&, unsigned char) const in /Volumes/OpenFOAM/OpenFOAM-v2306/platforms/darwin64ClangDPInt32Opt/lib/libOpenFOAM.dylib
#5 Foam::fvMatrix<double>::solveSegregated(Foam::dictionary const&) in /Volumes/OpenFOAM/OpenFOAM-v2306/platforms/darwin64ClangDPInt32Opt/lib/libfiniteVolume.dylib
#6 Foam::fvMatrix<double>::solveSegregatedOrCoupled(Foam::dictionary const&) in /Volumes/OpenFOAM/OpenFOAM-v2306/platforms/darwin64ClangDPInt32Opt/lib/libfiniteVolume.dylib
#7 main in /Volumes/OpenFOAM/OpenFOAM-v2306/platforms/darwin64ClangDPInt32Opt/bin/icoFoam
#8 start in /usr/lib/dyld
=============
zsh: floating point exception icoFoam
```
### Environment information
- OpenFOAM version : All
- Operating system : macOS arm64
- Hardware info : Apple M1
- Compiler : Clang
### Possible fixes
I'm attaching two modified files in `src/OSspecific/POSIX/signals`. It shouldn't change anything on other platforms including x86 Macs. OpenFOAM SIGFPE can be successfully triggered on macOS arm64.
~~[feexceptErsatz.H](/uploads/5daae02b07e49ad02418463ec66ec342/feexceptErsatz.H)~~
~~[sigFpe.C](/uploads/ccdd9fb1744c206d6ddf79a5634e3751/sigFpe.C)~~
See comment for second versionhttps://develop.openfoam.com/Development/openfoam/-/issues/2955BUG: filmPyrolysisRadiativeCoupledMixed parallel error2023-09-08T10:48:52ZAndrew HeatherBUG: filmPyrolysisRadiativeCoupledMixed parallel error<!--
*** 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
As reported via @Prashant for EP#2050
### Steps to reproduce
See tutorial `combustion/fireFoam/LES/flameSpreadWaterSuppressionPanel`
- decompose each region (primary, film, pyrolysis) into 8 procs (used scotch)
- parallel failure at runtime due to operating on fields of different sizesv2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2954Possible wrong code implementation for ErgunWenYuDragDragForce2023-08-07T08:30:41ZShah Akib SarwarPossible wrong code implementation for ErgunWenYuDragDragForce<!--
*** 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 code implemented for ErgunWenYuDrag inside src/lagrangian/intermediate/submodels/Kinematic/ParcelForces/Drag/ErgunWenYuDrag/ErgunWenYuDragFroce.C seems different than the source cited in the corresponding header file. There seems to be a '(1 - alphac)' missing in the numerator of the return value of the calcCoupled function, whereas there is an extra 'alphac' in the denominator that is absent in the cited papers.
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v2112https://develop.openfoam.com/Development/openfoam/-/issues/2953provision for delayed reading of compound tokens2023-08-19T06:46:01ZMark OLESENprovision for delayed reading of compound tokensIn work initiated by @serge and @gregorweiss, the files are read and the compound token is tagged as such, but allocated with zero size. This maintains the token stream elements to allow delayed reading.In work initiated by @serge and @gregorweiss, the files are read and the compound token is tagged as such, but allocated with zero size. This maintains the token stream elements to allow delayed reading.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2951Deb package with Ubuntu 23.042023-08-02T18:58:36ZMarkus TowaraDeb package with Ubuntu 23.04### Summary
I followed the instructions here on XUbuntu 23.04
https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/debian
After this apt-get update complains:
```
E: The repository 'https://dl.openfoam.com/repos/deb...### Summary
I followed the instructions here on XUbuntu 23.04
https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/debian
After this apt-get update complains:
```
E: The repository 'https://dl.openfoam.com/repos/deb lunar Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
```
### Possible fixes
This path exists, however the release codename is lunar not luna
https://dl.openfoam.com/repos/deb/dists/luna/
Workaround: change lunar to luna in /etc/apt/sources.list.d/openfoam.listhttps://develop.openfoam.com/Development/openfoam/-/issues/2950binField2023-08-02T08:02:36ZPekkabinFieldSince version 2206, a new binField function is launched. Does anyone have any idea how to extract pressure and viscous force components with this new bined function? To my understand the total force distribution is possible to extract fr...Since version 2206, a new binField function is launched. Does anyone have any idea how to extract pressure and viscous force components with this new bined function? To my understand the total force distribution is possible to extract from the the total force field but not force components. I hope that the old functionality is bring back in some way.
BR/Pekkahttps://develop.openfoam.com/Development/openfoam/-/issues/2949BUG - AMI - areaNormalisationMode not written2023-09-01T10:39:30ZAndrew HeatherBUG - AMI - areaNormalisationMode not written`areaNormalisationMode` can be `project` or `mag` - but these values are not written in the boundary file for (re-)start`areaNormalisationMode` can be `project` or `mag` - but these values are not written in the boundary file for (re-)startv2312Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2946Use UPtrList for managing objective functions2023-12-21T11:54:41ZMark OLESENUse UPtrList for managing objective functionsStumbled across these when examining other code...
The incompressiblePrimalSolver uses a List of pointers for the objective functions. I think that a UPtrList would make more sense. The primary reason being to encapsulate the pointer de...Stumbled across these when examining other code...
The incompressiblePrimalSolver uses a List of pointers for the objective functions. I think that a UPtrList would make more sense. The primary reason being to encapsulate the pointer dereference, as well as other methods (eg, test(), get(), ...).
The code that may need to be modified in any case is the use of lookupClass. This is usually OK, but there is no absolute guarantee about the iteration order.
Here's a code snippet using `sorted` instead, which generates a UPtrList as an intermediate type (a couple of allocations fewer than sending back a HashTable).
```
Foam::UPtrList<Foam::objective>
Foam::incompressiblePrimalSolver::getObjectiveFunctions() const
{
DynamicList<objective*> objectives;
for (auto& adjoint : mesh_.sorted<adjointSolver>())
{
if (adjoint.primalSolverName() == solverName_)
{
PtrList<objective>& managerObjectives =
adjoint.getObjectiveManager().getObjectiveFunctions();
for (objective& obj : managerObjectives)
{
objectives.push_back(&obj);
}
}
}
return UPtrList<objective>(objectives);
}
```Vaggelis PapoutsisVaggelis Papoutsishttps://develop.openfoam.com/Development/openfoam/-/issues/2945Particle Tracking for moving mesh can result in endless while iteration2024-01-30T09:48:52ZJan HartmannParticle Tracking for moving mesh can result in endless while iteration<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be re...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
I am doing a lagrangian particle simulation together with a moving mesh method. After a certain amount of simulations steps one particle gets caught in the while loop within the function of trackToFace. I analyzed some output. The Tet Face of the particle stays constant and the step fraction does not change anymore within the loop. Therefore the while loop is never exited. The variable nBehind_ that shall prevent such a behaviour stays as zero so the condition within the loop never gets false. Nevertheless the particle tracking does not change anymore and the simulation freezes at this position. If i restart the simulation or add another condition that is a maximum iter counter i can resolve this problem. In the next time step the particle movement works properly again. The error occurs in version of2206 but since the functions are not changed it should also appear in the current version.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
This is a tough one since the dynamic mesh code uses some own written boundary condition for the patch that is moving. The error occurs after 10 hours of computation and a total of 1.8 million computed parcels. Since the error does not occur after restart from the previously saved time step it is difficult to reproduce it.
<!-- How one can reproduce the issue - this is very important -->
### Example case
Due to current development i can not simply upload the case and boundary condition.
<!--
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 simulation does not continue since it is trapped in this loop.
<!-- 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
- OpenFOAM version: v2206
- Operatin System: Ubuntu, CentOS
- Compiler: gcc
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v2306|v2212|v2206|v2112|v2106 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
### Possible fixes
In my case an iter counter that exits the loop after a certain amount of iteration solve the problem.
<!--
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/2944mapFieldsPar - source and target swapped - WIP code2023-09-01T11:13:55ZPrashant SonakarmapFieldsPar - source and target swapped - WIP codeDeveloped for [EP#944](https://exchange.openfoam.com/node/944)
and another [comment ](https://exchange.openfoam.com/node/2025#comment-21802)to be noted while integration
Only internal note.Developed for [EP#944](https://exchange.openfoam.com/node/944)
and another [comment ](https://exchange.openfoam.com/node/2025#comment-21802)to be noted while integration
Only internal note.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/2943importation of MED mesh files types2023-07-13T07:45:30Zfranco otaolaimportation of MED mesh files types### Functionality to add/problem to solve
Following my post about ideasunvToFoam ([](https://develop.openfoam.com/Development/openfoam/-/issues/2942)). This format does not allow the importation of meshes with pyramid elements. so if a ...### Functionality to add/problem to solve
Following my post about ideasunvToFoam ([](https://develop.openfoam.com/Development/openfoam/-/issues/2942)). This format does not allow the importation of meshes with pyramid elements. so if a mesh has even one single pyramid cell, it is not possible to import it from salome to OpenFOAM easily. Salome has its native format MED, which can save pyramid elements as any arbitrary polyhedral cell type. The need from these functionality is clear and has been there since long time [](https://www.cfd-online.com/Forums/openfoam-meshing/73971-mesh-conversion-salome-openfoam.html)
### Target audience
Salome has the capacity to combine structured & unstructured meshes in a conformal way. also to create meshes respecting the edges of a geometry. The audience is the common OpenFOAM user who wants to use other opensource meshers inside salome.
### Proposal
adding a medToFoam which would import directly the MED format files to OpenFOAM
### What does success look like, and how can we measure that?
being able to import meshes directly from salome output without intermediate formats.
### Links / references
some references that could help:
- first a foamToMed already exists (import of openfoam meshes to salome) could be helpful https://github.com/mortbauer/foamMeshToMED
- there exist also a python script to export meshes directly from salome to FOAM format (which I don't think could be useful for the development, as it does not passes thought MED format but in any case I post it) https://github.com/psicofil/salomeToOpenFOAM
- The MED format has been integrated to paraview, their reader could help the development? https://discourse.paraview.org/t/med-format-native-support-in-paraview/7028