[Bug] r3.flow: test fails on Mac with arm64

[nilason]

Describe the bug

The r3flow_test.py::test_flowlines fails on macOS arm64 platform (it succeeds on x86_64 however).

See details below for test results:

**r3flow_test:** ``` ./raster3d/r3.flow – r3flow_test ❌ Test failed Test r3flow_test Testsuite ./raster3d/r3.flow Test file ./raster3d/r3.flow/testsuite/r3flow_test.py Status FAILED Return code 1 Number of tests 2 Successful tests 1 Failed tests 1 Percent successful 50% Test duration 0:00:01.110401 Tested modules r3.flow Supplementary files standard output (stdout) standard error output (stderr) Standard error output (stderr) F. ====================================================================== FAIL: test_flowlines (__main__.FlowlineTest.test_flowlines) ---------------------------------------------------------------------- Traceback (most recent call last): File "raster3d/r3.flow/testsuite/r3flow_test.py", line 143, in test_flowlines self.assertRaster3dFitsUnivar( File "etc/python/grass/gunittest/case.py", line 337, in assertRaster3dFitsUnivar self.assertModuleKeyValue( File "etc/python/grass/gunittest/case.py", line 271, in assertModuleKeyValue self.fail(self._formatMessage(msg, stdMsg)) AssertionError: r3.univar map=test_flowaccum percentile=90.0 separator== -g difference: mismatch values (key, reference, actual): [('coeff_var', 177.119169754436, 177.793368943374), ('max', 89, 90), ('range', 89, 90), ('stddev', 11.3061070026581, 11.3491433842187), ('variance', 127.828055555556, 128.803055555556)] command: r3.univar map=test_flowaccum percentile=90.0 separator== -g {'map': 'test_flowaccum', 'separator': '=', 'flags': 'g'} ---------------------------------------------------------------------- Ran 2 tests in 1.041s FAILED (failures=1) ``` **r3flow_test stdout:** ``` 0..2..4..6..8..10..12..14..16..18..20..22..24..26..28..30..32..34..36..38..40..42..44..46..48..50..52..54..56..58..60..62..64..66..68..70..72..74..76..78..80..82..84..86..88..90..92..94..96..98..100 Building topology for vector map ... Registering primitives... ``` **r3flow_test stderr:** ``` F. ====================================================================== FAIL: test_flowlines (__main__.FlowlineTest.test_flowlines) ---------------------------------------------------------------------- Traceback (most recent call last): File "raster3d/r3.flow/testsuite/r3flow_test.py", line 143, in test_flowlines self.assertRaster3dFitsUnivar( File "etc/python/grass/gunittest/case.py", line 337, in assertRaster3dFitsUnivar self.assertModuleKeyValue( File "etc/python/grass/gunittest/case.py", line 271, in assertModuleKeyValue self.fail(self._formatMessage(msg, stdMsg)) AssertionError: r3.univar map=test_flowaccum percentile=90.0 separator== -g difference: mismatch values (key, reference, actual): [('coeff_var', 177.119169754436, 177.793368943374), ('max', 89, 90), ('range', 89, 90), ('stddev', 11.3061070026581, 11.3491433842187), ('variance', 127.828055555556, 128.803055555556)] command: r3.univar map=test_flowaccum percentile=90.0 separator== -g {'map': 'test_flowaccum', 'separator': '=', 'flags': 'g'} ---------------------------------------------------------------------- Ran 2 tests in 1.041s FAILED (failures=1) ``` <\details>

[nilason]

I manually followed the test case to be able to better see what's going on:

g.region res=10 res3=10 n=80 s=0 w=0 e=120 b=0 t=50

r3.mapcalc expression="map_1 = 100"
r3.mapcalc expression="map_2 = -20"
r3.mapcalc expression="map_3 = 0.01"
r3.mapcalc expression="map_4 = col() + row() + depth()"
r3.mapcalc expression="map_5 = col() * col() + row() * row() + depth() * depth()"

v.in.ascii -zt input="-" output="test_seeds" z=3 <<EOF                                                       Mapset <user1> in <nc_spm_full_v2alpha2>
84.80609404|35.19733594|39.43321996
14.42915927|56.86951467|22.42338987
29.06094033|78.06029074|39.31707858
64.95524796|50.76614609|12.02301418
75.47677891|18.36008965|29.362122
88.84231714|31.23108675|34.33555293
41.13822083|64.70413255|25.85158957
14.15768282|45.26556161|10.63049231
69.36315244|2.92994235|39.63663467
95.88028571|0.80210167|28.57206445
EOF

r3.flow input=map_5 flowline=test_flowline seed_points=test_seeds \
    flowaccumulation=test_flowaccum direction=down

mkdir data
v.out.ascii input=test_flowline format=standard \
    output=./data/flowline_tmp.ascii precision=6

The assertion: https://github.com/OSGeo/grass/blob/76c1ac531f69c80f88de127fb38819123e9e4784/raster3d/r3.flow/testsuite/r3flow_test.py#L140-L141 succeeds.

The following does not: https://github.com/OSGeo/grass/blob/76c1ac531f69c80f88de127fb38819123e9e4784/raster3d/r3.flow/testsuite/r3flow_test.py#L143-L144

Of the expected values: https://github.com/OSGeo/grass/blob/76c1ac531f69c80f88de127fb38819123e9e4784/raster3d/r3.flow/testsuite/r3flow_test.py#L23-L35 the following deviated:

key             reference              actual
=======================================================
'coeff_var'     177.119169754436       177.793368943374
'max'           89                     90
'range'         89                     90
'stddev'        11.3061070026581       11.3491433842187
'variance'      127.828055555556       128.803055555556

These are the results of r3.univar -g map=test_flowaccum, which indicates that the problem perhaps either lies with r3.univar and/or the expected test results.

I attach the resulting ascii file of:

r3.out.ascii input=test_flowaccum output=./data/testout.ascii.txt

testout.ascii.txt

which (for me) shows a max and range value of 90.

[nilason]

These are the results of r3.univar -g map=test_flowaccum, which indicates that the problem perhaps either lies with r3.univar and/or the expected test results.

Alternatively, if indeed max and range is 89 on Intel architectures, we may have a rounding issue at hand.

[echoix]

Is there a way to do the math once manually or symbolically to have the truth?

[petrasovaa]

These are the results of r3.univar -g map=test_flowaccum, which indicates that the problem perhaps either lies with r3.univar and/or the expected test results.

Alternatively, if indeed max and range is 89 on Intel architectures, we may have a rounding issue at hand.

What may be happening is that the flowlines get counted towards different cell (Rast3d_location2coord) due to some precision issue I don't understand. So it would make sense that sum and mean of the flow accumulation (number of flow lines per cell) are the same, but max and stddev differ. We could therefore test only for sum and mean and avoid this problem, unless you have a better idea.

[petrasovaa]

Is there a way to do the math once manually or symbolically to have the truth?

It's too complicated for that unfortunately.

[echoix]

Was this worked on finally ? I consider it necessary for the next release.