deconvolution code

[pavlis]

Ian, could you pull the add_deconvolution branch and see if it build correctly for you? It builds for me, but I'm getting this mysterious error on macos:

[Pavlis-Macbook:cxx/build/python] pavlis% python
Python 3.6.5 (default, Mar 22 2019, 21:04:14) 
[GCC 4.2.1 Compatible Clang 5.0.0 (trunk 306208)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ccore
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: dlopen(/Users/pavlis/src/mspass/cxx/build/python/ccore.cpython-36m-darwin.so, 2): Symbol not found: __ZN6mspass3agcERNS_14CoreSeismogramEd
  Referenced from: /Users/pavlis/src/mspass/cxx/build/python/ccore.cpython-36m-darwin.so
  Expected in: flat namespace
 in /Users/pavlis/src/mspass/cxx/build/python/ccore.cpython-36m-darwin.so

It is complaining about the CoreSeismogram object, I think, as the other random characters are from name mangling. Note I can confirm this in a more raw form from this low level approach. Used

nm ccore.cpython-36m-darwin.so > nm.out
vi nm.out

With that If find this section in nm.out

00000000002101c0 t __ZN6mspass29compute_energy_concentrationsEPdidS0_i
00000000001e1c90 t __ZN6mspass2L2ERNS_7dmatrixE
00000000002afb60 t __ZN6mspass2trERKNS_7dmatrixE
0000000000211270 t __ZN6mspass3ERR6getmsgEPc
00000000002112a0 t __ZN6mspass3ERR6getmsgEv
0000000000211240 t __ZN6mspass3ERRC1EPKc
0000000000211210 t __ZN6mspass3ERRC2EPKc
                 U __ZN6mspass3agcERNS_14CoreSeismogramEd
00000000002ad7b0 t __ZN6mspass3degEd
00000000002ad790 t __ZN6mspass3radEd
00000000002f8ff0 s __ZN6mspass3wtfE
00000000001e1ba0 t __ZN6mspass4LinfERNS_7dmatrixE
00000000002f9008 s __ZN6mspass4nwtfE

Any ideas how to sort this out? I'm going to try this on my ubuntu machine to see if that can give me some insight, but in any case it might be helpful to see if you reproduce this on your mac.

[pavlis]

Update on this. I pulled that branch to carbonate and after some hiccups with the gcc confusion (seems I still need the -CMake flag incantation - thought we had cured that) I got this message when it tried to link the ccore python library:

[ 80%] Linking CXX shared module ccore.cpython-36m-x86_64-linux-gnu.so
/bin/ld: ../gsl/lib/libgsl.a(fft.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/bin/ld: ../gsl/lib/libgsl.a(error.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/bin/ld: ../gsl/lib/libgsl.a(stream.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
make[2]: *** [python/ccore.cpython-36m-x86_64-linux-gnu.so] Error 1
make[1]: *** [python/CMakeFiles/ccore.dir/all] Error 2
make: *** [all] Error 2

This suggests we may have a linking configuration error, but I don't know how to track this down. Any ideas you could give on this would be appreciated as I'm stuck on debugging the deconvolution code until we resolve this.

Note that cmake is still building a custom copy of gsl on carbonate. It isn't finding the one the sysadmins have built. I don't think that is the problem here though.

[wangyinz]

I think I know what it is. It is some weirdness of Python library's requirement. Let me try to fix it.

[wangyinz]

So I got it fixed with adding the -fPIC flag in https://github.com/wangyinz/mspass/commit/fa7188e26c4ba7792a03861eae8ed6096023b1ae. The issue is that the python libraries are shared objects so it requires all the static libraries being linked to be compiled with "position-independent code". The caveat here is that if you are using a GSL provided by the system, it may not be compiled with -fPIC, and you will see the same error. I guess the fix will be always use our own GSL builds in cmake.

[pavlis]

Hmmm - this doesn't seem to have fixed the problem on any platform I've tested. What I've tried is:

1. Pulled your changes to macos test version on my laptop. It still produces the error about the CoreSeismogram mangled name not being defined.
2. I get the same behavior on carbonate.
3. On my ubuntu machine trying to load the ccore module causes python to seg fault immediately. i.e. import ccore causes a seg fault.
4. Tested pulling the master branch form mspass and building it. This confirmed that the problem was created by something changed in the add_deconvolution branch. i.e master works fine.

I am stumped. Not sure what to do next. Any tools you can think of the help us sort this out? ldd doesn't show any difference between the master and add_deconvolution generated ccore module except for the expected line for gsl. Did you actually test anything more than getting things to link without an error? I'm passing the ball to you to solve this problem - not critical as I'm not planning on doing that much this weekend and next week I'm traveling to visit grandkids.

[wangyinz]

You are correct, I only fixed the issue at linking stage and did not test it in Python. The original issue is actually a combination of two: 1) failed at linking stage because of lack -fPIC in GSL, and 2) inconsistency between the algorithm.h header and the actual implementation. So, I have (1) fixed, but you can still see errors at linking stage probably because the machines you are testing has a system GSL library provided, and it is not compiled with -fPIC. This is likely what happened on Carbonate.

In the case it linked fine but failed when importing the module, the error message is like this:

>>> import ccore
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: /mspass/git/mspass/cxx/build/python/ccore.cpython-36m-x86_64-linux-gnu.so: undefined symbol: _ZN6mspass3agcERNS_14CoreSeismogramEd

As the mangled name suggested, it is the agc function not defined. I looked at the difference with the master branch and found this. You have changed all TimeSeries and Seismogram to the CoreTimeSeries and CoreSeismogram. However, such changes do not appear in the implementations (e.g. agc.cc). I guess you probably have that locally but somehow missed to commit to the repo.

[pavlis]

First, thanks for finding that fix so fast. I'm impressed as I have no idea how you figured that out so quickly. Please educate me if possible.

Bad news is we still aren't there, and I'm getting different, but similar behavior on three different platforms I've tested this. I can only easy get details on two which are:

1. When I import ccore in macos on my laptop I get this:

   [Pavlis-Macbook:cxx/build/python] pavlis% python 
   Python 3.6.5 (default, Mar 22 2019, 21:04:14) 
   [GCC 4.2.1 Compatible Clang 5.0.0 (trunk 306208)] on darwin
   Type "help", "copyright", "credits" or "license" for more information.
   >>> import ccore
   Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   ImportError: dlopen(/Users/pavlis/src/mspass/cxx/build/python/ccore.cpython-36m-darwin.so, 2): Symbol not found: __Z5dcopyiPdiS_i
   Referenced from: /Users/pavlis/src/mspass/cxx/build/python/ccore.cpython-36m-darwin.so
   Expected in: flat namespace
   in /Users/pavlis/src/mspass/cxx/build/python/ccore.cpython-36m-darwin.so

2. On the carbonate.uits.iu.edu cluster I get this:

   [pavlis@h1 python]$ python
   Python 3.6.1 (default, Jun 28 2017, 11:37:04) 
   [GCC Intel(R) C++ gcc 6.3 mode] on linux
   Type "help", "copyright", "credits" or "license" for more information.
   >>> import ccore
   Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   ImportError: /geode2/home/u070/pavlis/Carbonate/src/mspass/cxx/build/python/ccore.cpython-36m-x86_64-linux-gnu.so: undefined symbol: _ZN4YAML6detail9node_data10set_scalarERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE

In both cases there is a linking problem. Macos one is for dcopy, which is mysterious, and the carbonate error is a function in the yaml library. I don't remember what I got for the ubuntu machine I tried all this on.

Any more great ideas?

[wangyinz]

Well... this is strange. So I went on Carbonate and compiled the code with these modules:

  1) intel/19.0.5       4) git/2.13.0         7) boost/gnu/1.72.0
  2) perl/5.24.1        5) core               8) python/3.6.8
  3) quota/1.2          6) cmake/gnu/3.8.0    9) gcc/9.1.0

and this command:

cmake .. -DCMAKE_C_COMPILER=gcc  -DCMAKE_CXX_COMPILER=g++ -DCMAKE_Fortran_COMPILER=gfortran -DBOOST_ROOT=/N/soft/rhel7/boost/gnu/1.72.0

When everything is done, and I do the import ccore in Python3, I can only reproduce the error similar to the first one you listed complaining about the dcopy undefined.

I was able to get ride of that with:

diff --git a/cxx/src/lib/deconvolution/ShapingWavelet.cc b/cxx/src/lib/deconvolution/ShapingWavelet.cc
index d301ea7..6b177b1 100644
--- a/cxx/src/lib/deconvolution/ShapingWavelet.cc
+++ b/cxx/src/lib/deconvolution/ShapingWavelet.cc
@@ -7,8 +7,9 @@
 #include "mspass/deconvolution/ShapingWavelet.h"
 #include "mspass/deconvolution/wavelet.h"
 #include "mspass/deconvolution/FFTDeconOperator.h"
+#include "misc/blas.h"
 /* Temporary until we resolve the blas include issue */
-void dcopy(int,double*,int,double*,int);
+//void dcopy(int,double*,int,double*,int);
 //
 using namespace mspass;
 namespace mspass{

This is just an issue created with a wrong blas interface. We should now use the misc/blas.h header to properly call those BLAS and LAPACK functions. After having that addressed, the error turns into:

>>> import ccore
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: /tmp/mspass/mspass/cxx/build/python/ccore.cpython-36m-x86_64-linux-gnu.so: undefined symbol: _ZN6mspass15sparse_convolveERKNS_14CoreTimeSeriesERKNS_14CoreSeismogramE

which is pretty much the same issue I mentioned earlier, I didn't get that fixed as I thought you have the modified code locally.

[wangyinz]

OK, I take that back. The last error is actually yet another bug... which can be fixed by:

diff --git a/cxx/src/lib/deconvolution/CMakeLists.txt b/cxx/src/lib/deconvolution/CMakeLists.txt
index 343d7ad..4982e28 100644
--- a/cxx/src/lib/deconvolution/CMakeLists.txt
+++ b/cxx/src/lib/deconvolution/CMakeLists.txt
@@ -6,6 +6,6 @@ include_directories(
   ${PROJECT_SOURCE_DIR}/include)

 add_library(deconvolution STATIC ${sources_deconvolution})
-target_link_libraries(deconvolution PRIVATE seismic utility ${BLAS_LIBRARIES} ${LAPACK_LIBRARIES} ${GSL_LIBRARIES} )
+target_link_libraries(deconvolution PRIVATE seismic utility algorithms ${BLAS_LIBRARIES} ${LAPACK_LIBRARIES} ${GSL_LIBRARIES} )

It is because the libdeconvolution is dependent on libalgorithms, and it is not linked at all. Bad news is, after fixing that, the errors turns into:

>>> import ccore
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: generic_type: type "CNR3CDecon" referenced unknown base type "mspass::Base3CDecon"

It appears to be something related to pybind11? I am not quite sure how to fix this one...

[pavlis]

Thank you for digging into this so quickly. It is late and I would mess this up if I tried working on it now, but I can see exactly what is wrong creating your last error. I messed up the wrapper for that new CNR3CDecon operator. It relates to the obnoxious thing pybind11 requires they call a trampoline class. As I understand it a trampoline class is required to get polymorphic classes to behave as they should. Anyway, I can see I missed a step. Hopefully I can make some progress this way. Thanks again.

[pavlis]

Well, problem mostly solved, but there is a residual problem I'll describe after documenting what I found and had to do.

The main issue that created the last problem you noted was something I honestly didn't completely solve. There is some kind of oddity with multiple inheritance in pybind11 that I could not resolve to get the wrappers for the new CNR3CDecon operator to build. I kept getting errors about ambiguous overloads, which seem to be traced to this construct:

class CNR3CDecon : public FFTDeconOperator, public Base3CDecon

I have lots of similar constructs, but this one kept generating this kind of error:

/N/u/pavlis/Carbonate/src/mspass/cxx/build/pybind11/include/pybind11/pybind11.h: In instantiation of 'Return (Derived::* pybind11::method_adaptor(Return (Class::*)(Args ...)))(Args ...) [with Derived = mspass::Base3CDecon; Return = mspass::Metadata; Class = mspass::CNR3CDecon; Args = {}]':
/N/u/pavlis/Carbonate/src/mspass/cxx/build/pybind11/include/pybind11/pybind11.h:1111:45:   required from 'pybind11::class_<type_, options>& pybind11::class_<type_, options>::def(const char*, Func&&, const Extra& ...) [with Func = mspass::Metadata (mspass::CNR3CDecon::*)(); Extra = {char [56]}; type_ = mspass::Base3CDecon; options = {PyBase3CDecon}]'
/N/u/pavlis/Carbonate/src/mspass/cxx/python/mspass_wrapper.cpp:893:108:   required from here
/N/u/pavlis/Carbonate/src/mspass/cxx/build/pybind11/include/pybind11/pybind11.h:1025:66: error: static assertion failed: Cannot bind an inaccessible base class method; use a lambda definition instead
 1025 |     static_assert(detail::is_accessible_base_of<Class, Derived>::value,
      |                                                                  ^~~~~
/N/u/pavlis/Carbonate/src/mspass/cxx/build/pybind11/include/pybind11/pybind11.h:1027:12: error: cannot convert 'mspass::Metadata (mspass::CNR3CDecon::*)()' to 'mspass::Metadata (mspass::Base3CDecon::*)()' in return
 1027 |     return pmf;

I decided that for this particular example polymorphism was not a high priority, so I dropped the Base3CDecon class completely. If we need that capability later, we can deal with it then.

Now the residual problem. There is clearly a configuration difference in linux relative to macos related to a problem you and I know well from previous experience: the traditional unix linker (ld) does not look at a library twice. That is, if you need somthing like the math library it is common to see constructs like this:

g++ blah blah -lm -lseispp -lglcgrid -lm

The residual issue, I think, is related to yaml as I continue to get the same error noted above with node_data. Any idea how to fix this? The current version of add_deconvolution should generate the same error for you on carbonate or, I hypothesize, any linux implementation

[pavlis]

Hmmm - not a linux issue. When I tried the revision on my ubuntu test machine that problem does not appear. Must be some peculiarity of the known but mysterious oddities of the way carbonate is configured. My next development steps are all going to be done outside carbonate unless I run into something that requires totalview so this has gone to a very low priority.

[pavlis]

I would like to ask your help on something I think you may be able to solve more easily than me beating my head against the wall on something I only marginally understand. It fits this thread because it is the latest problem with what I think is a yaml library linking problem. I base that on this error I get trying to run a test python script on carbonate:

[pavlis@i7 tests]$ python testcnr3c.py
Traceback (most recent call last):
  File "testcnr3c.py", line 16, in <module>
    from mspasspy.ccore import AntelopePf
ImportError: /geode2/home/u070/pavlis/Carbonate/src/mspass/python/mspasspy/ccore.cpython-36m-x86_64-linux-gnu.so: undefined symbol: _ZN4YAML6detail9node_data10set_scalarERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE

Searching for "node_data" and I find a node_data.h file in the yaml library code. Now that name may not be that unique so consider that only a hypothesis. I had the same observation earlier in this thread. The error is thrown when executing import AntelopePf, which references MetadataDefinitions that depends on yaml, so they hypothesis is probably correct.

I do not get this error on my ubuntu machine. I was pushing the testing to carbonate, however, because the algorithm being tested in this script (CNR3CDecon) is aborting with a memory corruption error. I wanted to try to solve this issue with totalview as I have no tools on that machine I know how to solve that kind of problem. It almost certainly means the program has some stray pointer away from the point that is actually aborting. Totalview's memory debugger is pretty good at finding that kind of thing, although debugging a routine behind a python wrapper is adventure land.

I'm rambling. What I'd like to ask you to do is pull the add_deconvolution branch on carbonate and build it. You will need to manually (cp) install the ccore components in python/mspasspy unless you know how to install it more properly (if so please educate me). Then cd to python/tests. Again unless you know how to do this more properly edit the sys.path.append line to point at your version of ccore and execute the same line that is throwing the error above (python testcnr3c.py). What to do next depends upon what happens. If you get the same thing I do perhaps you can figure out what is causing the problem. If you don't get this tell me your modules configuration as that has proven to be an issue with carbonate previously.

[wangyinz]

hmmm.... I can't reproduce that error on Carbonate. To build the code, I used exactly the same modules I listed earlier:

[wangyinz@h1 python]$ module list
Currently Loaded Modulefiles:
  1) intel/19.0.5       4) git/2.13.0         7) python/3.6.8
  2) perl/5.24.1        5) core               8) boost/gnu/1.72.0
  3) quota/1.2          6) gcc/9.1.0          9) cmake/gnu/3.8.0

Then, the config line is like:

cmake .. -DCMAKE_C_COMPILER=gcc  -DCMAKE_CXX_COMPILER=g++ -DCMAKE_Fortran_COMPILER=gfortran -DBOOST_ROOT=/N/soft/rhel7/boost/gnu/1.72.0

After calling make, I did:

[wangyinz@h1 build]$ cd python/
[wangyinz@h1 python]$ ls
CMakeFiles  ccore.cpython-36m-x86_64-linux-gnu.so
Makefile    cmake_install.cmake
[wangyinz@h1 python]$ python3
Python 3.6.8 |Intel Corporation| (default, Apr 12 2019, 17:34:58)
[GCC 4.8.2 20140120 (Red Hat 4.8.2-15)] on linux
Type "help", "copyright", "credits" or "license" for more information.
Intel(R) Distribution for Python is brought to you by Intel Corporation.
Please check out: https://software.intel.com/en-us/python-distribution
>>> from ccore import AntelopePf
>>> from ccore import MetadataDefinitions

As you can see, there is no error from those import lines.

I think I came across this node_data related error before when I was trying to debug it on Carbonate. It seems to be that CMake incorrectly found a yaml-cpp package installed somewhere else instead of from the current build. I was able to fix that issue by removing any previous builds. Maybe that's something you could try. If not, probably we will need to schedule a call to resolve this.

[pavlis]

Well, that did it, but I don't know which of two things did it. I was using a different cmake line but I also removed the build directory before running cmake. I should have tried the later before - something that seems necessary sometimes. Thanks for looking into this.

[pavlis]

Would you please send me the .modules file you currently have on carbonate? I'm now getting a weird collision with intel libraries where I think the python interpreter is incorrectly loading some needed library built with an incompatible library.

One more example of how helpful using a container will be for any user who isn't a developer.

[wangyinz]

Well, I don't really have one other than whatever the default is. I've been manually loading those modules when debug the issues above. What is that collision? Maybe I can try to reproduce it on my end.

[pavlis]

I was not sure where I should insert this comment, but decided I'd put it here only because I encountered the problem trying to get some deconvolution python scripts I had running before the API changes. It is actually a more generic problem with the python-C++ interfacing so could have put this lots of places.

Anyway, the version of ccore created by the current form of the branch add_deconvolution throws this error if you try to import ccore:

import mspasspy.ccore
Traceback (most recent call last):

  File "<ipython-input-2-d5eddcccb42f>", line 1, in <module>
    import mspasspy.ccore

ImportError: /home/pavlis/src/mspass/python/mspasspy/ccore.cpython-36m-x86_64-linux-gnu.so: undefined symbol: _ZN6mspass10WindowDataERKNS_10TimeSeriesERKNS_10TimeWindowE

I am pretty sure that is referencing this function:

CoreTimeSeries WindowData(const CoreTimeSeries& parent, const TimeWindow& tw);

defined in the pybind11 wrappers like this:

m.def("WindowData",&mspass::WindowData,"Reduce data to window inside original",
    py::return_value_policy::copy,
    py::arg("d"),
    py::arg("twin") )
  ;

I cannot understand why that is an undefined symbol? Any ideas on how to sort this out? It suggests the .so file is not properly built, but that is only a hypothesis.

[wangyinz]

Undefined symbol is usually something missing in the linking stage, but we have also encountered it before with inconsistent headers and implementations. Probably latter is more likely.

[wangyinz]

Well, if you look at the message, it says _ZN6mspass10WindowDataERKNS_10TimeSeriesERKNS_10TimeWindowE, which should correspond to a signature more like WindowData(TimeSeries& parent, TimeWindow& tw), but you referred a function with CoreTimeSeries. Maybe that is the inconsistency?

[pavlis]

Thanks, I realized both of the above. I have been trying to find any inconsistency and haven't been able to see any. It is quite mysterious. Tried commenting out the wrappers for WindowData and CNR3CDecon (which is only class presently defined in the wrappers that uses WindowData) and I still get the same error when it seg faults.

I did try this and it give us more data:

pavlis-home-linux:~/src/mspass/cxx/build/python> ldd -r ccore.cpython-36m-x86_64-linux-gnu.so 
    linux-vdso.so.1 (0x00007ffdee1fb000)
    libboost_serialization.so.1.71.0 => /home/pavlis/src/mspass/cxx/build/boost/lib/libboost_serialization.so.1.71.0 (0x00007f2cb74f8000)
    libpython3.6m.so.1.0 => /usr/lib/x86_64-linux-gnu/libpython3.6m.so.1.0 (0x00007f2cb6e48000)
    liblapack.so.3 => /usr/lib/x86_64-linux-gnu/liblapack.so.3 (0x00007f2cb65a8000)
    libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 (0x00007f2cb6338000)
    libgsl.so.23 => /usr/lib/x86_64-linux-gnu/libgsl.so.23 (0x00007f2cb5ed0000)
    libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f2cb5b40000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2cb57a0000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2cb5588000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2cb5190000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2cb4f70000)
    libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f2cb4d38000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2cb4b18000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2cb4910000)
    libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f2cb4708000)
    libgfortran.so.4 => /usr/lib/x86_64-linux-gnu/libgfortran.so.4 (0x00007f2cb4328000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f2cb86c8000)
    libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007f2cb40e8000)
undefined symbol: _ZN6mspass10WindowDataERKNS_10TimeSeriesERKNS_10TimeWindowE   (./ccore.cpython-36m-x86_64-linux-gnu.so)

I think the way this output works is that the first lines are the standard output of ldd pointed at an so file. The last line shows this symbol is not defined in the library for some reason. That is mysterious because it most certainly is compiled (I can see that happen running cmake/make) and I can see the .o file in build:

pavlis-home-linux:~/src/mspass/cxx/build> ar -t src/lib/algorithms/libalgorithms.a 
agc.o
seismogram_helpers.o
slice_and_dice.o
sparse_convolve.o
tseries_helpers.o

noting WindowData is in slice_and_dice.o. I don't know where else to look. Really stumped with this one.

Before wasting your time on this, let me try building it with clang and on carbonate. Maybe one of them will turn up a difference we can use to diagnose this.

[pavlis]

Well, I got exactly the same error with clang and a fresh copy on quakes (now rebuilt). Got into the usual confusing compilations and stopped trying with carbonate as I don't expect a different answer there, only confusion with the complicated configuration issues there.

The quakes experiment does allow me to rule one thing out. For some reason on my ubuntu machine here at home I have the link problem with boost I was patching with LD_LIBRARY_PATH. That wasn't necessary on quakes, so I don' t think that is the issue. I am out of ideas for now. If you can think of anything please pass it along.

[wangyinz]

Let me give it a try. Is the add_deconvolution branch in sync?

[wangyinz]

I guess it is not the latest as I had to fix a pybind11 include path to get it to compile. Anyway, I just fixed the problem and committed it. Turns out it is exactly the WindowData defined in algorithm.h being inconsistent with the implementations.

[wangyinz]

Well, just to clarity, the problem is not in the pybind11 wrapper but really in the C++ code. So basically, if you write a test code that uses that problematic WindowData call will lead to the same error. I think when python imports the library, it will check whether all symbols imported are defined and that's how the error got triggered. That's why commenting out the related wrapper code does not help.

[pavlis]

Well, I don't understand how I missed that. I think this an example of how poor we humans are at seeing subtle differences in something. Reminds me of an email I saw years ago where text was written with large numbers of words missing in a way that a native english speaker had difficulty even seeing the omissions. Like many compiler errors I stared at for absurdly long and failed to see. This one is especially glaring because I know for sure I cross checked that very thing 3 or 4 times and every time I was blind to the mistake. Weird.

Thanks for finding that for me. Why sometimes punting to someone else can help. I owe you one

[pavlis]

I saw you checked in a number of things. Wonder if you caught this one with the pybind11 wrappers. ProcessingHistory contains the ErrorLogger class referenced with the symbol elog. I missed putting that in the wrappers. Seems I should probably merge add_deconvolution into what you are doing to avoid collisions. How should I proceed?

[wangyinz]

Yeah, it is always a good idea to have someone else to take a look.

I already merged API branch to master. You should be able to rebase the decon branch with master to get those fix.

[pavlis]

Am working on a set of pure python wrappers for your scalar deconvolution code (as adapted by me to mspass). I wanted to put part of this into the record as I think it is a model for how most processing algorithms should be built. The issue in a parallel environment we want to guarantee is to reduce overhead in initiation of a process. For the deconvolution code I am doing that by defining this class:

class RFdeconProcessor:
    def __init__(self,alg="LeastSquares",pf="RFdeconProcessor.pf"):
        self.algorithm=alg
        self.pfhandle=mspass.AntelopePf(pf)
        if(self.algorithm=="LeastSquares"):
            md=self.pfhandle.get_branch('LeastSquare')
            self.processor=mspass.LeastSquareDecon(md)
        elif(alg=="WaterLevel"):
            md=self.pfhandle.get_branch('WaterLevel')
            self.processor=mspass.WaterLevelDecon(md)
        elif(alg=="MultiTaperXcor"):
            md=self.pfhandle.get_branch('MultiTaperXcor')
            self.processor=mspass.MultiTaperXcorDecon(md)
        elif(alg=="MultiTaperSpecDiv"):
            md=self.pfhandle.get_branch('MultiTaperSpecDiv')
            self.processor=mspass.MultiTaperSpecDivDecon(md)
        elif(alg="GeneralizedIterative"):
            raise RuntimeError("Generalized Iterative method not yet supported")
        else:
            raise RuntimeError("Illegal value for alg="+alg)
    def loaddata(d,type="Seismogram",window=False):
    def loadnoise(n,type="Seismogram",component=2,window=False):
    def loadwavelet(w,type="Seismogram",component=2,window=False):
    def apply():
    def actual_output():
    def ideal_output():
    def inverse_filter():
    def QCMetrics():
    def change_parameters(md)

As you see the only thing I implemented yet is the constructor, but it is useful to show the idea for a polymorphic entity C++ processor. All it does is define self.processor with the proper C++ constructor and it all should work (at least the books say so). The method are little more than calls to the virtual methods defined in the base class for the supported operators.

The point is a job doing deconvolution should create one of these as a global thing to avoid the overhead of creation in a spark map call. The map operation would then call this function:

def RFdecon(processor,d,wavelet=None,noisedata=None,wcomp=2):

Noting the processor is the global instance of RFdeconProcessor. RFdecon would return a Seismogram object with the deconvolved data and actual output in component wcomp. The function documentation states (written but not pasted in above) the user should call methods like actual_output, ideal_output, etc. after RFdecon returns successfully if those entities are needed. Also note the QCMetrics method will ALWAYS be called before return and the attributes it computes pushed to the output headers (Metadata).

I reiterate that I'm putting this in the record as a model for how to wrap C/C++ code to implement a map or a reduce algorithm. With few exceptions setting up any processing algorithm has an overhead that cannot be neglected. The model of defining the processor as a class and using that class as a required argument for map and reduce algorithms is what we need to stress to users. I think we can and should use this implementation as a model for that concept.