Development issueshttps://develop.openfoam.com/groups/Development/-/issues2017-07-11T13:02:55Zhttps://develop.openfoam.com/Development/openfoam/-/issues/515upgrade from NamedEnum to Enum2017-07-11T13:02:55ZMark OLESENupgrade from NamedEnum to EnumMore flexible and reduces chances of mistakes in the long-termMore flexible and reduces chances of mistakes in the long-termv1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/519BUG: Issue in using subTrisurface2017-07-12T04:42:30ZPrashant SonakarBUG: Issue in using subTrisurfaceAttached modified SHM dict for motorBike case illustrating failure.[snappyHexMeshDict](/uploads/3d1a271dc0fd48e33ce1dd43f4cb8815/snappyHexMeshDict)
Refer EP#415
```
Setting refinement level of surface to be consistent with shells.
--> F...Attached modified SHM dict for motorBike case illustrating failure.[snappyHexMeshDict](/uploads/3d1a271dc0fd48e33ce1dd43f4cb8815/snappyHexMeshDict)
Refer EP#415
```
Setting refinement level of surface to be consistent with shells.
--> FOAM FATAL ERROR:
bad size -83804595
```
@mark @Mattijsv1712Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/501COMP: 64 bit label compilation - further updates2017-07-12T04:46:26ZPrashant SonakarCOMP: 64 bit label compilation - further updatesFurther compilation failure at
foamVtkLagrangianWriter.C:103:25: error: call of overloaded 'write(int)' is ambiguous
@markFurther compilation failure at
foamVtkLagrangianWriter.C:103:25: error: call of overloaded 'write(int)' is ambiguous
@markVersion v1706Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/279tutorial RunFunctions ignore non-standard locations of decomposeParDict2017-07-12T07:20:28ZMark OLESENtutorial RunFunctions ignore non-standard locations of decomposeParDictSeems to have broken with last foundation merge.Seems to have broken with last foundation merge.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/522BUG: Failure when using nFaceSplitInterval without detectNearSurfacesSnap2017-07-12T12:20:46ZPrashant SonakarBUG: Failure when using nFaceSplitInterval without detectNearSurfacesSnapAttached dict and log for flange tutorial replicating failure.
[snappyHexMeshDict](/uploads/c4054725bd020d122b39279746a6cebf/snappyHexMeshDict)
[log.snappyHexMesh](/uploads/b35ab2d3b953e2709eeb5f019fa59987/log.snappyHexMesh)
- Ref EP#417Attached dict and log for flange tutorial replicating failure.
[snappyHexMeshDict](/uploads/c4054725bd020d122b39279746a6cebf/snappyHexMeshDict)
[log.snappyHexMesh](/uploads/b35ab2d3b953e2709eeb5f019fa59987/log.snappyHexMesh)
- Ref EP#417v1712Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/523remove deprecated ensight output order2017-07-13T06:34:42ZMark OLESENremove deprecated ensight output orderAdded for transition purposes only in 1612 - to verify that the output was identical with the new output backend.
Remove for 1712.
The deprecated order was `(hex prism pyr tet poly)` whereas the newer order is `(tet pyr prism hex pol...Added for transition purposes only in 1612 - to verify that the output was identical with the new output backend.
Remove for 1712.
The deprecated order was `(hex prism pyr tet poly)` whereas the newer order is `(tet pyr prism hex poly)` (increasing number of points) consistent with foamToEnsightParts
v1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/524provide build information about intel-mpi + gcc combination2017-07-13T06:34:55ZMark OLESENprovide build information about intel-mpi + gcc combination@Pawan@Pawanv1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/534OStringStream rewind probably not behaving as expected2017-07-18T15:01:50ZMark OLESENOStringStream rewind probably not behaving as expectedThe rewind only repositions the output pointer, but does not truncate the output buffer.
Eg,
OStringStream os;
os << "1234567890";
os.rewind();
os << "abc";
produces "abc4567890" as output, not "abc" as may be expected....The rewind only repositions the output pointer, but does not truncate the output buffer.
Eg,
OStringStream os;
os << "1234567890";
os.rewind();
os << "abc";
produces "abc4567890" as output, not "abc" as may be expected.
Suggested recourse, provide explicit `reset()` method to reposition output pointer and buffer.
@andyv1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/532streams cleanup2017-07-18T15:02:35ZMark OLESENstreams cleanupPartially inspired by #527, there is a bit of a mishmash of allocators for streams.
Relying on a dynamic cast for deletion just looks wrong.
- Should rejig to use pointers (not references) internally since this will allow better behavio...Partially inspired by #527, there is a bit of a mishmash of allocators for streams.
Relying on a dynamic cast for deletion just looks wrong.
- Should rejig to use pointers (not references) internally since this will allow better behaviour with any open/close methods that would be nice to add.
- Should have a bidirectional wrapped stringstream to avoid some copying during tokenizing of dictionaries.v1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/529combine externalCoupler from lumpedPoints and function object2017-07-18T15:02:49ZMark OLESENcombine externalCoupler from lumpedPoints and function objectshould also name as externalFileCoupler, to allow the future possibility of other coupling mechanisms.should also name as externalFileCoupler, to allow the future possibility of other coupling mechanisms.v1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/526enable profiling output for postProcess and -postProcess2017-07-19T11:59:17ZMark OLESENenable profiling output for postProcess and -postProcessLike most utilities, these two don't use the normal run() mechanism - so there is no profiling output possible.
- fix by adding an explicit print, but only report the profiling to the log file from master process. We don't wish to overw...Like most utilities, these two don't use the normal run() mechanism - so there is no profiling output possible.
- fix by adding an explicit print, but only report the profiling to the log file from master process. We don't wish to overwrite any profiling that was conducted during the simulation. Besides which, we don't have a proper Time object for handling the write nicely either.
@Prashant - this is the first solution. Please see if it is adequate.
STYLE: could discuss trimming down the cpu/sys information. It doesn't seem to make much sense to write it every time.v1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/482-dict argument assumes name starting with './' is relative to the case (inste...2017-07-19T11:59:41ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.com-dict argument assumes name starting with './' is relative to the case (instead of pwd) directoryv1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/457compressible dynamicLagrangian SGS2017-07-20T08:46:57ZAdmincompressible dynamicLagrangian SGSIt seems that there is a bug in dynamicLagrangian SGS model implemented for “compressible” solver. Since the rho value already implemented into the equations for fmm and flm then flm and fmm files in zero directory should have the same d...It seems that there is a bug in dynamicLagrangian SGS model implemented for “compressible” solver. Since the rho value already implemented into the equations for fmm and flm then flm and fmm files in zero directory should have the same dimension as incompressible version which is [0 4 -4 0 0 0 0] for both fmm and flm. However, with this set of dimension and with many other combinations, OpenFOAM is giving the “incompatible dimensions for operation” error.Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/19scotch include file is /usr/include/scotch/scotch.h which does not work in sr...2017-07-20T10:00:28ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comscotch include file is /usr/include/scotch/scotch.h which does not work in src/parallel/decompose/AllwmakeTest is for $SCOTCH_ARCH_PATH/include/scotch.h or /usr/include/scotch.h
This is on Ubuntu 12.10.Test is for $SCOTCH_ARCH_PATH/include/scotch.h or /usr/include/scotch.h
This is on Ubuntu 12.10.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/542failed check for scotch header2017-07-20T10:00:40ZMark OLESENfailed check for scotch headerSystem scotch can be located under `/usr/include/scotch/scotch.h`
- Was originally logged under ThirdParty https://develop.openfoam.com/Development/ThirdParty-plus/issues/19System scotch can be located under `/usr/include/scotch/scotch.h`
- Was originally logged under ThirdParty https://develop.openfoam.com/Development/ThirdParty-plus/issues/19Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/538Coupled patch crash in parallel2017-07-20T10:14:25ZAdminCoupled patch crash in parallelI'm using version OF-plus from 30 September 2016 (commit a9d9107930fc1b8d39196d712de6585d50aa81d0).
I need to build a new patch that couples information from two neighbor regions. I need to couple boundary information, not internal info...I'm using version OF-plus from 30 September 2016 (commit a9d9107930fc1b8d39196d712de6585d50aa81d0).
I need to build a new patch that couples information from two neighbor regions. I need to couple boundary information, not internal information. It is currently working in serial and in parallel when the decomposition keeps the coupled patch cells in the same processor. However, if the decomposition splits the domains just at the coupling patch, the code crashes.
**I've found an easy way to reproduce the error:**
Let's imagine two cubes (left and right) with two coupled boundary conditions: left_to_right and right_to_left. Let's use the chtMultiRegionSimpleFoam solver and the compressible::turbulentTemperatureRadCoupledMixed boundary condition for temperature. Inside this boundary condition, let's add the code:
`scalarField X = (Tp + nbrField)/2.0;`
Then:
* If we run the case in serial everything is ok.
* If we decompose the case in 2 processors using simple decomposition, with the decomposition perpendicular to the coupled patches (thus processor 0 includes: left-bottom and right-bottom zones), everything is ok
* If we decompose the case in 2 processors using simple decomposition, with the decomposition parallel to the coupled patches (thus processor 0 includes: left-left and right-left zones), the error obtained is:
> --> FOAM FATAL ERROR:
> [0] Field<scalar> f1(0), Field<scalar> f2(0) and Field<scalar> f3(1600)
> for operation f1 = f2 + f3
Thus, in the case where the crash appears, the size of the patch is not the same from the owner and the neighbor regions. It seems that information between both processors is not shared at patch level. **How can I avoid it? Is it a bug or I must call the boundary values in another way?**
Thank you in advance,
Elisabethttps://develop.openfoam.com/Development/openfoam/-/issues/518Cannot bypass underscore prefix for word::validated2017-07-21T12:58:24ZMark OLESENCannot bypass underscore prefix for word::validatedPrefixing a leading digit with `_` makes for words that are parser friendly, but can also be useful *not* to have this behaviour.Prefixing a leading digit with `_` makes for words that are parser friendly, but can also be useful *not* to have this behaviour.v1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/546Cannot print application help from non-case directory2017-07-22T21:58:37ZAdminCannot print application help from non-case directoryBehavior at c2db86f:
```bash
~ $ blockMesh -help
debug::switchSet(const char*, dictionary*&):
Cannot find DebugSwitches in dictionary
```Behavior at c2db86f:
```bash
~ $ blockMesh -help
debug::switchSet(const char*, dictionary*&):
Cannot find DebugSwitches in dictionary
```Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/552managing fatal exceptions is awkward2017-07-29T11:22:50ZMark OLESENmanaging fatal exceptions is awkwardMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/553argList should forgive/ignore lone dash.2017-08-01T11:12:01ZMark OLESENargList should forgive/ignore lone dash.A lone dash can inadvertently arise from TAB-completion (issue #551). Since an option without a name doesn't make much sense, we could/should trap this and either emit a warning or just silently ignore it.
@froesler, @Prashant, @andyA lone dash can inadvertently arise from TAB-completion (issue #551). Since an option without a name doesn't make much sense, we could/should trap this and either emit a warning or just silently ignore it.
@froesler, @Prashant, @andyMark OLESENMark OLESEN