Why is OGS v6 not a native Linux application, as in OGS v5?

It seems that OGS v6 has become, preferentially, a Windows application in comparison to OGS v5.

There is a partial explanation at this link regarding Linux binaries:

Dune/DumuX, which is similar to OGS, has installation via a Python script. Their website provides you with a script that facilitates setting up a Dune/DuMux directory tree and configures all modules using CMake. Relatively easy to install and run reproducible research on Linux. If you use Windows, DuMuX recommends using Ubuntu bash on Windows.
https://dumux.org/installation/

Would it be possible to offer this python script approach to install OGS v6 on Linux?

There is no preference for any operating system in OGS-6, although some configurations (MFront, MPI) are not supported on Windows. So OGS is a fully native application on every platform.

I guess what you are talking about are the provided precompiled binaries. They work very well on Windows and we fully support it. On Linux / macOS they often only work on a machine running the same operating system version as the machine which built the binaries. So we had lots of complaints from users that the binaries do not run on their system. This is where containers fit, as they will simply run. So we provide container with prebuilt binaries for a better user experience.

You are free to compile OGS natively on every machine and every operating system and it should not be hard to do so: you need a recent compiler, a recent CMake and Git and you are good to go (CMake will handle every required dependency automatically), just follow the developer guide. In the end it comes down to:

git clone https://gitlab.opengeosys.org/ogs/ogs.git
cd ogs
cmake -S . --preset release
cmake --build --preset release
# Run ogs

Compiling ran OK until building netcdf with conan
I have attached the error log and CMakeFile.txt

I don’t understand the error:
CMake Error at /home/l1nux/.conan/data/netcdf-cxx/4.3.1-1/bilke/testing/build/0dedcc9c0a34ef2310bfce5dddb07b68bf577a06/CMakeFiles/CMakeTmp/CMakeLists.txt:15 (target_link_libraries):
The “optimized” argument must be followed by a library.

cmake.check_cache.zip (246 Bytes)

The attached zip did not contain anything useful. Please provide how you configured with CMake (which options you passed) and what the (full) CMake output on the command line was.

Thanks for looking!

Yes, first I will try re-running CMake and copy the full output from the command line.

And yes, the attached zip file is useless, I thought I had included more information.

Ok, I completed the following steps this morning:

Read the Troubleshooting Guide: https://www.opengeosys.org/docs/devguide/troubleshooting/conan/
Deleted the Conan cache directory in $HOME/.conan to start fresh & avoid errors
Cloned ogs v6.4.0 from gitlab: Files · v6.4.0 · ogs / ogs · GitLab
Did not change any options in CMake at the terminal (i.e. used default settings in CMakeLists.txt)

git clone ogs / ogs · GitLab
mkdir build
cd build
cmake …/ogs
cmake --build . --config Release -j 4

At 100% Building:
[100%] Linking CXX executable …/bin/testrunner

/home/l1nux/tmp/Python-3.8.1/./Modules/posixmodule.c:6586: undefined reference to openpty' ... /home/l1nux/tmp/Python-3.8.1/./Modules/posixmodule.c:6684: undefined reference to forkpty’

make[2]: *** [Tests/CMakeFiles/testrunner.dir/build.make:764: bin/testrunner] Error 1
make[1]: *** [CMakeFiles/Makefile2:10185: Tests/CMakeFiles/testrunner.dir/all] Error 2

Is this a Python 3.8.1 issue when building the tests?
Related files attached, including CMake output at the terminal

build_CMake_output.zip (84.4 KB)

I looked in the $HOME/tmp folder and extracted posixmodule.c from the archive Python-3.8.1.tgz

posixmodule.c
at line 6586: if (openpty(&master_fd, &slave_fd, NULL, NULL, NULL) != 0)
at line 6684: pid = forkpty(&master_fd, NULL, NULL, NULL);

From google, I understand the “psuedo-terminal utilities” relevance of openpty, forkpty;
and read links dealing with compilation errors based on the error: “undefined reference”, which was solved by adding -lutil flag to the linker.

That is, to add -lutil to CMAKE_EXE_LINKER_FLAGS and CMAKE_MODULE_LINKER_FLAGS

More clarification here:

Adding the following to CMakeLists.txt did not work; error still there.

  • set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -lutil")
    
  • set(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_MODULE_LINKER_FLAGS} -lutil")
    

openpty and forkpty are not OGS dependencies

Running Python v3.8.1

In the thread you linked the reason for the error was a broken custom python installation. I guess this is the same as reason as for your problem (why should there some Python installation in $HOME/tmp?). So advice to

  • fix (or remove) this custom Python installation
  • OR configure OGS without Python support (-DOGS_USE_PYTHON=OFF CMake option)

Yes, I have now compiled OGS v6.4.0 with the default CMakeLists.txt using an alternative python3 installation. In fact, one that resided in miniconda3.

That seems to suggest that it is a python library issue.
In my case the externally installed Python 3.8.1 didn’t provide the case for testrunner.
Whereas the externally installed miniconda3 version did:
//Path to a program.
_Python3_EXECUTABLE:FILEPATH=/media/l1nux/SAN240/miniconda3/bin/python3.8
//Path to a file.
_Python3_INCLUDE_DIR:PATH=/media/l1nux/SAN240/miniconda3/include/python3.8
//Path to a library.
_Python3_LIBRARY_RELEASE:FILEPATH=/media/l1nux/SAN240/miniconda3/lib/libpython3.8.so

With default compiled, I will now try compiling with Document Explorer=ON