IborCoupon Instrument Not Being Handled Correctly

[tatmaca]

Hi ORE team,

I recently set up ORE on my MacOS environment using the latest ORE User Guide (dated 24 May 2024) and ran into the following issue after building and running the initial tests. Aside from the examples (which I have not tried yet), tests 2, 4, and 5 passed, but I had 20 cases fail in test 3 (quantext-test-suite), all with a seemingly related root cause that I'm not sure how to resolve.

In each of the 20 cases, I have either of the two error messages:

fatal error: in "QuantExtTestSuite/BondTRSTest/testBondTRS/_0": QuantLib::Error: IborCouponPricer: expected IborCoupon

or

fatal error: in "QuantExtTestSuite/BlackMultilegOptionEngine/testBlack76Displacement": QuantLib::Error: BlackMultiLegOptionEngineBase::calculate(): instrument is not handled: BlackMultilegOptionEngine: coupon type not handled, supported coupon types: Fix, Ibor, ON comp, ON avg, BMA/SIFMA, subperiod. leg = 0 cf = 0, BlackMultilegOptionEngine: coupon type not handled, supported coupon types: Fix, Ibor, ON comp, ON avg, BMA/SIFMA, subperiod. leg = 0 cf = 1, BlackMultilegOptionEngine: coupon type not handled, supported coupon types: Fix, Ibor, ON comp, ON avg, BMA/SIFMA, subperiod. leg = 0 cf = 2, BlackMultilegOptionEngine: coupon type not handled, supported coupon types: Fix, Ibor, ON comp, ON avg, BMA/SIFMA, subperiod. leg = 0 cf = 3, BlackMultilegOptionEngine: coupon type not handled, supported coupon types: Fix, Ibor, ON comp, ON avg, BMA/SIFMA, subperiod. leg = 0 cf = 4, BlackMultilegOptionEngine: coupon type not handled, supported coupon types: Fix, Ibor, ON comp, ON avg, BMA/SIFMA, subperiod. leg = 0 cf = 5

with the filepaths for the different test cases changed, of course. I have not edited any of the files and am not sure how to move forward. If there is any more information I can provide to help provide more context, please let me know.

I am running Boost 1.88.0 and my OS is MacOS 15.5.

Thank you!

[pcaspers]

Thank you, we reproduce this locally, looking into it.

[pcaspers]

This seems to be related to the way symbols are resolved on OSX. From the ld man page

Two-level namespace By default all references resolved to a dynamic library record the library to which they were resolved. At runtime, dyld uses that information to directly resolve symbols. The alternative is to use the -flat_namespace option. With flat namespace, the library is not recorded. At runtime, dyld will search each dynamic library in load order when resolving symbols. This is slower, but more like how other operating systems resolve symbols.

One possible fix is to add

    if (APPLE)
        add_linker_flag("-flat_namespace" supportsFlatNameSpace)
    endif()

here https://github.com/OpenSourceRisk/Engine/blob/master/cmake/commonSettings.cmake#L131.

As far as I understand this would also have the advantage that the symbol lookup is closer to what Linux does, thereby simplifying maintenance.

The alternative would be to try and make the two-level namespace work on OSX. At the moment I would tend to add the flat_namespace flag though.

Thoughts? Could you test that fix on your machine and let us know whether it works for you?

[tatmaca]

Thanks for the prompt response.

I've made the suggested edit to the .cmake file:

...
else()
    if (NOT DEFINED BUILD_SHARED_LIBS)
        # build shared libs always
        set(BUILD_SHARED_LIBS ON)
    endif()

    if (APPLE)
        add_linker_flag("-flat_namespace" supportsFlatNameSpace)
    endif()

    # Issue with Boost CMake finder introduced in version 1.70
    set(Boost_NO_BOOST_CMAKE         ON)
...

I then deleted my old build folder and then ran the following terminal prompts:

mkdir build && cd build
cmake -DBOOST_ROOT=$BOOST_INC -DBOOST_LIBRARYDIR=$BOOST_LIB -DQL_ENABLE_SESSIONS=ON ..

Which yielded the following output:

-- The CXX compiler identification is AppleClang 17.0.0.17000013
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at cmake/commonSettings.cmake:21 (check_linker_flag):
  Unknown CMake command "check_linker_flag".
Call Stack (most recent call first):
  cmake/commonSettings.cmake:133 (add_linker_flag)
  CMakeLists.txt:27 (include)


-- Configuring incomplete, errors occurred!

Some of the lower-level details go over my head, but I'm confused by this error, as the add_linker_flag is used later in the .cmake file in what is (now) line 150. Any thoughts on how to resolve this error?

[pcaspers]

Which cmake version are you using? The check_linker_flag() function that the configure step is complaining about was added in 3.18:

https://cmake.org/cmake/help/latest/module/CheckLinkerFlag.html

[pcaspers]

I realize that our cmake version check is not correct, if you have a major version >= 4:

if(CMAKE_MINOR_VERSION GREATER 18 OR CMAKE_MINOR_VERSION EQUAL 18)
    include(CheckLinkerFlag)
endif()

If this is the case, can you just delete this check for your testing? A similar check appears in the same file after # add pthread flag and should be deleted as well.

I'll fix this in 1.8.13.1 as well of course - we require cmake 3.18 anyhow, so these checks should be removed entirely.

[tatmaca]

Ah, I see. I am indeed running version 4.0.3—I did resolve the check_linker_flag() issue by removing the check in commonSettings.cmake.

I'm waiting for the make call to finish and will let you know when I run the tests to see if this fixes the original issue I encountered.

[tatmaca]

Looks like that solved it! Thanks again for the help.

P.S. Just to confirm, Test 1 will not be run with the ctest command because those examples are run manually afterwards, correct?

[pcaspers]

Test 1 are the examples right? They should run, but there might be a problem with locating the ore executable. You can check with:

ctest -R examples -V

The logic to locate the ore executable is here

https://github.com/OpenSourceRisk/Engine/blob/master/Examples/ore_examples_helper.py#L114

You might just overwrite the entire function with

    def _locate_ore_exe(self):
        self.ore_exe = "/Users/peter.caspers/oreplus/build/macOS-clang-ninja-clang_asan_o2/ore/App/ore"
        print_on_console("Using ORE executable " + (os.path.abspath(self.ore_exe)))

replacing the path with where your executable sits. I guess we need to review this function, too.