Python and Cpp interface installation problem/bugs

[jeet]

Hello,
I am utilizing your geopsy library for computing seismic dispersion curves (Rayleigh
dispersion curves).
Recently, we observed that you introduced a new Python interface in the
latest release of your software.

We have endeavoured to install geopsy-3.5.2v and its Python
interface meticulously by following your documentation, adhering to all
the provided instructions for its construction.
However, despite successfully installing the gpdc library itself, the Python interface is
currently non-functional.
It appears that there may be an issue with the build process or perhaps
some essential headers are missing, particularly concerning the files
libGeopsyPyCoreWave.so or libGeopsyPySciFigs.so. The error trace-log is:

Code: Select all

Traceback (most recent call last):
  File "/home/user/example.py", line 3, in <module>
    import GeopsyPySciFigs as SF
  ImportError: dynamic module does not define module export function 

Python seems to be able to locate the file as a module, as it does not
return any errors regarding a missing module (we have correctly added it
to the Python path and configured it for Python 3.9). Nevertheless, an
error arises concerning the dynamic module, which should be associated
with the binary .so file located in the geopsy package folder. We have
tested both versions 3.5.1 and 3.5.2.

The configuration details of the machine and all instructions for its
setup are available in the following Dockerfile within our GitHub
repository:
(https://github.com/ImahnShekhzadeh/geop ... Dockerfile).

Could you please assist us in resolving this issue? We are eager to
utilize the Python interface as it enables us to precisely specify the
frequency vector to gpdc for computing dispersion curves without relying
on a frequency sampling method. Presently, the gpdc executables do not
permit us to specify the exact frequency vector; instead, the frequency
vector is constructed by the program by specifying the sampling method.

Additionally, I attempted to utilize the C++ interface using the
provided example in your documentation. However, even this interface is
not functioning as expected due to some missing header files in the
include folder. For example, when attempting to compile using the
following command it crashes:

Code: Select all

g++ test.cpp -I/home/user/geopsy/include/ -I/home/user/geopsy/include/QGpCoreWave/   -I/home/user/geopsy/include/QGpCoreMath/ -L/home/user/geopsy/lib/  -lQGpCoreWave -lQGpCoreTools -o mytest 

The error is:
In file included from

Code: Select all

/home/user/geopsy/include/QGpCoreMath/AbstractColorPalette.h:30:0,
                 from /home/user/geopsy/include/QGpCoreMath.h:6,
                 from 
/home/user/geopsy/include/QGpCoreWave/ArrivalTime.h:32,
                 from /home/user/geopsy/include/QGpCoreWave.h:6,
                 from test.cpp:1:
/home/user/geopsy/include/QGpCoreMath/QGpCoreMathDLLExport.h:12:10: 
fatal error: QGpCoreMathStatic.h: No such file or directory
 #include "QGpCoreMathStatic.h"
          ^~~~~~~~~~~~~~~~~~~~~
compilation terminated.

It's worth mentioning that both gpdc and fortran are functioning correctly.

Your prompt assistance in resolving these issues would be greatly
appreciated, especially for what concerns the Python interface (highly recommended to our usage)

Sincerely,

Gurjeet Singh

[admin]

Hi Gurjeet,

Thanks for providing this Dockerfile, things can be clearly tested. I had little practical experience playing with docker. I learned a bit. After building the container, I faced the same error as you.

In the configuration line, you have to specify the path where the file "Python.h" is located.

Code: Select all

/opt/conda/lib/python3.10

must be replaced by

Code: Select all

/opt/conda/include/python3.10

The warning messages that Python is not recognized do not pop up when running the global configure script. I will try to fix it for the next releases.

In my environment this single include path is sufficient. However, under your container (Ubuntu), the include files from module numpy are not located under the same location as "Python.h". I found it under

Code: Select all

/opt/conda/lib/python3.10/site-packages/numpy/core/include

I modified your Dockerfile by adding option '-j 8' to speed up the compilation. I also restricted the number of modules to compile to the strict necessary list (see attached file).

There are other details to be fixed to make it run under docker. They are related to the X display. Before running the container:

Code: Select all

xhost +local:docker

To run the container (named geopsypy):

Code: Select all

docker run -it -e DISPLAY=$DISPLAY -v /tmp/.X11-unix:/tmp/.X11-unix -v ~/sandbox/Gurjeet/geopsy:/app/files geopsypy

The last volume mount is to get access to the script file located on my host in ~/sandbox/Gurjeet

The Python modules are now correctly loaded. Note that the first line of the script must be edited to point to the correct Python executable (see the modified documentation page). There is still a bug (that does not appear under my host environment) when plotting the curves: only one plot is visible. If you are just interested in the computation of dispersion curves, you are not concerned (nor by display features).

If you want to compute the dispersion curve at a single frequency, it is best to compute it on larger frequency band that includes your value. The reason is that mode jumping detection is based on the fact that modes are never very close to each other on a large frequency band. But they can be very very close to each other in case of osculation points. In such case, the computation may erroneously jump to a higher order mode and return it as the fundamental. The automatic mode detection checks the validity of the obtained mode at a high frequency (the higher end of your range). Hence, the range must be large enough. The search is restarted with a finer step until passing the validity check or reaching the step limit (false is returned). The sampling must be also reasonable, not just three points. It may work in most cases, but it is prone to fail for some difficult cases. For normally increasing Vs with depth models, the mode identification works fine in nearly all cases. When there are low velocity layers below stiffer layers, things get more complex.

[admin]

Can you submit your test.cpp?

[admin]

The plotting error found in the Docker environment is due to Qt 5. The plotting Python module GeopsyPySciFigs is not working properly with Qt 5. After inquiring, it requires at least Qt 6.5. This is now tested at the configuration stage. The module is disabled if this condition is not met.