evaluationDate vs. referenceDate in yieldtermstructure

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

evaluationDate vs. referenceDate in yieldtermstructure

venk
Hello all -

Does anyone have a suggestion as to the best way to be able to maintain several yield curves with different reference dates within the same THREAD while using quantlib? Specifically, I maintain a "State" object that knows the evaluation date, and stores a table of yield curves based on market prices for the legs of a yield curve given a particular date. When that evaluation date changes, the object returns different yield curves bootstrapped off the market prices as of that date.

I would think that using the reference date argument for the yield curve constructor is sufficient, but I seem to be crashing when I try to do this and Settings::instance().evaluationDate() is not also set to the same reference date or later. It seems to be that the DepositRateHelper and SwapRateHelper use the evaluationDate, not the referenceDate, when bootstrapping, even though they are relative date rates? Am I misunderstanding?

Then, to further the porblem, if I set the evaluationDate (which is annoying to have to set and unset before I build my yieldcurve), it will work once, and when I try to change the date again, I get a crash in the standard libraries that mentions trying to access corrupt memory. I assume this is because of some combination of the Observable triggers for evaluationDate combined with the fact that I am not isolating every potential problem and locking/unlocking. I am not an expert at C++ and would like to operate without having to change the QuantLib codebase, but I am not sure I can do so.

Does anyone have thoughts on this? So far, the only solution I can come up with is the override instance to take an argument so I can key off of a State-dependent sessionID (as opposed to the current method of thread-specific sessionId, which can be done by defining the sessionId function with no arguments.

Thanks very much in advance for any thoughts you all might have.

Best,
-- V