Support

Why does the NFDI4Health Helpdesk page show only a placeholder instead of the enquiry form?

The NFDI4Health Helpdesk enquiry form requires JavaScript and the required cookies. If JavaScript is disabled or the required cookies are rejected, the page shows only a placeholder instead of the form. Alternatively, email helpdesk@nfdi4health.de.


Installation and Updates

Why does installing dataquieR appear to work, but library(dataquieR) or dataquieR::some_function() later says that the package is not installed?

An R package installation consists of several stages. Messages about downloading, unpacking, compiling, or building help files do not yet mean that the package was installed successfully. Success is confirmed only by the final message:

* DONE (dataquieR)

With patchwork 1.3.2 and ggplot2 3.5.0 or 3.5.1, the more noticeable error may occur only later, when calling library(dataquieR) or a function with dataquieR::. The actual installation failure is usually earlier in the installation output and can be easy to overlook:

Error: object 'is_ggplot' is not exported by 'namespace:ggplot2'
ERROR: lazy loading failed for package 'dataquieR'
* removing '.../dataquieR'

The final line means that R removed the incomplete installation. The later “there is no package called ‘dataquieR’” message is therefore a consequence of the failed installation, not a separate problem.

If you deliberately need a ggplot2 version below 4.0.0, use version 3.5.2. Restart R first so that the packages are not loaded, then run:

install.packages("remotes")
remotes::install_version("ggplot2", version = "3.5.2")
install.packages("patchwork")
install.packages("dataquieR")

If you do not need to remain below ggplot2 4.0.0, installing the current versions is sufficient:

install.packages(c("ggplot2", "patchwork", "dataquieR"))

Afterwards, verify the installed versions and load the package:

packageVersion("ggplot2")
packageVersion("patchwork")
library(dataquieR)

For installations that must stay below ggplot2 4.0.0, the first command should report version 3.5.2.


Computation

I tried to create my first report and it takes a very long time. It uses up all my memory.

You should first install all the packages suggested by dataquieR to have its full functionality. You can use the following dataquieR function:

prep_check_for_dataquieR_updates(beta = FALSE, deps = TRUE)


Can I install dataquieR with byte-compiled R code?

Yes. The CRAN package is kept small by default, but you can install dataquieR from source with byte-compiled R code if you prefer the faster installed representation and accept the larger installed package size. From R, request R CMD INSTALL --byte-compile with:

install.packages(
  "dataquieR",
  type = "source",
  INSTALL_opts = "--byte-compile"
)

The dataquieR update helper is intended for convenient source and beta updates and uses byte-compiled source installation by default:

dataquieR::prep_check_for_dataquieR_updates()

If you instead prefer the smaller installed package without byte compilation, use:

dataquieR::prep_check_for_dataquieR_updates(byte_compile = FALSE)



Report Generation and Rendering

Report rendering is very slow or appears to hang while “Mounting indicator pages”. Can this be caused by network/proxy settings?

Yes. In some versions before the next beta release 2.8.10.9000 or the next regular release 2.8.11, report rendering may perform synchronous online checks for documentation links while composing the HTML report. On Linux servers, HPC nodes, or Docker containers without direct outbound HTTPS access, this can make the rendering step very slow or look stuck, especially around “Mounting indicator pages”.

As a workaround, make sure the R process or Docker container has working proxy environment variables, for example http_proxy, https_proxy, HTTP_PROXY, HTTPS_PROXY, and suitable no_proxy/NO_PROXY values for local/internal hosts. Alternatively, allow direct HTTPS access to dataquality.qihs.uni-greifswald.de.

This behavior is expected to be fixed in the next beta release 2.8.10.9000 or in release 2.8.11, so report rendering will no longer depend on synchronous online reference checks by default.


On my Linux system/HPC cluster, I have trouble using Cairo, because the underlying system dependencies (e.g, libharfbuzz-icu.so.0) are missing or not working. What can I do?

You can switch your bitmap type for all compute nodes during the report rendering to something supported and different from Cairo:

r <- dq_report2(...
print(r, advanced_options = list(bitmapType = "Xlib"), dir = "/tmp/report")

See: