tests 1997.14-15 fail for some values of `OMP_NUM_THREADS`

[bastistician]

(I've been observing this test failure since at least data.table 1.15.4, but I've only now taken the time to look into it and found that it is related to my check.Renviron setting of OMP_NUM_THREADS.)

Minimal reproducible example

Sys.setenv("OMP_NUM_THREADS" = 1)  # or 2, in my case
library("data.table")
#> data.table 1.17.8 using 1 threads (see ?getDTthreads).  Latest news: r-datatable.com
test.data.table(testPattern = "1997")

Output from R 4.5.1 on an Ubuntu 22.04 system

getDTthreads(verbose=TRUE):
  OpenMP version (_OPENMP)       201511
  omp_get_num_procs()            4
  R_DATATABLE_NUM_PROCS_PERCENT  unset (default 50)
  R_DATATABLE_NUM_THREADS        unset
  R_DATATABLE_THROTTLE           unset (default 1024)
  omp_get_thread_limit()         2147483647
  omp_get_max_threads()          4
  OMP_THREAD_LIMIT               unset
  OMP_NUM_THREADS                1
  RestoreAfterFork               true
  data.table is using 1 threads with throttle==1024. See ?setDTthreads.
test.data.table() running: /usr/local/lib/R/site-library/data.table/tests/tests.Rraw.bz2
Running 21 of 7478 tests matching '1997'
Running test id 1997.14         Test 1997.14 ran without errors but failed check that x equals y:
> x = getDTthreads() 
First 1 of 1 (type 'integer'): 
[1] 3
> y = new 
First 1 of 1 (type 'integer'): 
[1] 1
Mean relative difference: 0.6666667
Running test id 1997.15         Test 1997.15 ran without errors but failed check that x equals y:
> x = setDTthreads() 
First 1 of 1 (type 'integer'): 
[1] 3
> y = new 
First 1 of 1 (type 'integer'): 
[1] 1
Mean relative difference: 0.6666667

On this system, it wouldn't fail for OMP_NUM_THREADS >= 3.

These tests also fail on my Alpine Linux system and for both the reference BLAS and "openblas-pthread" (tested in case that could interfere).

[aitap]

Thank you for the report and testing! The test bumps into a discrepancy between how setDTthreads() reads the environment and explicitly given arguments. setDTthreads(threads = NULL) uses the minimum between the number of threads requested through the R_DATATABLE_* environment variables and the OpenMP ICVs (twice, through the API and environment variables), including the 'nthreads-var' ICV as one of the limits. On the other hand, with an explicitly given number or percentage, setDTthreads() respects omp_get_num_procs() and the 'thread-limit-var' OpenMP ICV, but doesn't consult 'nthreads-var'. This makes some sense individually, but breaks the assumption that setDTthreads(percent=...) and R_DATATABLE_NUM_PROCS_PERCENT always do the same thing. It's a bit hard to test reliably, because 'nthreads-var' could be set independently from OMP_NUM_THREADS, and the test only has access to the latter. 2076b80 is a kludge that makes the test consult the environment, but not the OpenMP API, when comparing the results of the two calls to setDTthreads(). I can send it as a PR if it's deemed a good enough idea. (I don't dare change the behaviour of setDTthreads().)

[aitap]

Alternatively, we may test that R_DATATABLE_NUM_PROCS_PERCENT + setDTthreads() sets less or the same number of threads as setDTthreads(percent=...). This is a weaker guarantee than what setDTthreads does, but it will not fail in weird circumstances.