opensourcerisk / engine Goto Github PK

Hi,

I'm referring to ore::data::Envelope which changed to hold also a NettingSetDetails.
Now, both Envelope ctors that set additionalFields_ will initialize as nettingSetDetails_(NettingSetDetails()).
Then when you call this const string& nettingSetId() const { return nettingSetDetails_.nettingSetId(); it comes out empty.

At least this ctor needs changing:

    //! Constructor with netting set / portfolio ids, with additional fields
    Envelope(const string& counterparty, const string& nettingSetId, const map<string, string>& additionalFields,
             const set<string>& portfolioIds = set<string>())
        : counterparty_(counterparty), nettingSetId_(nettingSetId), nettingSetDetails_(NettingSetDetails()),
          portfolioIds_(portfolioIds), additionalFields_(additionalFields) {}

.. change initialization to include nettingSetDetails_(NettingSetDetails(nettingSetId)).
In anycase, it doesn't seem to be a way to construct an envelope with additional fields and netting set id and later on to recover the netting set id..

Thanks, Laurentiu.

In release 1.8.6.0 this scenario used to work.

With current head of master now we get:

market object FXSpot(INRJPY) required for configuration 'default'
not found, do nothing
market object FXSpot(JPYINR) required for configuration 'default'
not found, do nothing
StructuredErrorMessage { "errorType":"Trade", "tradeId":"NonDeliverableSwap", "tradeType":"Swap", "exceptionType":"Error building trade for context 'oreapp'", "exceptionMessage":"did not find object INRJPY of type fx index under configuration 'default' or 'default'"}

Note that we have both EURINR and EURJPY and INRJPY fx spot should be given by triangulation.

Can provide additional details if necessary.

I am trying to create local image of risk analytics
Access is denied on below repositories. Kindly grant access , my git username is vadaliah
docker pull lballabio/ore
docker tag lballabio/ore ore

Appreciate your help.
Regards,
Hiren

Steps to reproduce:

1. Downloaded ORE-1.8.2.zip to PC running Windows 7 Home Premium Service Pack 1.
   PC has Python 3.6.1 installed.
2. Extracted to C:\Work\ORE-1.8.2.
3. Opened a cmd shell window.
4. Navigated to C:\Work\ORE-1.8.2\Examples\Example_1
5. Executed run.py

Results:

C:\work\ORE-1.8.2\Examples\Example_1>run.py
Traceback (most recent call last):
File "C:\work\ORE-1.8.2\Examples\Example_1\run.py", line 5, in module
    from ore_examples_helper import OreExample
  
File "..\ore_examples_helper.py", line 7, in module
    import matplotlib
ModuleNotFoundError: No module named 'matplotlib'

Note the excel spreadsheet in the same folder (Example_1.xlsm) worked fine once I updated the paths.

I tried several other examples and they have the same issue.

Hi, Apologies if this is not the right place for this issue but I don't see where else to post this.

I signed up on the website and it says that I cannot post any topics nor allowed to comment on any of the existing topics. If its any help, I am using Internet Explorer 11 for signing into the webpage.

Could someone help?

Hi all,
I just want to flag that the current copy fails to build in VS because of the recent rework of FX spots in OREData/marketdata. The files are still listed in the project files (and filters) and need to be removed for a successful build. Let me know if you have this in check already, otherwise I can send a quick PR to clean it up.

Hi Open Source Risk Engine devs,

Many thanks for a really useful tool. I am trying to build a development docker container with OSRE, based on an alpine image. I have successfully built QuantExt but when I try to make install it, I get an error almost at the end:

make[2]: Entering directory '/home/Engine-2a56688ff4d91e378bf88620a45864824150fbc5/QuantEexactlyxt'
make[2]: Nothing to be done for 'install-exec-am'.
 config/install-sh -c -d '/usr/share'
 /usr/bin/install -c -m 644 ./config '/usr/share'
install: omitting directory './config'
make[2]: *** [Makefile:433: install-dist_dataDATA] Error 1
make[2]: Leaving directory '/home/Engine-2a56688ff4d91e378bf88620a45864824150fbc5/QuantExt'
make[1]: *** [Makefile:764: install-am] Error 2
make[1]: Leaving directory '/home/Engine-2a56688ff4d91e378bf88620a45864824150fbc5/QuantExt'
make: *** [Makefile:460: install-recursive] Error 1

Unfortunately, I am more familiar with CMake rather than autotools so I am yet to understand what make is trying to tell me. My theory at present is that it is attempting to install the directory config, which I believe is generated by configure and should probably be skipped (the message install: omitting directory './config' is reminiscent of cp without the -r flag, when copying directories).

Any ideas of thoughts on this are greatly appreciated.

Cheers

Marco

Hi all,
With the ORE 6 release, ore.vcxproj started requiring Windows SDK version 10.0.17763.0 specifically, probably unintentionally. Other versions, e.g. 10.0.18362.0 on my machine, will cause the ore project to fail building in VS, raising MSB8036. Relaxing this to 10.0 makes building the solution easier as it allows for using the latest version available on the machine.

This is fixed by right-clicking the ore project in Solution Explorer, selecting Retarget Projects, and finally picking 10.0 from the drop-down menu. I'll accompany this issue with a PR to close the issue if you agree with this fix.

Best regards,
Fredrik Gerdin Börjesson,
SEB

Hi,

I am now looking for a general use risk framework to be adopted on spatial GIS data domain. Are you close to markets only or OSR is general use engine?

Thx.

Ladislav

Hi,
In QuantExt/qle/time/, there's an implementation of Actual/364 that is currently not used within ORE nor QuantExt. Instead, QuantLib's own implementation of Actual/364 (dated to 2014) is referenced, for example, within the parseDayCounter() function in OREData. The project filter QuantExt.vcxproj.filters still expects the day counter's files to be imported, however, whereas QuantExt.vcxproj does not do so. This causes my Visual Studio instance to throw out the filters as no files are found in the VS project.

The solution is to delete the day counter's files from QuantExt/qle/time and their filters from QuantExt.vcxproj.filters, if considered safe and QuantLib's version suffices.

There is a liker error while linking libOREData.dll, its not able to link with some regex functions from boost.

I've discovered a problem with the funding cost/benefit adjustment:
Expected positive exposures should lead to high(er) FCA and expected negative exposures to high(er) FBA, the results (and the source code, see OREAnalytics/postprocess.cpp, method PostProcess::updateStandAloneXVA(), line 646 ff.) suggest that that ORE calculates this reverted.

Considering that funding costs actually depend on the borrowing spread and funding benefits on the lending spread, the above suggests even more an exchange of the two terms (see also Gregory, The xVA Challenge, page 343 on FVA calculation).

Please see also my posts at [http://www.opensourcerisk.org/forums/topic/fca-versus-fba/] and the pull request #17 .

building ore-swig i get an error building the ore code:

ore/QuantExt/qle/termstructures/kinterpolatedyoyoptionletvolatilitysurface.hpp:121:56: error: no viable conversion from 'const shared_ptr<QuantExt::YoYInflationCapFloorEngine>' to 'const shared_ptr<QuantLib::YoYInflationCapFloorEngine>'
    yoyOptionletStripper_->initialize(capFloorPrices_, yoyInflationCouponPricer_, slope_);

this is fixed by prepending QuantLib:: to every YoYInflationCapFloorEngine in that file or by rejigging QuantExt::YoYInflationCapFloorEngine to derive from QuantLib::YoYInflationCapFloorEngine instead of QuantLib::YoYInflationCapFloor::engine. the later also requires adding a (straightforward) non-default constructor call.

i am not familiar with the code base but it looks like many types exist in both the QuantExt and QuantLib namespaces but the code doesn't appear to (need to) specify namespace much. none of the relevant quantext subclasses appear to implement initialize() so both look fine i think. but i am not sure which approach is more consistent with the style here or if something else should be done.

Dear All!

As we also need to calculate xva values on good friday, I'd like to suggest a relaxation on the date requirement resp. the exact calculation of the CSA compounding rate in NettedExposureCalculator::collateralPaths:

    // Don't use Settings::instance().evaluationDate() here, this has moved to simulation end date.
    Date today = market_->asofDate();
    string csaIndexName = netting->csaDetails()->index();
    // this line throws an Exception if called on good-friday or any other holiday of the resp. CSA index:
    Real csaRateToday = market_->iborIndex(csaIndexName, configuration_)->fixing(today);
    LOG("CSA compounding rate for index " << csaIndexName << " = " << csaRateToday);

A possibility might be to use the forecastTodaysFixing parameter, however then still the QL_REQUIRE would need to be moved after checking this parameter (and returning the forecast rate) in InterestRateIndex::fixing:

Rate InterestRateIndex::fixing(const Date& fixingDate,
                                   bool forecastTodaysFixing) const {

        QL_REQUIRE(isValidFixingDate(fixingDate),
                   "Fixing date " << fixingDate << " is not valid");

        Date today = Settings::instance().evaluationDate();

        if (fixingDate>today ||
            (fixingDate==today && forecastTodaysFixing))
            return forecastFixing(fixingDate);

Another, less intrusive alternative would be to introduce a separate method fixingEstimate here, that is only used for the collateralPaths method above and does the above mentioned relaxation, avoiding the removal of the fixing date check for future forecast fixing dates in general.

I'd like to make a pull request after comments/suggestions on that.

-regards,
Roland

Hi to all,

I was looking at the LGM ZCO formula:

where small t represents the start of the zero cupon bond, but in the implemetation we see (lgm.hpp):

Real sigma = std::sqrt(parametrization_->zeta(t)) * (parametrization_->H(T) - parametrization_->H(S));

Question: Shouldn't it be zeta(S) instead of zeta(t)?

Hi, when browsing the source code I came across two files that seem to have moved from the analytics layer (orea/simulation/dategrid.hpp resp. dategrid.cpp) to the data layer (ored/utilities/dategrid.hpp resp. dategrid.cpp)

There is still one reference to the old location in orea/scenario/scenariogeneratordata.hpp with boost::shared_ptr<ore::analytics::DateGrid> closeOutDateGrid() const { return closeOutDateGrid_; } and
private: boost::shared_ptr<ore::analytics::DateGrid> closeOutDateGrid_;

This member doesn't seem to have much use in the project however. Removing the ore::analytics:: qualifier didn't hurt though.

I've seen that there are 2 missing items in the userguide:

1. in section 7.3.2 Leg Data and Notionals, the elements FXReset and Exchanges with subelements

• ForeignCurrency, ForeignAmount, FXIndex and FixingDays for FXReset and
• NotionalInitialExchange, NotionalFinalExchange and NotionalAmortizingExchange (this element is also missing in the instruments.xsd Schema Definition) for Exchanges

2. in section 9.16 Swaption Implied Volatility the line
   IndexTenor | An integer followed by D, W, M or Y | Underlying index tenor

Hi all!
This issue is to discuss the CreditDefaultSwap instrument available both in QuantLib and QuantExt. The version present in the latter project has additional options for the protection payment time, toggleable through an enum rather than a boolean as in QL. Because the instrument class has been duplicated, we cannot directly link the IsdaCdsEngine available in QL without first altering it to fit the QuantExt CDS instrument used in ORE.

I would propose bringing these changes over to QuantLib as a small initial migration, relating to #83, along with the QuantExt MidPointCdsEngine. Doing so, we can avoid having to copy over the Isda engine to QuantExt as well, which we have had to do now. We will provide a PR with this setup though I am hoping for someone to provide som input on this, such that it may be resolved properly ahead of the next release. What are your thoughts on this?

Best regards,
Fredrik Gerdin Börjesson,
SEB

Hi all,
This issue expands on the problem described in PR #68, as requested. In short, the issue is that for some sets of market quotes, the quadratic interpolation of yield curves will fail in Debug mode but not in Release mode.

Below are the steps to reproduce the issue:
The setup is a Win 32-bit debug build with Boost 1.73 and QL 1.18.

1. Configure a YieldCurve object, in our case that is the arbitrarily selected USD Fed funds curve as of 2020-12-30, in curveconfig.xml like below. We use a large set of sampled monthly quotes reaching from 2020 till 2039 and I want to remark that the issue is not present if we only select 2020–2035 or a shorter span, for example. I also tried this with the included example set (in ORE) but the low number of quotes configured for the curves seemed to make this difficult.

<YieldCurve>
  <CurveId>USD-FEDFUND</CurveId>
  <CurveDescription/>
  <Currency>USD</Currency>
  <DiscountCurve>USD-FEDFUND</DiscountCurve>
  <Segments>
    <Direct>
      <Type>Discount</Type>
      <Quotes>
        <Quote>DISCOUNT/RATE/USD/USD-FEDFUND/2020-12-30</Quote>
        <Quote>DISCOUNT/RATE/USD/USD-FEDFUND/2021-01-30</Quote>
        …
        <Quote>DISCOUNT/RATE/USD/USD-FEDFUND/2039-11-28</Quote>
        <Quote>DISCOUNT/RATE/USD/USD-FEDFUND/2039-12-28</Quote>
      </Quotes>
    </Direct>
  </Segments>
  <InterpolationVariable>Discount</InterpolationVariable>
  <InterpolationMethod>Quadratic</InterpolationMethod>
  <YieldCurveDayCounter>A365</YieldCurveDayCounter>
</YieldCurve>

2. Add the corresponding curve in todaysmarket.xml:

<DiscountingCurve currency="USD">Yield/USD/USD-FEDFUND</DiscountingCurve>

3. Set the ore.xml to output the computed curve for some 180 points with a 1D resolution.
4. Launch the debug build.

We can then observe how the launched debug executable will fail with the error:

Check failed in file C:\...\boost_1_73_0\boost\numeric\ublas\lu.hpp at line 298:
detail::expression_type_check (prod (triangular_adaptor<const_matrix_type, upper> (m), e), cm2)
Error: Cannot build all required curves! Building failed for: (Yield/USD/USD-FEDFUND: yield curve building failed for curve USD-FEDFUND on date 2020-12-30: lu_substitute error: internal logic);

The throw is made here: ql/math/matrix.cpp#L90. Now, if ran as a release build instead, we’ll end up with the below plot if we compute both the linear and the quadratic curves. We can clearly see how only the linearly interpolated discount curve is reasonable. The reason for the quadratically interpolated discount curve beginning from zero is that we were given the skip parameter in the implementation to help with matrix singularity issues. This causes the quote/pillar D(t=0) = 1.0 to be skipped and replaced by zero, by the looks of it. This seems unintentional although ignoring the skip leads to failures when trying to calibrate lambda.

Are we able to shed some light on these two related problems? I assume this issue with singularity and skipping pillars may also carry over partially to the log quadratic interpolation but I have yet to see or hear any complaints of any explicit issues there. I have a dataset with market quotes to share if requested but I'd need to clear this first. We're thankful for any insight into these issues!

Best regards,
Fredrik Gerdin Börjesson,
SEB

Looking at OSR to do some crypto risk management. So two questions:

1. what is the mechanism for synching with main QuantLib branch
2. looking over it's a easy fix to move over to the QuantLib::ext name space so that one can use the std extensions.

Also what's the best way for third parties to coordinate developmment

Hi,
When configuring a cap/floor volatility structure with optional quotes, the class CapFloorVolCurve hardcodes both near and far strike extrapolation to be disabled in the CapFloorTermVolSurfaceSparse class. See capfloorvolcurve.cpp#L643. This prevents hole-filling around the edges, if, say, the given grid of volatilities looks like:

[X - data exists, O - missing data]

This would throw an error along the lines of "interpolation range [-0.5, 1.0]: extrapolation at 2.0 not allowed". There are a few possible solutions to this:
1. Hardcoding the values passed to lowerStrikeConstExtrap and upperStrikeConstExtrap as true, which would align the class with the default behavior of the underlying class OptionInterpolator2d in QuantExt.
2. Enabling or disabling extrapolation depending on the Extrapolation tag already present in the cap/floor volatility config.
3. Exposing a second extrapolation tag in the cap/floor volatility curve configuration to govern this behavior, though I fear this complicates the config unnecessarily.
4. Providing extrapolated market data in market.txt.

I think it would be fine to allow this by default, as in option 1, since it might perhaps be expected from a sparse surface configuration. I will provide a PR for this, although I am open to implementing any other ideas as well.

Best,
Fredrik Gerdin Börjesson,
SEB

After pulling and compiling the new master, I can't run some examples any more (e.g. example 1). ORE stops with messages like

DEBUG [2020-Jun-23 20:43:43.409165] (...data\yieldcurve.cpp:1401) : Adding Segment Cross Currency Basis Swap with conventions "USD-CHF-XCCY-BASIS-CONVENTIONS"
DEBUG [2020-Jun-23 20:43:43.540667] (...tdata\yieldcurve.cpp:668) : Bootstrapping with 13 instruments
ALERT [2020-Jun-23 20:43:43.556290] (...ata\todaysmarket.cpp:871) : StructuredErrorMessage { "errorType":"Curve", "curveId":"Yield/CHF/CHF-IN-USD", "exceptionType":"Failed to Build Curve", "exceptionMessage":"yield curve building failed for curve CHF-IN-USD on date 2016-02-05: 1st iteration: failed at 5th alive instrument, pillar February 9th, 2018, maturity February 9th, 2018, reference date February 5th, 2016: 1st leg: no implementation provided"}

final message: ALERT [2020-Jun-23 20:43:49.742852] (...\orea\app\oreapp.cpp:231) : Error: Cannot build all required curves! Building failed for: (Yield/CHF/CHF-IN-EUR: yield curve building failed for curve CHF-IN-EUR on date 2016-02-05: 1st iteration: failed at 3rd alive instrument, pillar February 9th, 2018, maturity February 9th, 2018, reference date February 5th, 2016: 1st leg: no implementation provided); (Yield/CHF/CHF-IN-USD: yield curve building failed for curve CHF-IN-USD on date 2016-02-05: 1st iteration: failed at 5th alive instrument, pillar February 9th, 2018, maturity February 9th, 2018, reference date February 5th, 2016: 1st leg: no implementation provided); (Yield/GBP/GBP-IN-EUR: yield curve building failed for curve GBP-IN-EUR on date 2016-02-05: 1st iteration: failed at 5th alive instrument, pillar February 9th, 2018, maturity February 9th, 2018, reference date February 5th, 2016: 1st leg: no implementation provided); (Yield/GBP/GBP-IN-USD: yield curve building failed for curve GBP-IN-USD on date 2016-02-05: 1st iteration: failed at 5th alive instrument, pillar February 9th, 2018, maturity February 9th, 2018, reference date February 5th, 2016: 1st leg: no implementation provided);

-regards,
Roland

Hi, I am trying to install ORE. However, I came up with an issue that I am not able to solve:

I work with Osx Sierra. I obtained Boost via homebrew and Boost is located at

/usr/local/Cellar/boost/1.64.0_1/include/
/usr/local/Cellar/boost/1.64.0_1/lib

I can successfully build Quantlib and QuantExt.

./autogen.sh

./configure.sh --with-boost-include=/usr/local/Cellar/boost/1.64.0_1/include –with-boost-lib=/usr/local/Cellar/boost/1.64.0_1/lib

make -j4

Also quantext-test-suite succeeds. Now when I repeat the same for OREdata everything seems to work

checking for Boost development files... yes
checking for Boost version >= 1.55... yes
checking for Boost::uBLAS support... yes
checking for Boost unit-test framework... yes
checking whether Boost unit-test streams work... yes

however, when I run ./test/ored-test-suite

I see the error message:

Running 35 test cases...
dyld: lazy symbol binding failed: Symbol not found: __ZN5boost16re_detail_10620013get_mem_blockEv
Referenced from: /Users/Alessandro/ore/OreData/ored/.libs/libOREData-1.8.2.dylib
Expected in: flat namespace

dyld: Symbol not found: __ZN5boost16re_detail_10620013get_mem_blockEv
Referenced from: /Users/Alessandro/ore/OreData/ored/.libs/libOREData-1.8.2.dylib
Expected in: flat namespace

unknown location:0: fatal error: in "OREDataTestSuite/ParseTest/ParseTest__testStrikeParsing": signal: SIGABRT (application abort requested)

OREData tests completed in 1 s

*** 1 failure is detected in the test module "Master Test Suite"

Any suggestion on how I can fix this? Thank you very much!

I've noticed that you changed the labels for additionalScenarioDataFileName (new: aggregationScenarioDataFileName) and scenariodump (new: aggregationScenarioDataDump). In the userguide this is still described with the old names, the examples have the new aggregationScenarioDataFileName, however the scenariodump parameter is just commented out (although aggregationScenarioDataDump works fine).

-regards,
Roland

Hi,

This is related to #110, only that we're setting <IsInArrears>false</IsInArrears>.
Pricing for this one works, with workaround provided, but XVA doesn't work. It will complain that fx fixing is missing. That's because we're advancing today with simulation and eventually hit an eligible cashflow for which we need the fxRate, but because fixing is in advance and with a negative gap (e.g. fixed before the start of coupon) then will decide that it needs to come from fixings, but that's impossible because fx fixing date is in the future (with regards to actual pricing date).

Note, there are some issues with XVA run currently in master, so maybe check also these commits:

• 1f317d5
• 6de57c3

If more information is needed, please let me know.

Regards, Laurentiu.

Hi, I am trying to install ORE on my MacOS Mojave, but got some troubles. Firstly, when I tried to built "App", the compilation was ended by the error "ld: symbol(s) not found for architecture x86_64". The detailed output of "make -j4" is provided in the file "output_make"; just in case, I also attached the output of "./configure" below. After several hours spent on this issue, I just cannot solve it. Could please help me to figure out the problem?

On the other hand, I am also not 100% sure whether the installation of QuantExt, OREData and OREAnalystics is fully successful. In fact, the compilation for all three doesn't show any error; so I guess it works and continue the next step. However, when I tried to test the installation, the "test-suite" file doesn't exist in their corresponding test file in each of the three; is that because the command "make -j4" didn't fully work? I am really confusing about this and doubt a lot whether the installation is truly accomplished. I do appreciate any support from your side and hopefully we can solve the issue to make ORE running on my computer.

output_.:configure.pdf

output_make.pdf

Hi,
I'm trying to generate a C# class using xsd.exe (in .Net) and the xml schema found in /xsd/instruments.xsd. When running the command: "xsd /c /language:CS instruments.xsd" in the Developer Command Prompt I get the following error message:

Warning: Schema could not be validated. Class generation may fail or may produce incorrect results.
Error: Error generating classes for schema 'instruments'.

• The datatype 'date' is missing.

Has anyone been able to generate C# classes using the schemas in /Xsd/? Is xsd.exe meant to support these xsd-files or is there another tool I can use? I should also add I'm fairly new to this type of xml functionality.

Kind regards,
Mikael

Dear All!
As I have the need to know the accrual start- and enddate along with each cashflow, I'd like to add these to the standard flows report with a pull request. Please comment!

I've added this now in #58 .

-regards,
Roland

Hi, please, explain how to compile QuantExt with VS 2017. There was an error C2516: "Quantext::FxForward::engine is not a legal base class" while compiling ORE. On the other hand, Quantlib compiled without any errors in release mode under the same VS.

I'm just wondering why, I know it's not required by the BSD license, but is there a reason for leaving the QuantExt extensions outside of the QuantLib library itself? If it was pushed to the QuantLib library, there would be many more "eyes" on it from the open source community, and therefore likely more development upon its work. I understand it is the work of the company in support of Open Source Risk, but this would potentially simplify the development ahead for both OSR and QuantLib. And likely reduce maintenance on the side of the OpenSourceRisk project team. I suppose the real question: is it OSR's desire to keep their extensions separate? If they were integrated into QuantLib, along with the test suite, then it would be maintained by QuantLib devs and updates would be automatically done on their side, freeing up the work that OSR devs would have to do with every incremental update of QuantLib. I see there was a session in 2018 where this was discussed, but haven't seen it done yet.

I'm attempting to port it over but I am not exactly a C++ expert. So some of the functions I'm potentially breaking but keeping a list for those that know C++ well so they can fix it properly if they need those functions (I personally don't), mostly by commenting out problematic code segment declarations in MSVC 14.1 (Visual Studio 2017 Community), or adding missing include files that have needed definitions imported. I suppose I'll see if I broke anything by running the QuantExt testsuite against it once I work through the errors. But this would be SO MUCH FASTER if someone well versed in C++ was helping me do it. I'll get the changes into my GitHub fork probably in the next week or so, once I get it compiling as a standalone library.

Hi,
I am trying to install ORE in MacOSX Sierra; but I'm having an issue that I am not able to solve:

I obtained Boost via homebrew and Boost is located at

/usr/local/Cellar/boost/1.67.0_1/include/
/usr/local/Cellar/boost/1.67.0_1/lib

I can successfully build Quantlib and QuantExt.

When I repeat the same for OREData everything seems to work

however, when I run ./test/ored-test-suite

I see the following error message:

Running 54 test cases...
unknown location:0: fatal error: in "OREDataTestSuite/FXSwapTest/FXSwapTest__testFXSwap": memory access violation at address: 0x00000000: no mapping at fault address

*** 1 failure is detected in the test module "Master Test Suite"

Any suggestion on how I can fix this? Thank you very much!

9.6. states that
1)
the definition of the futures includes 5 Tokens. However in ORE 6 are expected. The sixth one is the tenor.
So MM FUTURE/PRICE/EUR/JUN18/LIF3ME would be MM FUTURE/PRICE/EUR/JUN18/LIF3ME/3M
2)
it states "Expiry month is typically quoted as JUN08, SEP09, DEC10,". However, YYYY-MM is expected.

Best Regards
Borgomi

The Quantext Python library is successfully generated by swig in Windows system,But when I ran the test file, I encountered the following error：
testing QuantExt 1.8.5.0
testConsistency (instruments.FxForwardTest)
Test consistency of fair price and NPV() ... oks
testSimpleInspectors (instruments.FxForwardTest)
Test FxForward simple inspectors. ... ok
testConsistency (instruments.DepositTest)
Test consistency of fair price and NPV() ... ok
testSimpleInspectors (instruments.DepositTest)
Test Deposit simple inspectors. ... ok
testConsistency (instruments.EquityForwardTest)
Test consistency of fair price and NPV() ... ok
testSimpleInspectors (instruments.EquityForwardTest)
Test EquityForward simple inspectors. ... ok
testConsistency (instruments.TenorBasisSwapTest)
Test consistency of fair price and NPV() ... ERROR
testSchedules (instruments.TenorBasisSwapTest)
Test TenorBasisSwap schedules. ... ERROR
testSimpleInspectors (instruments.TenorBasisSwapTest)
Test TenorBasisSwap simple inspectors. ... ERROR
testConsistency (instruments.SubPeriodsSwapTest)
Test consistency of fair price and NPV() ... ERROR
testSchedules (instruments.SubPeriodsSwapTest)
Test SubPeriodsSwap schedules. ... ERROR
testSimpleInspectors (instruments.SubPeriodsSwapTest)
Test SubPeriodsSwap simple inspectors. ... ERROR
testNPV (instruments.CommodityForwardTest)
Test NPV() ... ok
testSimpleInspectors (instruments.CommodityForwardTest)
Test CommodityForward simple inspectors. ... ok
testConsistency (instruments.PaymentTest)
Test consistency of fair price and NPV() ... ok
testSimpleInspectors (instruments.PaymentTest)
Test Payment simple inspectors. ... swig/python detected a memory leak of type 'QuantLib::ext::shared_ptr< SimpleCashFlow > *', no destructor found.
ERROR
testConsistency (instruments.CrossCurrencyFixFloatSwapTest)
Test consistency of fair price and NPV() ... ERROR
testSchedules (instruments.CrossCurrencyFixFloatSwapTest)
Test CrossCurrencyFixFloatSwap schedules. ... ERROR
testSimpleInspectors (instruments.CrossCurrencyFixFloatSwapTest)
Test CrossCurrencyFixFloatSwap simple inspectors. ... ERROR
testConsistency (instruments.AverageOISTest)
Test consistency of fair price and NPV() ... ERROR
testSimpleInspectors (instruments.AverageOISTest)
Test AverageOIS simple inspectors. ... ERROR
testSimpleInspectors (ratehelpers.AverageOISRateHelpersTest)
Test Avegare OIS Rate helpers simple inspector. ... ERROR
testSimpleInspectors (ratehelpers.CrossCcyBasisSwapHelperTest)
Test Cross Curency Basis Swap Helper simple inspector. ... ERROR
testSimpleInspectors (ratehelpers.TenorBasisSwapHelperTest)
Test Tenor Basis Swap Helper simple inspector. ... ERROR
testSimpleInspectors (ratehelpers.SubPeriodsSwapHelperTest)
Test SubPeriods Basis Swap Helper simple inspector. ... ERROR
testSimpleInspectors (ratehelpers.OIBSHelperTest)
Test OIBS Helper simple inspector. ... ERROR
testSimpleInspectors (ratehelpers.BasisTwoSwapHelperTest)
Test basis to swap Helper simple inspector. ... ERROR
testSimpleInspectors (ratehelpers.OICCBSHelperTest)
Test OICCBS simple inspector. ... ERROR
testSimpleInspectors (ratehelpers.ImmFraRateHelperTest)
Test ImmFraRateHelper simple inspector ... ERROR
testSimpleInspectors (ratehelpers.CrossCcyFixFloatSwapHelperTest)
Test crossccyfixfloat rate helper simple inspector ... ERROR
testConsistency (cashflow.FXLinkedCashFlowTest)
Test consistency of FX Linked Cash Flow fair price and NPV() ... ERROR
testSimpleInspectors (cashflow.FXLinkedCashFlowTest)
Test FX Linked Cash simple inspectors. ... ERROR
testConsistency (cashflow.FloatingRateFXLinkedNotionalCouponTest)
Test consistency of FX Linked Cash Flow fair price and NPV() ... ERROR
testSimpleInspectors (cashflow.FloatingRateFXLinkedNotionalCouponTest)
Test Floating Rate FX Linked Notional Coupon inspectors. ... ERROR
testConsistency (instruments.OvernightIndexedBasisSwapTest)
Test consistency of fair price and NPV() ... ERROR
testSchedules (instruments.OvernightIndexedBasisSwapTest)
Test OvernightIndexedBasisSwap schedules. ... ERROR
testSimpleInspectors (instruments.OvernightIndexedBasisSwapTest)
Test OvernightIndexedBasisSwap simple inspectors. ... ERROR
testConsistency (instruments.OvernightIndexedCrossCcyBasisSwapTest)
Test consistency of fair price and NPV() ... ERROR
testSchedules (instruments.OvernightIndexedCrossCcyBasisSwapTest)
Test OvernightIndexedCrossCcyBasisSwap schedules. ... ERROR
testSimpleInspectors (instruments.OvernightIndexedCrossCcyBasisSwapTest)
Test OvernightIndexedCrossCcyBasisSwap and engine simple inspectors. ... ERROR
testConsistency (instruments.CreditDefaultSwapTest)
Test consistency of fair price and NPV() ... ok
testSimpleInspectors (instruments.CreditDefaultSwapTest)
Test CreditDefaultSwap simple inspectors. ... ok
testConsistency (instruments.CDSOptionTest)
Test consistency of fair price and NPV() ... ERROR
testSimpleInspectors (instruments.CDSOptionTest)
Test CDSOptionTest simple inspectors. ... ERROR
testConsistency (instruments.CrossCcyBasisSwapTest)
Test consistency of fair price and NPV() ... ERROR
testSchedules (instruments.CrossCcyBasisSwapTest)
Test CrossCcyBasisSwap schedules. ... ERROR
testSimpleInspectors (instruments.CrossCcyBasisSwapTest)
Test CrossCcyBasisSwap simple inspectors. ... ERROR
testConsistency (instruments.DiscountingSwapEngineMultiCurveTest)
Test consistency of NPV() ... ok
testSimpleInspectors (termstructures.BlackVolatilityWithATMTest)
Test Black Volatility with ATM simple inspector. ... ERROR
testSimpleInspectors (termstructures.BlackVarianceSurfaceMoneynessSpotTest)
Test Black Variance Surface Moneyness Spot simple inspector. ... ok
testSimpleInspectors (termstructures.BlackVarianceSurfaceMoneynessForwardTest)
Test Black Variance Surface Moneyness Forward simple inspector. ... ok
testSimpleInspectors (termstructures.SwapConventionsTest)
Test SwapConventions simple inspectors. ... ERROR
testSimpleInspectors (termstructures.SwaptionVolCubeWithATMTest)
Test Swaption Vol Cube With ATM simple inspector. ... ERROR
testSimpleInspectors (termstructures.QLESwaptionVolCube2Test)
Test QLE Swaption Vol Cube 2 simple inspector. ... ERROR
testSimpleInspectors (termstructures.SwaptionVolatilityConstantSpreadTest)
Test Swaption Volatility Constant Spread simple inspector. ... ok
testSimpleInspectors (termstructures.FxBlackVannaVolgaVolatilitySurfaceTest)
Test Fx Black Vanna Volga Volatility Surface simple inspector. ... ok
...................

Ran 56 tests in 0.381s

FAILED (errors=40)

After a period of exploration, I found that the possible parameters are boost:: shared_ ptr can lead to errors,Could you please take look at it and help me solve this problem?

I've noticed that the DiscountFactor column in the cash-flow report (typically flows.csv) doesn't in specific cases display values that are expected. It appears to me that the populated discount factor in flows.csv is based on the DiscountingCurves curves defined in todaysmarket.csv rather than the true discount factor.

To see this, let's use Example 18:

1. Run the example with the standard settings. NPV of Trade id="Bond_Fixed" is 11415374. Summing all discounted cash-flows of this bond in flows.csv gives also 11415374.
2. Now go to portfolio.xml and for Trade id="Bond_Fixed" change ReferenceCurveId from EUR-EURIBOR-6M to e.g. BOND_YIELD_EUR. In npv.csv the NPV of this bond is 10894231 but in flows.csv adding up the discounted cash-flows still (incorrectly) gives 11415374.

Hence, the DiscountFactor used in flows.csv doesn't reflect the true discounting rate for NPV.

Can someone please check this?

Trying to build the latest release as directed in userguide.pdf.

Quantlib works, QuantExt works, it fails on OREData with this:

'QuantLib::PiecewiseDefaultCurveQuantExt::SurvivalProbability,QuantLib::LogLinear,QuantExt::IterativeBootstrap::instruments_': cannot access private member declared in class 'QuantLib::PiecewiseDefaultCurveQuantExt::SurvivalProbability,QuantLib::LogLinear,QuantExt::IterativeBootstrap' OREData c:\xxxx\engine-1.8.5.0\quantext\qle\termstructures\iterativebootstrap.hpp 134

Any suggestions?

Thanks in advance, Eduardo

Hi,
I'm trying to generate a C# class using xsd.exe (in .Net) and the xml schema found in /xsd/instruments.xsd. When running the command: "xsd /c /language:CS instruments.xsd" in the Developer Command Prompt I get the following error message:

Warning: Schema could not be validated. Class generation may fail or may produce incorrect results.
Error: Error generating classes for schema 'instruments'.

• The datatype 'date' is missing.

Has anyone been able to generate C# classes using the schemas in /Xsd/? Is xsd.exe meant to support these xsd-files or is there another tool I can use? I should also add I'm fairly new to this type of xml functionality.

Kind regards,
Mikael

Hi,
I've built ORE 1.8.5 on Ubuntu 20.04. No problems compiling and linking ORE. However, when running the test-suite for e.g. QuantExt, I end up with the following error:

./quantext-test-suite: symbol lookup error: /home/ore108050/build/QuantExt/qle/libQuantExt.so: undefined symbol: ZN8QuantLib21DiscountingSwapEngineC1ERKNS_6HandleINS_18YieldTermStructureEEEN5boost8optionalIbEENS_4DateES9

This function is indeed not defined in libQuantExt.so but in libQuantLib.so.

Has anyone experienced a similar problem on Linux?

Thanks in advance for any assistance.

Hello,
Not sure if this is the right place to post this (let me know if I should move it to Stackoverflow or elsewhere). I just installed the ORE and compiled everything successfully (Visual Studio 2013 (in x64) with QuantLib-1.9.2 and boost_1_63_0), the first examples work fine but Example_13 doesn't, I get the following errors in the logs:

ALERT    [2017-Apr-20 17:37:50.956801] (...tfolio\portfolio.cpp:114) : Error building trade (Swap_2) : Expected a leg of coupons of type CappedFlooredIborCoupon
ALERT    [2017-Apr-20 17:38:21.997905] (...tfolio\portfolio.cpp:114) : Error building trade (Swap_2) : did not find object EUR of type capfloor curve under configuration libor
ALERT    [2017-Apr-20 17:38:22.609966] (orea\app\oreapp.cpp:147)     : Error: InMemoryCube::InMemoryCube no ids specified

I didn't change anything before running the example, so is it normal?
Thanks!

Hello Everyone,

I followed the user_guide https://www.opensourcerisk.org/wp-content/uploads/2020/06/userguide.pdf
to build ORE on my machine and I am having an issue in the second stage after building Quantlib (a successfully build), I have provided a screenshot for the Property page and the error itself. I would appreciate any help I can get.

Hi all,
We run portfolios of caps and floors where there may be underlyings of different IBOR indices, e.g. we may have both EUR-3M and EUR-6M surfaces. Unfortunately, this is not supported by ORE.

The current setup has cap/floor volatilities indexed by their currencies in todaysmarket.xml, preventing the use of IBOR-specific naming. We suggest a change to this such that other names may be provided, as with i.e. IndexForwardingCurves or YieldCurves, and not just currency codes. This requires changes in the pricing engine builder for caps/floors and a few other places where the volatilities are looked up from the market.

To illustrate, this:
<CapFloorVolatility currency="EUR">CapFloorVolatility/EUR/EUR_CF_N_3M</CapFloorVolatility>
would become this:
<CapFloorVolatility name="EUR-3M">CapFloorVolatility/EUR/EUR_CF_N_3M</CapFloorVolatility>

I will update this issue if I ever find the time to implement this myself, should this be a desired feature. Maintaining backward compatibility is probably preferable if this is to be supported, so some care should be taken to ensure this.

Best regards,
Fredrik Gerdin Börjesson,
SEB

I am trying to build the ORE suite but am hitting a build error in solution OREAnalytics postprocess.cpp due to some undeclared identifiers. I could probably fix this for you, but am not sure this is the right thing to do. Can you have a look please? Thanks.

Anyhow on the testsuite the issues seem to be mostly around missing semicolons and then dategeneration.cpp has quite a few calendars that are not members of QuantLib::DateGeneration such as:

Error C2039 'ThirdThursday': is not a member of 'QuantLib::DateGeneration' QuantExtTestSuite c:\engine\quantext\test\dategeneration.cpp 83
Same thing for ThirdFriday, MondayAfterThirdFriday and TuesdayAfterThirdFriday, basically everything in that dategeneration.cpp

This leads me to believe the QuantLib dategenerationrule.hpp file (they did not include) that ORE is using is a modified version, as the mentioned rules are not inside the latest file. Does anyone have the file with these undeclared calendar rules??? You can see the latest file is missing all of these rules: https://github.com/lballabio/QuantLib/blob/master/ql/time/dategenerationrule.hpp

Hi,
The OREDataTestSuite project is missing a header filter and also the inclusion of related headers in Visual Studio. I believe this may be a plausible cause for some tests not failing correctly in VS's test suite after we had done some otherwise test-breaking changes on our fork. Missing header file includes also seem to be largely present in the OREAnalytics and QuantExt projects as well. The missing files and filter also complicate adding more tests, which I don't think is intended.

I'll strive to submit a fix for this in short, unless anyone else gets there first.

Hi,
I wanted to lift an issue on the user guide to collect and track documentation faults, inconsistencies, and other requested bits. Some of these I hope to fix and submit PRs for myself, while for others I believe it is in our best interest if I leave them to you, the maintainers.

Below, I'll create a checklist of apparent issues in the user guide:

• Equity curve config is missing documentation of the NoDividends type. This will let users avoid having to create a zero dividend quote to avoid errors.
• Equity curve config is missing documentation of the DividendInterpolation item and its default values.
• Equity curve config is missing documentation the Extrapolation tag.
• Chapter 11 Fixings History is missing specific coverage of allowed bond, commodity, and equity indices, other than what is mentioned briefly in other sections.
• Table 58 (Chap. 11: Zero inflation indices) is missing the values SECPI, DKCPI, and CACPI.
• Various places in the guide list the incomplete set of ZC inflation indices without a table reference. Perhaps this should be kept to one exclusive table (such as Table 58) for maintainability. Examples of these lists are found on p. 238, 239 x2, and 240.
• Some user guide listings fail on case-sensitivity that is applied by default in RapidXML. An example of this is in Listing 10, Section 7.2.2 Index Curves, that incorrectly uses "Name" rather than "name" in:
  <Index Name="EUR-EONIA">Yield/EUR/EUR1D</Index>
  This would then throw an error message that is rather obscure to debug. In this specific example, the parseIborIndex(str s) tried looking for an empty string as it had not been read previously.

I hope that lifting and adding these items will be helpful for others. Feel free to chime in on other points as well.

Hello

Could you please advice if this command is wrong, or if there is any outstanding issue with docker images?
Any reference guide please?

docker-compose -f docker-compose-boost.yml -f docker-compose-ore.yml -f docker-compose-quantlib.yml -f docker-compose-ore-app.yml up
Building env_quantlib
Step 1/8 : ARG boost_version=latest
Step 2/8 : FROM build_env_boost:${boost_version}
ERROR: Service 'env_quantlib' failed to build: pull access denied for build_env_boost, repository does not exist or may require 'docker login'

Hi!
While writing booleans to some XMLs we noticed that the usage of booleans in the XSDs is inconsistent in using either the ore_types.xsd defined type bool and the standard xs:boolean. The latter is stricter, allowing only true/1 or false/0 and not e.g. True/TRUE as is noted as allowed by Table 28 in the user guide (v6). This gets pretty messy in e.g. the CPILegData element that uses both of the boolean types for different tags. I suggest changing the XSDs to use bool across the board in order to simplify the XML writing and to avoid annoying errors.

Best,
Fredrik Gerdin Börjesson,
SEB

Is it possible to add a custom value for collateral balance at t = 0?

The only option I see now is through the fullInitialCollateralisation boolean which leads to either collateral = NPV or collateral = 0 . But this is way too limiting and it will lead to unrealistic time-zero exposures.

Hi ORE developers,

Many thanks for an amazing open source project and for the new release. I'd like to report a very minor issue with the manual, but I wasn't sure what the correct fix was, so I didn't create a PR. In Docs/UserGuide/userguide.tex:

CPI Swaps & Y & Y & N & Y \\
\hline
CPI Caps/Floors & Y & Y & N \\

CPI Caps/Floors is missing the last column I believe (e.g. CPI Caps/Floors & Y & Y & N & N \\ or CPI Caps/Floors & Y & Y & N & Y \\).

Cheers

Hi,
We have looked into FX forwards (NDFs) recently and believe that the npvCurrency_ variable is sometimes incorrect when a settlement currency is set and the payment date is different from the fixing date. This leads to the npv report writing the wrong currency code for the trade's npv and thus the base currency npv is incorrectly converted.

It seems this

Best,
Fredrik Gerdin Börjesson,
SEB

when will the ORE project support MSVC14.1? when I build ORE under MSVC 14.1, build error C2065 popped up, seems ORE is not supporting MSVC14.1 or C++ 14？