Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-07-06T12:05:23Zhttps://develop.openfoam.com/Development/openfoam/-/issues/564mismatch in send/receive sizes of int32/int642021-07-06T12:05:23ZMark OLESENmismatch in send/receive sizes of int32/int64I think the root cause for #505 could be how ints are being sent/received.
For example, an int32_t is sent with a LABEL tag and is 4 bytes. But a LABEL is received in UIPstream as a `label` and could be 32 or 64-bits (depending on WM_LAB...I think the root cause for #505 could be how ints are being sent/received.
For example, an int32_t is sent with a LABEL tag and is 4 bytes. But a LABEL is received in UIPstream as a `label` and could be 32 or 64-bits (depending on WM_LABEL_SIZE). It would seem to be the same for int64, but we probably haven't been sending those about too much in that form.
@andy @MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/565extraneous 'orientedWeightField' entry in header of surfaceFieldValue.H2017-08-10T10:29:55ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comextraneous 'orientedWeightField' entry in header of surfaceFieldValue.HMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/566setSet dumps wrong vtk files of sets2020-01-22T21:31:06ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsetSet dumps wrong vtk files of setssetSet writes vtk files of sets with 0 elements, even when set has non-zero elements.setSet writes vtk files of sets with 0 elements, even when set has non-zero elements.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/567require weighting with absolute values for surfaceFieldValue2017-09-12T08:01:03ZMark OLESENrequire weighting with absolute values for surfaceFieldValue- The current weightedAverage (eg, with rhoU . dA) includes the direction, but should also provide a variant without the direction.
- the derived `pTotal` in surfMeshSamplers only works for compressible cases.
@Pawan- The current weightedAverage (eg, with rhoU . dA) includes the direction, but should also provide a variant without the direction.
- the derived `pTotal` in surfMeshSamplers only works for compressible cases.
@Pawanv1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/568implicit conversion of string to switch2017-08-11T16:07:11ZMark OLESENimplicit conversion of string to switchThe Switch constructors (from string) allows this sort of thing:
Switch sw;
sw = "none";
these seems to be too much automatic conversion - constructor should be explicit.The Switch constructors (from string) allows this sort of thing:
Switch sw;
sw = "none";
these seems to be too much automatic conversion - constructor should be explicit.v1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/569locationInMesh specified in shmDict being ignored in favor of locationsInMesh2019-07-03T19:47:41ZAdminlocationInMesh specified in shmDict being ignored in favor of locationsInMeshI am having issues with snappy in 1706 - locationsInMesh is being used despite shmDict specifying locationInMesh.
We mesh automotive geometries, where we want a MRF cellZone for brake discs. These brake ducts have dozens of independent...I am having issues with snappy in 1706 - locationsInMesh is being used despite shmDict specifying locationInMesh.
We mesh automotive geometries, where we want a MRF cellZone for brake discs. These brake ducts have dozens of independent volume channels where a centroid can be outside the volume (total=100s per car), so specifying all locationsInMesh can't be automated - we use the original functionality of defining bounds to these channels via STL geometry. In all versions before 1706 this works fine.
However, in 1706, despite specifying locationInMesh and then providing the geometry for cellZones, locationsInMesh is what shows up in shm's log. Strangely, the faceZones are created, and are not empty. The MRF cellZones are also created, but no cells are assigned to them. I checked the extended code guide, where it shows both locationInMesh and locationsInMesh can be used, so I suspect this could be a bug?
**snappyHexMeshDict:**
> allowFreeStandingZoneFaces true;
locationInMesh (-1.5 -0.5 1.5);
internal_fluid_l_mrf_fr_wheel
{
level (8 8);
faceZone internal_l_mrf_fr_wheel;
faceType internal;
cellZone fluid_l_mrf_fr_wheel;
cellZoneInside inside;
}
**log from snappy** (anomolies to previous versions in boxes)
![snappyLog](/uploads/7efb9df21a47eaeab50e2c7e7e3446d2/snappyLog.png)
I've attached a small test case, just run the run_snappy.sh to reproduce (runs in minutes.) Log from when I run it locally is also attached.
[cellZoneProblem_testCase.zip](/uploads/9f16affbb2b99d49d8f1926f41885c11/cellZoneProblem_testCase.zip)[log.mesh.allMeshing](/uploads/efbf9d6753d975c35e08f9626878174d/log.mesh.allMeshing)https://develop.openfoam.com/Development/openfoam/-/issues/570Velocity fluctuation in porousSimpleFoam2017-08-16T05:19:51ZAdminVelocity fluctuation in porousSimpleFoamWhile using 'porousSimpleFoam' solver its expected to show constant superficial velocity along the flow.
But its showing some variation or oscillation at the entrance, at higher velocities the its showing at more regions.
Tried with a ve...While using 'porousSimpleFoam' solver its expected to show constant superficial velocity along the flow.
But its showing some variation or oscillation at the entrance, at higher velocities the its showing at more regions.
Tried with a very low relaxation factor also, it doesn't works.
But the pressure drop is showing convincing values.https://develop.openfoam.com/Development/openfoam/-/issues/571BUG: Unable to create a List from a SLList2019-12-09T22:11:26ZAdminBUG: Unable to create a List from a SLListOn beahlf of @hjasak
The following code fails
```
int main(int argc, char *argv[])
{
SLList<label> a;
List<label> b(a);
return 0;
}
```
With the error message
```
src/OpenFOAM/lnInclude/ListI.H:94:35: error: invalid type a...On beahlf of @hjasak
The following code fails
```
int main(int argc, char *argv[])
{
SLList<label> a;
List<label> b(a);
return 0;
}
```
With the error message
```
src/OpenFOAM/lnInclude/ListI.H:94:35: error: invalid type argument of unary '*' (have 'int')
this->operator[](i) = *iter;
```v1712AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/572snappyHexMesh : visualising connection between inside and outside points2020-01-03T09:46:50ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comsnappyHexMesh : visualising connection between inside and outside pointsWould be nice to have a leak-detection process, either built-in or stand-alone, that can detect mesh paths between provided 'inside' and 'outside' points.Would be nice to have a leak-detection process, either built-in or stand-alone, that can detect mesh paths between provided 'inside' and 'outside' points.https://develop.openfoam.com/Development/openfoam/-/issues/573boundaryRadiation cannot be used for parallel computations2017-08-21T05:44:37ZAdminboundaryRadiation cannot be used for parallel computationsHello, in the OpenFOAM v3.0+ I have to use in our available cluster, I found that the BC type "boundaryRadiation" cannot be used in parallel computations. There are several tutorial cases containing "boundaryRadiation", like in lagrangia...Hello, in the OpenFOAM v3.0+ I have to use in our available cluster, I found that the BC type "boundaryRadiation" cannot be used in parallel computations. There are several tutorial cases containing "boundaryRadiation", like in lagrangian/coalChemistryFoam and fireFoam/smallPoolFirem3D. When I run them with parallel decomposition, I got the following error information:
`+++++++++++++++++++++++++++++++++++++++++++++++++++++
[0]
[0]
[0] --> FOAM FATAL IO ERROR:
[0] [1]
[1]
[1] --> FOAM FATAL IO ERROR:
[1] inconsistent patch and patchField types for
patch type processor and patchField type boundaryRadiation
[1]
[1] file: /home/users/nus/xiaoer/OpenFOAM/xiaoer-v3.0+/run/simplifiedSiwek/constant/boundaryRadiationProperties.boundaryField..* from line 25 to line 29.
[1]
[1] From function static Foam::tmp<Foam::fvPatchField<Type>> Foam::fvPatchField<Type>::New(const Foam::fvPatch &, const Foam::DimensionedField<Type, Foam::volMesh> &, const Foam::dictionary &) [with Type = double]
[1] in file /app/OpenFOAM/OpenFOAM-v3.0+/src/finiteVolume/lnInclude/fvPatchFieldNew.C at line 163.
[1]
FOAM parallel run exiting
+++++++++++++++++++++++++++++++++++++++++++++++++++++++`
Could you please tell me how to fix this issue?
Thanks!https://develop.openfoam.com/Development/openfoam/-/issues/574Curle's analogy2019-12-09T22:11:26ZAdminCurle's analogyI believe there is a mistake in the implemented acoustic analogy in OF-1706. The coefficient on the RHS should be 1/(4*pi) instead of 4*pi.
Probably change:
pDash = 4*mathematical::pi/c0_ * (d/magSqr(d) & dfdt);
to pDash = 1/4/mathemati...I believe there is a mistake in the implemented acoustic analogy in OF-1706. The coefficient on the RHS should be 1/(4*pi) instead of 4*pi.
Probably change:
pDash = 4*mathematical::pi/c0_ * (d/magSqr(d) & dfdt);
to pDash = 1/4/mathematical::pi/c0_ * (d/magSqr(d) & dfdt);https://develop.openfoam.com/Development/openfoam/-/issues/575ENH: print correct information of "out of bounding box" for sampledTriSurface...2019-04-26T11:55:28ZPrashant SonakarENH: print correct information of "out of bounding box" for sampledTriSurface field samplingAttached example illustrating behavior
- sampling trisurface is out of mesh
- it gives badly formed BB error when used with fieldValue (and nothing with sampledSurfaces!)
[test_GL575.tgz](/uploads/d59947762579e3c6ed783acf923bf4ff/test_...Attached example illustrating behavior
- sampling trisurface is out of mesh
- it gives badly formed BB error when used with fieldValue (and nothing with sampledSurfaces!)
[test_GL575.tgz](/uploads/d59947762579e3c6ed783acf923bf4ff/test_GL575.tgz)
Refer: EP#472
@mark @Mattijsv1712AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/576ENH: improving postChannel2021-07-31T18:02:11ZAdminENH: improving postChannelHello!
postChannel is an old small utility that allows to collapse data from a turbulent channel flow LES or DNS into a single profile by averaging along x and z, which are statistically homogeneous directions. There is, however, a sign...Hello!
postChannel is an old small utility that allows to collapse data from a turbulent channel flow LES or DNS into a single profile by averaging along x and z, which are statistically homogeneous directions. There is, however, a significant downside: it is impossible to choose what fields are to be averaged. Instead, they are hardcoded, see
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/applications/utilities/postProcessing/miscellaneous/postChannel/collapse.H
A couple of years ago I have developed my version of the utility which allows one to provide a list of fields to be averaged. Also, it allows you to specify the names of the patches corresponding to the top and bottom walls, and the outputted 1d profiles will include the data averaged on the patches. This is relevant in some situations, for instance in Wall-Modelled LES, where nu_t at the wall is an important quantity. Here is the repo with my code.
https://bitbucket.org/lesituu/postchannelflow
I would like to know if there is interest in incorporating my enhancemnts into the main code. From my side this seems like a nice small enhancemnt, which can be used to test getting through the process of contributing some code.
Kind regards,
Timofey
\## Reattaching the author to the issue ticket: @timofeymukha ##Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/577createZeroDictionary with volume flow rate2019-12-09T22:11:26ZvilfayeaucreateZeroDictionary with volume flow ratehttps://develop.openfoam.com/Development/OpenFOAM-plus/blob/develop/etc/caseDicts/createZeroDirectoryTemplates/boundaryConditions/fluid/incompressible/inletOptions
If you have a look at the source code of createZeroDictionary (see abov...https://develop.openfoam.com/Development/OpenFOAM-plus/blob/develop/etc/caseDicts/createZeroDirectoryTemplates/boundaryConditions/fluid/incompressible/inletOptions
If you have a look at the source code of createZeroDictionary (see above), it requires volumeFlowRate instead of volumetrictFlowRate. Could you fix it?
Thanks
SebastienPrashant SonakarPrashant Sonakarhttps://develop.openfoam.com/Development/openfoam/-/issues/578BUG: Add error for missing semi-colon2017-09-11T12:21:12ZPrashant SonakarBUG: Add error for missing semi-colonAttached case illustrating behavior configured for v1612+ or later
[motorBike.tgz](/uploads/184f2a29c661147209e0261689a7b56d/motorBike.tgz)
yPlus FO has missing semicolon at the end of libs.
Rest of the entries seem ignored and it out...Attached case illustrating behavior configured for v1612+ or later
[motorBike.tgz](/uploads/184f2a29c661147209e0261689a7b56d/motorBike.tgz)
yPlus FO has missing semicolon at the end of libs.
Rest of the entries seem ignored and it outputs field every time step.
Adding semicolon, it dumps only on output time = 5
@mark @Mattijs @andyv1712https://develop.openfoam.com/Development/openfoam/-/issues/579tabulated6DOFMotion does not produce right results as ocsillatingLinearMotion...2019-01-08T15:29:17ZAdmintabulated6DOFMotion does not produce right results as ocsillatingLinearMotionin pimpleDymFoamThe tabulated6DOFMotion solidBodyMotionFunction does not produce right results as
ocsillatingLinearMotion solidBodyMotionFunction as demonstrated in the attached file. The test cases
were conducted using pimpleDyMFoam solver of OpenFoam ...The tabulated6DOFMotion solidBodyMotionFunction does not produce right results as
ocsillatingLinearMotion solidBodyMotionFunction as demonstrated in the attached file. The test cases
were conducted using pimpleDyMFoam solver of OpenFoam v1612+. Test cases of a plunging airfoil
are available. Please direct any suggestions to weixing.yuan@nrc-cnrc.gc.ca.[OpenFoamAirfoilPlungingMotion.pdf](/uploads/8f753fadbd8d82cdabc23ba5fdc97628/OpenFoamAirfoilPlungingMotion.pdf)https://develop.openfoam.com/Development/openfoam/-/issues/580contiguous flag2018-07-02T09:38:59ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcontiguous flagIn lagrangian there are various occurrences of making a specialisation of contiguous(), returning false:
coalCombustion/coalParcel/coalParcel.H
intermediate/parcels/derived/basicReactingMultiphaseParcel/basicReactingMultiphaseParcel.H
i...In lagrangian there are various occurrences of making a specialisation of contiguous(), returning false:
coalCombustion/coalParcel/coalParcel.H
intermediate/parcels/derived/basicReactingMultiphaseParcel/basicReactingMultiphaseParcel.H
intermediate/parcels/derived/basicReactingParcel/basicReactingParcel.H
spray/parcels/derived/basicSprayParcel/basicSprayParcel.H
The default template function returns false so they're not needed.AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/581mpi issue with new wave boundary implementation (previously ihfoam)2017-09-08T10:27:03ZAdminmpi issue with new wave boundary implementation (previously ihfoam)I noticed an issue with a case using the new wave boundary implementation in the interfoam solver v1706.
The simulation unexpectedly aborts before normal completion:
*mpirun noticed that process rank 6 with PID 0 on node nav08 exited on ...I noticed an issue with a case using the new wave boundary implementation in the interfoam solver v1706.
The simulation unexpectedly aborts before normal completion:
*mpirun noticed that process rank 6 with PID 0 on node nav08 exited on signal 8 (Floating point exception).*
The bug is probably related with MPI since running the same case in serial mode does not provoke this error.
[waves_mpi_problem.zip](/uploads/d5f07cb1830cf4effb2c37d1b8e49cc1/waves_mpi_problem.zip)https://develop.openfoam.com/Development/openfoam/-/issues/582Bugfix for interIsoFoam/isoAdvector2019-12-09T22:11:26ZJohan RoenbyBugfix for interIsoFoam/isoAdvectorHello OpenCFD
I've had a number of crash reports for isoAdvector, of which one can be seen here:
https://github.com/isoAdvector/isoAdvector/issues/9
Inspection showed that the division by zero error was caused by cells being touched a...Hello OpenCFD
I've had a number of crash reports for isoAdvector, of which one can be seen here:
https://github.com/isoAdvector/isoAdvector/issues/9
Inspection showed that the division by zero error was caused by cells being touched at just a point or an edge by the isoFace resulting in an isoFace normal of zero length. In a new commit at github/isoAdvector I have modified isoCutCell.C so that such cells are no longer treated as surface cells. Please see the required fix here (isoCutCell.C):
https://github.com/isoAdvector/isoAdvector/commit/252a182fb30dd38787a835d82a1c3dfb51a990ae
Kind regards,
Johanhttps://develop.openfoam.com/Development/openfoam/-/issues/583ENH: Add warning/error for missing weight field!2017-09-12T08:00:49ZPrashant SonakarENH: Add warning/error for missing weight field!With https://develop.openfoam.com/Development/OpenFOAM-plus/commit/7a803a5637b4c5174feda1cc7bab4c4906dd1d32
- the deprecated keyword orientedWeightField is removed
- however we miss warning/error when weightField is not provided!
Attach...With https://develop.openfoam.com/Development/OpenFOAM-plus/commit/7a803a5637b4c5174feda1cc7bab4c4906dd1d32
- the deprecated keyword orientedWeightField is removed
- however we miss warning/error when weightField is not provided!
Attached case [pitzDaily.tgz](/uploads/a94f07eed56de05e3433ca01840db6bd/pitzDaily.tgz)
Missing statements at https://develop.openfoam.com/Development/OpenFOAM-plus/blob/develop/src/functionObjects/field/fieldValues/surfaceFieldValue/surfaceFieldValue.C#L587
Refer EP#500
@Mattijs @andy @markv1712Mark OLESENMark OLESEN