Sif files with Data Explorer

Having compiled the singularity application, which Linux sif file contains DataExplorer?

$ singularity exec --app ogs ogs-6.4.0-serial.sif DataExplorer
FATAL: “DataExplorer”: executable file not found in $PATH

When I extracted the sif file, it seems that DataExplorer is missing in this CLI container;
as the download page states: [Latest Singularity container CLI with Utilities]

I did not have any luck with the other sif files I extracted and would like to avoid testing all of them. The reason I am using singularity is to test the Data Explorer.

Thanks!

ogs-without-linux

Currently we do not provide Singularity container with the Data Explorer. I will investigate it…

@bilke Thanks for replying! Looking forward to seeing Data Explorer in sif mode.

I will post as a separate question “why is OGS v6 not a native Linux application, as in OGS v5”.

Hah, you can already use (download) Singularity container with the Data Explorer but they are hidden a little bit:

$ singularity exec --app ogs gcc-default-system-cmake-850a857f-gui-cdf42cf7de64.sif DataExplorer
Could not locate the container application: ogs

Is there something I am missing?

The ogs/bin folder exists in the sif archive, which contains the ogs and DataExplorer executables

Try to run without --app ogs. The docs are a bit outdated in this regard. I will update them…

$ singularity exec gcc-default-system-cmake-850a857f-gui-cdf42cf7de64.sif DataExplorer

QStandardPaths: error creating runtime directory /run/user/1000 (No such file or directory)
QStandardPaths: error creating runtime directory /run/user/1000 (No such file or directory)
dbus[53980]: D-Bus library appears to be incorrectly set up: see the manual page for dbus-uuidgen to correct this issue. (Failed to open “/var/lib/dbus/machine-id”: No such file or directory; UUID file ‘/etc/machine-id’ should contain a hex string of length 32, not length 0, with no other text)
D-Bus not built with -rdynamic so unable to print a backtrace
Aborted (core dumped)

Can you try installing dbus-x11:

sudo apt-get install dbus-x11
sudo service dbus start

dbus-x11 is already installed.

$ sudo service dbus start
Failed to start dbus.service: Operation refused, unit dbus.service may be requested by dependency only (it is configured to refuse manual start/stop). See system logs and ‘systemctl status dbus.service’ for details.

I checked the link you gave for dbus-x11, but this was only useful for Windows 10 users (WSL).

I don’t know… I tested on several Linux machines and for me it worked.

Hi Lars, thanks for your help in answering my questions, it is much appreciated.

I don’t know either, as to why it doesn’t work “out of the box” on Ubuntu 20.04.

Compiling and running OGS/Data Explorer v5, Dune/DuMuX and PALM models on Ubuntu 20.04 is very straightforward.

In my user experience, OGS v6.4 is not only the exception, it seems labyrinthine under Ubuntu 20.04
As though its dependencies were something crafted for WSL on Windows 10 rather than Linux.

I like the OGS v6 video tutorials (https://www.opengeosys.org/docs/tools/getting-started/video-tutorial/), which have helped to get OGS compiled and running using its minimal cmake options. But compiling OGS v6.4 with netcdf has been unsuccessful.

I think we can leave the solution for v6.4 as above; with the proviso I haven’t been able to use it.

Almost all of the core developers of OGS use Linux as their main development environment (only exception is me – macOS and one other developer – Windows). Please do not make any assumptions to what target platform OGS is “crafted” to. Also I don’t get what the difference is between WSL (just an Ubuntu 20.04 virtual machine) on Windows 10 and native Ubuntu 20.04? Installation instructions are exactly the same.

It is a matter of perception regarding usability.

If almost all of the core developers use Linux as their main development environment and the end result for the Linux binary is a sif file, because of compilation/library/… issues, then there is an explicit usability issue for Linux users.

Whereas Windows 10 has native executables with Data Explorer.
The initial perception from the download page is the confidence in the Windows binary.
My initial experience with OGS was using it on a Windows machine.
From that perspective the OS gives an OK plug and chug effect.

But that OS is not the mainstay for reproducible research.

There are native Linux binaries available, which have been compiled but do not necessarily run on Ubuntu 20.04 without the issue of not finding the libraries. Again, a usability issue.

For some reason I have persevered, beyond the call of duty, to understand where and why the compilation fails. This can only improve the perception of usability.

From my perception over the last few days, the experience has been labyrinthine.
But I have solved an important step, getting OGS compiled where the issue was relatively minor.

Using Wine, Ubuntu 20.04 I can start and use OGS v6.4 Data Explorer out of the box.

But not on Ubuntu 20.04 if I try to compile OGS v6.4 with Data Explorer,
or use either the sif file (Data Explorer) or the Ubuntu binaries (Data Explorer) downloaded from Gitlab.

In terms of usability on Linux, that is an anomaly for usability.
That is meant as feedback.

But I can use my compiled version of OGS v6.4 with Paraview.