Development issueshttps://develop.openfoam.com/groups/Development/-/issues2019-07-03T19:32:56Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1203change of name for functionObject: motorbike pisoFoam2019-07-03T19:32:56ZPawan Ghildiyalchange of name for functionObject: motorbike pisoFoam<!---
Please read this!
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
--->
### Summary
(Summarize the bug encountered concisely)...<!---
Please read this!
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
--->
### Summary
(Summarize the bug encountered concisely)
residual functionObjects is not found while running simpleFoam
### Steps to reproduce
(How one can reproduce the issue - this is very important)
run case by All run scripts.
### Example case
**Motorbike case: ** tutorials/incompressible/pisoFoam/LES/motorBike/motorBike/system/stabilizationSchemes
tutorials/compressible/rhoSimpleFoam/aerofoilNACA0012
tutorials/heatTransfer/buoyantBoussinesqPimpleFoam/BenardCells
tutorials/incompressible/pimpleFoam/laminar/planarPoiseuille
tutorials/incompressible/simpleFoam/bump2D
### What is the current *bug* behaviour?
residual functionObjects is not found while running simpleFoam
### What is the expected *correct* behavior?
Name of functionObject need to be changed to new name which is
solverInfo
### Relevant logs and/or images
"--> FOAM Warning :"
Unknown function type residuals
Valid function types :
"
### Environment information
(OpenFOAM version : develop
(Operating system : redhat
(Hardware info : XXX)
https://develop.openfoam.com/Development/openfoam/-/issues/1267The 'function object' does not write out the results of 'volFieldValue' if 's...2019-07-03T19:32:25ZAdminThe 'function object' does not write out the results of 'volFieldValue' if 'solidificationMeltingSource' is used.<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
After calculation using solidificationMeltingSource, the time change of the liquid phase (eg. sMS:alpha1 field) fails to written out by function object utility.
### Steps to reproduce
> $ buoyantPimpleFoam
>
> (after the end)
>
> $ buoyantPimpleFoma -postProcess
### Example case
After expanding this attached file, execute 'Allrun' script file!
[solidificationMeltingSourceTest.tar.gz](/uploads/556b79b4ce57806740507da6e5ce49f6/solidificationMeltingSourceTest.tar.gz)
### 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
In case of the calculation simultaneously with solver
>volFieldValue meltingFranctions write:
>
> sum(PCM) of sMS1:alpha1 = 475.61726
>
>End
>
>(no problem)
---
When executed as post-processing
>volFieldValue meltingFranctions write:
>
> sum(PCM) of sMS1:alpha1 = 0
>
>
>End
### 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 :v1812
Operating system :ubuntu18.04
Compiler :gcc-7.3.0
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
-->https://develop.openfoam.com/Development/openfoam/-/issues/1329attach/detach does not correctly set owner/neighbour2019-07-03T19:27:33ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comattach/detach does not correctly set owner/neighbour<!--
*** 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
-->
<!--
All text between these marker...<!--
*** 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
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
(exchange platform 1010)
Issue: If statement does not check to see if face was modified in codeblock from lines 115 to 156 of attachInterface.C. This results in the attach instructions for the faces on the master patch being overwritten with old values for owner/neighbour/patchID.
The overall effect is that attachInterface.C:
deletes the faces from the slave patch as expected, but,
does not delete the faces from the master patch, and the cells across the faceZone are not attached. So the information in polymesh/<neighbour,boundary,owner> is incorrect
Adding a check to exclude faces that have been modified at line attachInterface.C:176 fixes this behaviour.
### Possible fixes
attachInterface.CMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1351Typo in the example2019-07-03T19:25:30ZAdminTypo in the exampleIn this link: https://www.openfoam.com/documentation/guides/latest/doc/guide-bcs-general-uniform-fixed-value.html
Under the **Usage** section, We can find the following:
> The uniformValue is a Foam::Function1 type, allowing the value to...In this link: https://www.openfoam.com/documentation/guides/latest/doc/guide-bcs-general-uniform-fixed-value.html
Under the **Usage** section, We can find the following:
> The uniformValue is a Foam::Function1 type, allowing the value to be prescribed as a function of time. For example, to ramp vector values from (0 0 0) to (10 0 0) over 5 seconds:The uniformValue is a Foam::Function1 type, allowing the value to be prescribed as a function of time. For example, to ramp vector values from (0 0 0) to (10 0 0) over 5 seconds:
> ```
> <patchName>
> {
> type uniformFixedValue;
> uniformValue table
> (
> (0 (0 0 0))
> (5 (0 0 0)) // Here, should be (10 0 0)
> );
> }
> ```
As you can see in the comment the velocity component should be `(10 0 0)` instead of `(0 0 0)`.https://develop.openfoam.com/Development/openfoam/-/issues/1349possible build issue with non-MPI vtk and runTimePostProcessing2019-07-02T09:40:17ZMark OLESENpossible build issue with non-MPI vtk and runTimePostProcessingFlagged by @PawanFlagged by @PawanMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1302interIsoFoam with morphing meshes2019-07-02T09:26:33ZJohan RoenbyinterIsoFoam with morphing meshesSo far isoAdvector has not worked with morphing meshes.
A version of isoAdvection/interIsoFoam that works with morphing meshes has now been committed in the new branch feature-isoAdvectorWithMorphingMeshes
A test case demonstrating th...So far isoAdvector has not worked with morphing meshes.
A version of isoAdvection/interIsoFoam that works with morphing meshes has now been committed in the new branch feature-isoAdvectorWithMorphingMeshes
A test case demonstrating that it works can be found here:
[sphereInSqueezedMesh.tar.gz](/uploads/68d31fde5a917760b7a0a0bc852b97bd/sphereInSqueezedMesh.tar.gz)
Will someone with merge privilege look at this (@andy ,@mark )?v1906Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1334overset patchFields no value field2019-07-02T09:24:37ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comoverset patchFields no value fieldoverset bc does not print value field so can only be post processed if liboverset.so was loadedoverset bc does not print value field so can only be post processed if liboverset.so was loadedMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/603muttley + openmpi-1.10.4 + openib does not support threads2019-06-28T09:56:15ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commuttley + openmpi-1.10.4 + openib does not support threadsopenmpi-1.10.4 (compiled with thread support!) + openib fails immediately in MPI_Init_thread without even printing the message
"mpi does not seem to have thread support. There might be issues with e.g. threaded IO"
- works with self, t...openmpi-1.10.4 (compiled with thread support!) + openib fails immediately in MPI_Init_thread without even printing the message
"mpi does not seem to have thread support. There might be issues with e.g. threaded IO"
- works with self, tcp
- works when changing MPI_Init_thread to MPI_Inithttps://develop.openfoam.com/Development/openfoam/-/issues/613foamToEnsight in parallel leaks memory2019-06-28T09:55:38ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamToEnsight in parallel leaks memoryRunning foamToEnsight -parallel produces under valgrind:
==4371== 88 bytes in 1 blocks are possibly lost in loss record 164 of 225
==4371== at 0x4C2B537: operator new[](unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-...Running foamToEnsight -parallel produces under valgrind:
==4371== 88 bytes in 1 blocks are possibly lost in loss record 164 of 225
==4371== at 0x4C2B537: operator new[](unsigned long) (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==4371== by 0x47332A: Foam::hashedWordList::hashedWordList(std::initializer_list<Foam::word>) (in /home/preston2/mattijs/OpenFOAM/OpenFOAM-plus.develop/platforms/linux64GccDPInt32Opt/bin/foamToEnsight)
==4371== by 0x44F003: main (in /home/preston2/mattijs/OpenFOAM/OpenFOAM-plus.develop/platforms/linux64GccDPInt32Opt/bin/foamToEnsight)
Error doesn't seem to be there non-parallel!Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/762No error when forgetting ¨;¨ in particle forces in the kinematicCloudProperti...2019-06-28T09:52:50ZAdminNo error when forgetting ¨;¨ in particle forces in the kinematicCloudProperties fileI made the really stupid mistake of forgetting the semicolon at the end of a particle force in the kinematicCloudProperties file.
`WenYuDragForce
{
alphac alpha.water
}
`
Because the statement is not ended, the next particle forces are...I made the really stupid mistake of forgetting the semicolon at the end of a particle force in the kinematicCloudProperties file.
`WenYuDragForce
{
alphac alpha.water
}
`
Because the statement is not ended, the next particle forces are not read in, which lead to really weird results. However, there is no warning of error. In many other input dictionaries the solver crashes because the next line is not read in.
I get that the user is responsible in the end for the input. However, in many other cases we are helped by errors and warnings. Therefore this mistake slipped by me. Would there be an easy fix to check this and give an error? I think this would be a nice safety feature. However, I can imagine that it would be too much work to prevent this kind of mistakes.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/866vtkWrite support for Lagrangian data2019-06-28T09:51:57ZAdminvtkWrite support for Lagrangian dataHas vtkWrite support been implemented for Lagrangian? If not, could this be implemented ASAP. We have some cases that we want to animate, and using the old approach of writing the Lagrangian data only, then reconstructing, then convert...Has vtkWrite support been implemented for Lagrangian? If not, could this be implemented ASAP. We have some cases that we want to animate, and using the old approach of writing the Lagrangian data only, then reconstructing, then converting to vtk is very unwieldy. We’d like to write the spray data in vtk format directly from a functionObject, and be able to select which associated spray properties (d, U, nP, etc.) get output.
KarlMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/885improve consistency of 'normal' methods2019-06-28T09:51:34ZMark OLESENimprove consistency of 'normal' methodsIn various places `normal()` can be a unit normal or an area normal. In places where there can be ambiguity, propose to provide explicit `areaNormal()` or `unitNormal()` methods. In the next version (1812), phase out `normal()` in favour...In various places `normal()` can be a unit normal or an area normal. In places where there can be ambiguity, propose to provide explicit `areaNormal()` or `unitNormal()` methods. In the next version (1812), phase out `normal()` in favour of these and deprecate `normal()`. In following version (1906), mark normal as `= delete` or otherwise tag its usage to finalize changeover.
For the first step, I propose adding these new names, but not yet changing code to use them. This will get them into place for early adopters and also make it easier with bugfixes/backports between 1806 and the 1812-develop.
@Nilsson @johan\_roenbyv1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/914reduce/remove the foamPackXXX scripts.2019-06-28T09:51:21ZMark OLESENreduce/remove the foamPackXXX scripts.- should remove all of the non-git elements, since it is unreliable to be packaging files from the working directory (which could contain extra rubbish) and not from the git repository.
- add support for add in submodules. cf #907- should remove all of the non-git elements, since it is unreliable to be packaging files from the working directory (which could contain extra rubbish) and not from the git repository.
- add support for add in submodules. cf #907v1812Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1333spurious time indexing for collated ensight write2019-06-28T09:50:42ZMark OLESENspurious time indexing for collated ensight writeAs noted in #1328 (@Prashant) - the areaWrite exhibits some odd output with ensight.
The cause traces back to the handling of time values, which are administered in the fieldDict. Both the less-than and the equal comparison operators ne...As noted in #1328 (@Prashant) - the areaWrite exhibits some odd output with ensight.
The cause traces back to the handling of time values, which are administered in the fieldDict. Both the less-than and the equal comparison operators need some additional tolerance.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/981ENH: support -time for blockMesh2019-06-28T09:49:27ZPrashant SonakarENH: support -time for blockMeshcorss reference and code at EP#765corss reference and code at EP#765Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/988reference cell initialised to 0 instead of -12019-06-28T09:49:00ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comreference cell initialised to 0 instead of -1If you have a cht case with 0 cells on some processors the call to getRefCellValue will fail. The reference cell setting is only done for fields that need it but the getRefCellValue is done always.
In createFluidFields.H replace
```
Lis...If you have a cht case with 0 cells on some processors the call to getRefCellValue will fail. The reference cell setting is only done for fields that need it but the getRefCellValue is done always.
In createFluidFields.H replace
```
List<label> pRefCellFluid(fluidRegions.size(), 0);
```
with
```
List<label> pRefCellFluid(fluidRegions.size(), -1);
```
@sergio review?Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/1085Cannot prevent use of user config.sh directories2019-06-28T09:47:28ZMark OLESENCannot prevent use of user config.sh directoriesThis can hit when building for spack, debian, rpms as a normal user.
Using `foamEtcFile` to locate elements such as `config.sh/mpi` mean that any existing entries under `~/.OpenFOAM` will be seen and possibly influence the build.
Anothe...This can hit when building for spack, debian, rpms as a normal user.
Using `foamEtcFile` to locate elements such as `config.sh/mpi` mean that any existing entries under `~/.OpenFOAM` will be seen and possibly influence the build.
Another potential problem could arise on cluster installations. The administrator may wish to lock down the OpenFOAM configuration values to avoid issues.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1159META: How does the Developer upgrade guide get filled?2019-06-28T09:46:15ZAdminMETA: How does the Developer upgrade guide get filled?Hello!
So, the developer upgrade guide is currently lagging behind, with the guide for 1806 "coming soon". My guess is that the guide is being composed after the release, which needs going through the introduced changes after the fact. ...Hello!
So, the developer upgrade guide is currently lagging behind, with the guide for 1806 "coming soon". My guess is that the guide is being composed after the release, which needs going through the introduced changes after the fact. A more efficient system, also leading to a better and more complete guide, would be to make it a live document where breaking API changes are registered upon commit. For each braking change one could add something like
ClassName Short description of the breaking change <Link to commit>
This would *really* make things easy for people writing stand-alone libraries since they can immediately see if their code is affected and how to address it. Hopefully, the overhead for the devs is not that large since breaking changes should not happen too often. Releasing the guide would amount to freezing the document upon the release of a new version of the software, sorting the list after the class name and adding a more detailed discussion of the most important changes.AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1148inconsistent handling of optional dimensions for dimensioned Type2019-06-28T09:40:25ZMark OLESENinconsistent handling of optional dimensions for dimensioned TypeThis is a continuation of #1116
- lookupOrDefault handles optional dimensions
- lookupOrAddToDict does lookup and adding on base type (ie, no dimensions)
- readIfPresent (and now readEntry), work directly with value_ - so also cannot ha...This is a continuation of #1116
- lookupOrDefault handles optional dimensions
- lookupOrAddToDict does lookup and adding on base type (ie, no dimensions)
- readIfPresent (and now readEntry), work directly with value_ - so also cannot handle optional dimensionsv1906Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1160general cleanup items for containers2019-06-28T09:39:46ZMark OLESENgeneral cleanup items for containers- move some HashTable details into the Detail namespace
- avoid delete/new when calling HashSet::set()
- better handling of pointers in hashes (IO).
- FixedList output formatting influences pair/edge and thus we get things like `2{100}`...- move some HashTable details into the Detail namespace
- avoid delete/new when calling HashSet::set()
- better handling of pointers in hashes (IO).
- FixedList output formatting influences pair/edge and thus we get things like `2{100}` for a labelPair output. For these short lists it probably doesn't have much space saving. It would be nice to have the same output format for a Pair or a Tuple2 of the same content.Mark OLESENMark OLESEN