Development issueshttps://develop.openfoam.com/groups/Development/-/issues2023-12-07T16:47:33Zhttps://develop.openfoam.com/Development/openfoam/-/issues/3045inconsistent handling of global IOobjects2023-12-07T16:47:33ZMark OLESENinconsistent handling of global IOobjectsSome items such as faSchemes, fvSchemes not properly marked as being global, which now provokes path resolution issues (after changes 4609aa38e1).
Much of the global object handling needs a revamp, but make do with a minor consistency u...Some items such as faSchemes, fvSchemes not properly marked as being global, which now provokes path resolution issues (after changes 4609aa38e1).
Much of the global object handling needs a revamp, but make do with a minor consistency update for now.v2312Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1083inconsistent handling of dimensioned types2018-11-26T20:53:03ZMark OLESENinconsistent handling of dimensioned typesIn `fixedPressureCompressibleDensityFvPatchScalarField`, for example, it grabs values from the thermodynamicProperties dictionary:
```
const scalar rholSat = dimensionedScalar(thermoProps.lookup("rholSat")).value();
```
The `dimensioned...In `fixedPressureCompressibleDensityFvPatchScalarField`, for example, it grabs values from the thermodynamicProperties dictionary:
```
const scalar rholSat = dimensionedScalar(thermoProps.lookup("rholSat")).value();
```
The `dimensioned(Istream&)` constructor forwards to `read(Istream&)` which requires name, dimensions, value.
In other locations (including in a tutorial example), these quantities are treated as if name, dimensions are optional.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2105Inconsistent foamToVTK -legacy with previous versions2021-05-27T14:20:47ZMatteo MontecchiaInconsistent foamToVTK -legacy with previous versions<!--
*** 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
Convert any OpenFOAM case using openfoam/1706 first and type the following command:
foamToVTK
then use openfoam/1912 and type:
foamToVTK -legacy
you will see that, in case of a tensor with class volSymmTensorField (e.g. UPrime2Mean), the order of the different tensor components is changed,
before it was:
XX XY XZ YY YZ ZZ
in the latest -legacy version is
XX YY ZZ XY XZ YZ
since the expected correct order is the first one, please correct the .vtk generation in the new
foamToVTK -legacy version.
I haven't tried if this problem occurs also without the "-legacy" flag.
### 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 : v1806|v1812|v1906 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
-->
Thank you in advance and have a nice day,
Matteohttps://develop.openfoam.com/Development/openfoam/-/issues/1069Inconsistent field ordering in PDRMesh2018-11-12T15:46:52ZMark OLESENInconsistent field ordering in PDRMeshRelies on the iteration of the IOobjectList being identical to that of names(), which is not guaranteed at all.
If these are not identical, the correspondence of naming will be incorrect.Relies on the iteration of the IOobjectList being identical to that of names(), which is not guaranteed at all.
If these are not identical, the correspondence of naming will be incorrect.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/530inconsistent faceZone normals from snappy, orientFaceZone fails to correct (l...2021-07-06T11:06:48ZAdmininconsistent faceZone normals from snappy, orientFaceZone fails to correct (log says it flips half the normals, but the faceZones mesh file is unchanged)So, I am seeing an issue I have seen in past versions: faceZones are not consistently oriented from snappy, AND this is not being corrected by orientFaceZone. This then prevents me from monitoring mass flow rates properly. When meshing a...So, I am seeing an issue I have seen in past versions: faceZones are not consistently oriented from snappy, AND this is not being corrected by orientFaceZone. This then prevents me from monitoring mass flow rates properly. When meshing a simple radiator (see geom image attached), I get a cellZone for the inside of the radiator, and a single faceZone separating the radiator cellZone from the external cellZone. I later take this faceZone, and split it into inlet and outlet faces using topoSet and a dict file in system.
Both the original faceZone, and the created inlet/outlet faceZones have random normals, which I want to have consistent for mass flow calculations. So, I try using orientFaceZone, but it does not change anything! I first meshed the case normally, then copied that mesh, and ran orientFaceZone on the copy. I am writing the mesh in ascii uncompressed, so I can use xxdiff to directly compare the files. Although the faceZones file for the copied mesh is newer, suggesting it was re-written by the utility, it is the exact same as the original file – no change. I have made a screenshot of xxdiff, to show you this. I've circled where I would normally expect to see a change.
The log file for orientFaceZone (also attached) clearly shows that it is flipping almost exactly 50% of the normals, and when I look at the faceZone normals in paraview (image also attached), about 50% should be flipped. Makes sense, as the 50% suggests a random distribution of the normals from snappy.
So, it appears to me that orientFaceZone is working, and doing the correct flipping. BUT, it seems to not write out the results! I cannot see any options that would force or prevent it from doing so, which makes me think it is a bug.
At the moment in 1706, I run the cases with two fluxSummary monitors: one using faceZone, and one using faceZoneAndDirection (great feature!!!) with the direction of the faceZone given by me explicitly. The two mass flow rates should match up exactly IF orientFaceZone were working, but there is a clear mis match (simpleFoam log attached.) I am hoping to get away from that, so if this is in fact a bug, I can share the test cases I created. They are 42MB each, compressed, and include a paraview state file for viewing the faceZone normals.
![xxdiff_of_faceZones_File](/uploads/55bdf2e0fb654cf5bdf361de82427b91/xxdiff_of_faceZones_File.png)
![geom02](/uploads/67aae2e470d9384b1f24d5a0f9b4f93e/geom02.png)
![faceNormals_after_orient](/uploads/7bc6e9e4000ff3fb27dcf2294053091c/faceNormals_after_orient.png)
![normalGlyphs_after_orient](/uploads/6860ccf9fe3db65eddd0028611bc4d8a/normalGlyphs_after_orient.png)
[log.orientFaceZone](/uploads/270772d77ab5138671304a40cbd8bc1b/log.orientFaceZone)
[log.solve_OF.log](/uploads/c98468aa50e936b6729ebf490939621d/log.solve_OF.log)https://develop.openfoam.com/Development/openfoam/-/issues/196Inconsistent face ordering between hex and boundBox2019-12-09T22:04:11ZMark OLESENInconsistent face ordering between hex and boundBoxFrom code inspection the face definitions in boundBox appear to be wrong - different face order than the hex cellModel, inverted face normals.
For code-style: the treeBoundBox enum for FRONT/BACK, TOP/BOTTOM could be misleading since ...From code inspection the face definitions in boundBox appear to be wrong - different face order than the hex cellModel, inverted face normals.
For code-style: the treeBoundBox enum for FRONT/BACK, TOP/BOTTOM could be misleading since TOP in this case designates +y and not +z as may be expected.
Will send additional notes per email.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1280inconsistent emissivity for externalWallHeatFluxTemperatureFvPatchScalarField2019-12-09T22:37:28ZMark OLESENinconsistent emissivity for externalWallHeatFluxTemperatureFvPatchScalarField- emissivity is partly ignored (hpTa) when there is no solid resistance- emissivity is partly ignored (hpTa) when there is no solid resistanceMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1803inconsistent behaviour: particle injection using coneInjection2024-01-11T17:58:01ZPawan Ghildiyalinconsistent behaviour: particle injection using coneInjection@andy @Sergio
I noticed a strange behaviour in number of parcel added when using reactingParcelFoam
on different number of processor using OpenFOAM-v1912 as well with 2006 (Intelmpi-openmpi)
Please note all cases run with same setting...@andy @Sergio
I noticed a strange behaviour in number of parcel added when using reactingParcelFoam
on different number of processor using OpenFOAM-v1912 as well with 2006 (Intelmpi-openmpi)
Please note all cases run with same setting but on different number of processor
**At first time step, all processor shows same number of parcels i.e 467 parcel added**
but them ramp to different value(3 shows same end number but two i.e 144 and 216 shows different number)
> | Cores | Parcel-InjectedPerTimeStep | | totalMassInjected |
> |-------|----------------------------|--|-------------------|
> | 36 | 350 | | 11.08329 |
> | 72 | 350 | | 11.08329 |
> | 144 | 700 | | 11.09316 |
> | 216 | 700 | | 11.11257 |
> | 288 | 350 | | 11.08329 |
**Observation**
1. number of particles per parcel vary by big number i.e 2 Million in first time step
when particles are injected (see below for 72 proc vs 144 proc)
![image](/uploads/5ddef451b8bf08106917266351e323fe/image.png)
**what i tried till now**
i) tried in 2006
ii)used fixedValue distribution
no difference in results
iii) changed precision of injection point .
i changed precision of injection point and it is not making any difference
(still need to check whether they lie in processor patch)
iii)added reacting1CloudProperties file (/uploads/f486d531e6259169af446ebfa1be301d/reactingCloud1Properties)https://develop.openfoam.com/Development/openfoam/-/issues/3002Inconsistent behavior of coneInjection model with particle collisions2023-10-25T10:55:52ZRiccardo RossiInconsistent behavior of coneInjection model with particle collisions<!--
*** 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
When using the coneInjection model with the DPMFoam or MPPICFoam solvers an inconsistent behavior is observed, i.e. particles are not injected in a cone shape but along lines within the specified cone.
The expected injection shape of particles is observed instead when the model is used with solvers without collisions, such as the kinematicParcelFoam.
### Steps to reproduce
Attached are the following two cases that can be run by simply running the associated solvers. Particles positions are saved in postProcessing/particlesTracks to be opened in Paraview by reading the associated vtp series files:
kinematicParcelFoam: empty box with zero flow velocity and particles released with a given speed using coneInjection model, no collisions
MPPICFoam: same case but with modified input files to allow for running with MPPICFoam and add collisions
### Example case
Examples cases can be found in the archive attached.
[tests.tgz](/uploads/35f9be8bc61c12b32b7266ce3177aab1/tests.tgz)
### What is the current *bug* behaviour?
The injection model does not produce a cone and particles are released along line with the conical orientation.
### What is the expected *correct* behavior?
The injection model should produce an axis-symmetric cone with minimum and maximum opening as specified in KinematicCloudProperties
### Relevant logs and/or images
The images below show the different behaviors of the injection model with (top) and without (bottom) collisions.
![coneInjectorWithCollisions](/uploads/4f0bfce984f01d39268391483711512f/coneInjectorWithCollisions.png)![coneInjectorWithoutCollisions](/uploads/b68700ab7691866b0d5d80681035d7a1/coneInjectorWithoutCollisions.png)
### Environment information
- OpenFOAM version : v2212
- Operating system : Centos
- Hardware info : -
- Compiler : Intel
### Possible fixesAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/issues/1412Inconsistency of globalIndex2019-08-30T06:04:46ZAdminInconsistency of globalIndex<!--
*** 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 ...<!--
*** 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 trying to generate a list of global cellIDs "for a cellSet" using local cellIDs of a decomposed case.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Following code snip was used:
globalIndex globalNumbering(mesh.nCells());
word cellSetName = "b1";
cellSet c1(mesh, cellSetName);
labelList channelID = c1.toc();
labelList gloProc(channelID.size());
labelList locProc(channelID.size());
for(int d=0; d<channelID.size(); d++)
{
const label globalCId = globalNumbering.toGlobal(channelID[d]);
gloProc[d] = globalCId;
const label localCId = globalNumbering.toLocal(globalCId);
locProc[d] = localCId;
}
Pout << "Local Lists on all Procs " << locProc << nl;
Pout << "Global Lists on all Procs " << gloProc << nl;
<!-- How one can reproduce the issue - this is very important -->
### Example case
I have tested my code for two cases; cavity and 1D straight channel.
<!--
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?
Here, the global cellIDs generated from local match with non-decomposed cellIds (i.e, in constant/polyMesh/sets/) for only the channel case.
They do not match in any way for the cavity case.
<!-- What actually happens -->
### What is the expected *correct* behavior?
The global cellIDs should match with those generated from local cellIDs, for any case.
<!-- 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 : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1806
- Operating system : Ubuntu 18.04
- Hardware info : Hp laptop, i7-5th gen, 4 cores
- Compiler : gcc
<!--
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
-->
Test cases:
[test_cases.tar.gz](/uploads/dee31416b6d779107c902bc5b14f0ca1/test_cases.tar.gz)
Solver used:
[testIco.tar.gz](/uploads/8f3120bba9631f18f4f47a65081663c7/testIco.tar.gz)https://develop.openfoam.com/Development/openfoam/-/issues/2575Inconsistency of function objects folder names with mesh regions2022-09-06T19:04:17ZRiccardo RossiInconsistency of function objects folder names with mesh regionsWHen using solver like the chtMultiRegionFoam some functions objects, such as surfaceFieldValue, are written to postProcessing/<regionName> whereas others, like sampling, are written directly into postProcessing even though they are only...WHen using solver like the chtMultiRegionFoam some functions objects, such as surfaceFieldValue, are written to postProcessing/<regionName> whereas others, like sampling, are written directly into postProcessing even though they are only applied to a particular region.https://develop.openfoam.com/Development/openfoam/-/issues/290inconsistency in scotch, metis library locations2017-01-02T12:24:10ZMark OLESENinconsistency in scotch, metis library locationsScotch and metis libraries are being installed under FOAM_EXT_LIBBIN, not under their respective XX_ARCH_PATH/lib.
If there are copies in the XX_ARCH_PATH/lib, they will not be available in the LD_LIBRARY_PATH anyhow and thus is confusi...Scotch and metis libraries are being installed under FOAM_EXT_LIBBIN, not under their respective XX_ARCH_PATH/lib.
If there are copies in the XX_ARCH_PATH/lib, they will not be available in the LD_LIBRARY_PATH anyhow and thus is confusing (wrong) to have them as LIB_LIB.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1040inconsistency in K/kappa reading for solidProperties2018-10-15T07:53:49ZMark OLESENinconsistency in K/kappa reading for solidPropertiesIf both `K` and `kappa` are present - on construct `K` will be used and `kappa` ignored.
For dictionary re-reading, both `K` and `kappa` are read if present. `kappa` is read second and will thus take effect.
- should use a Compat method...If both `K` and `kappa` are present - on construct `K` will be used and `kappa` ignored.
For dictionary re-reading, both `K` and `kappa` are read if present. `kappa` is read second and will thus take effect.
- should use a Compat method to handle this.https://develop.openfoam.com/Development/openfoam/-/issues/305Inconsistency in header/messages with kappaName etc2017-01-02T12:23:50ZMark OLESENInconsistency in header/messages with kappaName etcIn many places, the `Uname` became `U`, `kappaName` became `kappa`, but the headers and some error messages still refer to the old names.In many places, the `Uname` became `U`, `kappaName` became `kappa`, but the headers and some error messages still refer to the old names.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1010inconsistency in handling of FOAMversion2018-12-14T13:57:21ZMark OLESENinconsistency in handling of FOAMversionIssue raised (or stumbled over) by @escrmic
The compilation scripts define `Foam::FOAMversion` based on the version information at compile time (eg, WM_PROJECT_VERSION=1612). Subsequent renaming of the version within the `etc/bashrc` (e...Issue raised (or stumbled over) by @escrmic
The compilation scripts define `Foam::FOAMversion` based on the version information at compile time (eg, WM_PROJECT_VERSION=1612). Subsequent renaming of the version within the `etc/bashrc` (eg, WM_PROJECT_VERSION=1612.update2 or whatever) will not be respected in the internal `findEtcFiles()` lookups.
This can lead to a slight dichotomy since `bin/foamEtcFile` will use the current value of WM_PROJECT_VERSION. Thus `foamEtcFile` and `findEtcFiles()` will potentially locate different version-specific user or site files.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/14inconsistency in fftw make2019-07-21T22:56:27ZMark OLESENinconsistency in fftw makefftw uses double-precision interface only, makeFFTW should not have any special single-precision treatment.
Ref: https://develop.openfoam.com/Development/OpenFOAM-plus/issues/373
@Thalenberghen @Prashantfftw uses double-precision interface only, makeFFTW should not have any special single-precision treatment.
Ref: https://develop.openfoam.com/Development/OpenFOAM-plus/issues/373
@Thalenberghen @PrashantMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/2375inconsistency in documentation or implementation using Pstream::maxCommsSize2022-03-16T18:06:04ZMark OLESENinconsistency in documentation or implementation using Pstream::maxCommsSizeby inspection in Pstreams/exchange.C
The number of exchange iterations is calculated with the byte count:
```
nIter = (maxNBytes-1)/Pstream::maxCommsSize+1;
```
but later on in the loop the send sizes per iteration are calculated in th...by inspection in Pstreams/exchange.C
The number of exchange iterations is calculated with the byte count:
```
nIter = (maxNBytes-1)/Pstream::maxCommsSize+1;
```
but later on in the loop the send sizes per iteration are calculated in the element count, not the byte count:
```
nSend[proci] = min
(
Pstream::maxCommsSize,
sendBufs[proci].size()-startSend[proci]
);
// and
charSendBufs[proci] = reinterpret_cast<const char*>
(
&(sendBufs[proci][startSend[proci]])
);
```
I think that requested `Pstream::maxCommsSize` needs to be translated into a maxNumElems, with the appropriate sizeof(T) granularity and that is what should be used.
@Mattijs for comments?Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/918inconsistency in defining turbulence field "R"2018-10-09T08:55:44ZAdmininconsistency in defining turbulence field "R"Hello,
There is inconsistency in defining turbulence field "R". Webpage https://www.openfoam.com/documentation/cpp-guide/html/guide-fos-field-turbulence-fields.html#sec-fos-field-turbulence-fields-usage shows Fields stored on the mesh d...Hello,
There is inconsistency in defining turbulence field "R". Webpage https://www.openfoam.com/documentation/cpp-guide/html/guide-fos-field-turbulence-fields.html#sec-fos-field-turbulence-fields-usage shows Fields stored on the mesh database with the prefix ***turbulenceModel*** whereas it is stored with ***turbulenceProperties***
@Pawan @andyhttps://develop.openfoam.com/Development/openfoam/-/issues/2687Inconsistency in ATCModel treatment2023-05-30T17:05:36ZMartin WertherInconsistency in ATCModel treatment<!--
*** 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 -->
When comparing sensitivity maps obtained with "globally" cancelling the ATC term (ATCModel cancel) to 'standard' formulation with wall-near zeroing operating on both parameters, extraConvection and nSmooth, it was seen that results differ more and more from 'cancel' with increasing values for masking. One would assume the opposite since propagating the masking towards the interior of the domain comes close to cancelling globally.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Simply compare results obtained with 'cancel' option to
- ATCModel {ATCModel standard; zeroATCPatchTypes (wall patch); extraConvection n; nSmooth n; }
- ATCModel {ATCModel standard; zeroATCPatchTypes (wall patch); extraConvection n; nSmooth n+10; }
- ATCModel {ATCModel standard; zeroATCPatchTypes (wall patch); extraConvection n; nSmooth n*100; }
e.g., n = 7.
<!-- ### 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 -->
The current implementation
extraConvection * (adjointConvection - mask * altDiscrAdjointConvection)
leads to an unmatched extraConvection*adjointConvection term in the cells affected by the mask.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
@vaggelisp already proposed patching to
extraConvection * mask * (adjointConvection - altDiscrAdjointConvection)
to ensure consistency in the difference causing the aimed for numerical dissipation.
<!-- ### 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 : v2212|v2206|v2112|v2106|v2012 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/590inconsistencies in parsing primitives from strings2017-10-02T07:48:47ZMark OLESENinconsistencies in parsing primitives from stringsParsing from something like `" 123 "` behaves differently if tokenizer is used or readScalar.Parsing from something like `" 123 "` behaves differently if tokenizer is used or readScalar.v1712Mark OLESENMark OLESEN