Dumping log files / yield curve failures

What’s the easiest way of dumping out a log file from the example-simulated server? The items that are loading in a yield curve are issuing an evaluation error, and I’d like to debug that to see why that is happening. Any hints?

Pass in the command line option "-Dlogback.configurationFile=/path/to/logback/logback.xml ".

See any logback.xml file for the correct format - http://logback.qos.ch/manual/configuration.html

Thanks
Also I found the an alternative solution. Use eclipse :slight_smile: :slight_smile:

The stack trace is below.

19:30:30.117 [CalcNode-1] ERROR c.o.e.calcnode.SimpleCalculationNode - Invocation error: Ibor index with id Bundle[Reference Rate Simple Name~BBSW_AUD_P3M] is null
19:30:30.118 [CalcNode-1] WARN c.o.e.calcnode.SimpleCalculationNode - Caught exception
com.opengamma.OpenGammaRuntimeException: Ibor index with id Bundle[Reference Rate Simple Name~BBSW_AUD_P3M] is null
at com.opengamma.financial.analytics.conversion.FixedIncomeConverterDataProvider.getIndexIborIdBundle(FixedIncomeConverterDataProvider.java:1486) ~[classes/:na]
at com.opengamma.financial.analytics.conversion.FixedIncomeConverterDataProvider.getIndexIdForSwap(FixedIncomeConverterDataProvider.java:1462) ~[classes/:na]
at com.opengamma.financial.analytics.conversion.FixedIncomeConverterDataProvider.getIndexTimeSeriesRequirement(FixedIncomeConverterDataProvider.java:1209) ~[classes/:na]
at com.opengamma.financial.analytics.conversion.FixedIncomeConverterDataProvider.access$5(FixedIncomeConverterDataProvider.java:1206) ~[classes/:na]
at com.opengamma.financial.analytics.conversion.FixedIncomeConverterDataProvider$12.getTimeSeriesRequirements(FixedIncomeConverterDataProvider.java:801) ~[classes/:na]
at com.opengamma.financial.analytics.conversion.FixedIncomeConverterDataProvider$12.getTimeSeriesRequirements(FixedIncomeConverterDataProvider.java:1) ~[classes/:na]
at com.opengamma.financial.analytics.conversion.FixedIncomeConverterDataProvider.getConversionTimeSeriesRequirements(FixedIncomeConverterDataProvider.java:227) ~[classes/:na]
at com.opengamma.financial.analytics.timeseries.YieldCurveInstrumentConversionHistoricalTimeSeriesFunction.execute(YieldCurveInstrumentConversionHistoricalTimeSeriesFunction.java:121) ~[classes/:na]
at com.opengamma.engine.calcnode.SimpleCalculationNode.invoke(SimpleCalculationNode.java:813) [classes/:na]
at com.opengamma.engine.calcnode.SimpleCalculationNode.executeJobItems(SimpleCalculationNode.java:467) [classes/:na]
at com.opengamma.engine.calcnode.SimpleCalculationNode.executeJobItems(SimpleCalculationNode.java:578) [classes/:na]
at com.opengamma.engine.calcnode.SimpleCalculationNode.executeJob(SimpleCalculationNode.java:360) [classes/:na]
at com.opengamma.engine.calcnode.SimpleCalculationNodeInvocationContainer.executeJobs(SimpleCalculationNodeInvocationContainer.java:595) [classes/:na]
at com.opengamma.engine.calcnode.SimpleCalculationNodeInvocationContainer.access$0(SimpleCalculationNodeInvocationContainer.java:583) [classes/:na]
at com.opengamma.engine.calcnode.SimpleCalculationNodeInvocationContainer$1.run(SimpleCalculationNodeInvocationContainer.java:403) [classes/:na]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_45]
at java.lang.Thread.run(Thread.java:744) [na:1.7.0_45]
19:30:30.612 [CalcNode-1] ERROR c.o.e.calcnode.SimpleCalculationNode - Invocation error: Ibor index with id Bundle[Reference Rate Simple Name~BBSW_AUD_P3M] is null
19:30:30.613 [CalcNode-1] WARN c.o.e.calcnode.SimpleCalculationNode - Caught exception
com.opengamma.OpenGammaRuntimeException: Ibor index with id Bundle[Reference Rate Simple Name~BBSW_AUD_P3M] is null
at com.opengamma.financial.analytics.conversion.FixedIncomeConverterDataProvider.getIndexIborIdBundle(FixedIncomeConverterDataProvider.java:1486) ~[classes/:na]
at com.opengamma.financial.analytics.conversion.FixedIncomeConverterDataProvider.getIndexIdForSwap(FixedIncomeConverterDataProvider.java:1462) ~[classes/:na]
at com.opengamma.financial.analytics.conversion.FixedIncomeConverterDataProvider.getIndexTimeSeriesRequirement(FixedIncomeConverterDataProvider.java:1209) ~[classes/:na]
at com.opengamma.financial.analytics.conversion.FixedIncomeConverterDataProvider.access$5(FixedIncomeConverterDataProvider.java:1206) ~[classes/:na]
at com.opengamma.financial.analytics.conversion.FixedIncomeConverterDataProvider$12.getTimeSeriesRequirements(FixedIncomeConverterDataProvider.java:801) ~[classes/:na]
at com.opengamma.financial.analytics.conversion.FixedIncomeConverterDataProvider$12.getTimeSeriesRequirements(FixedIncomeConverterDataProvider.java:1) ~[classes/:na]
at com.opengamma.financial.analytics.conversion.FixedIncomeConverterDataProvider.getConversionTimeSeriesRequirements(FixedIncomeConverterDataProvider.java:227) ~[classes/:na]
at com.opengamma.financial.analytics.timeseries.YieldCurveInstrumentConversionHistoricalTimeSeriesFunction.execute(YieldCurveInstrumentConversionHistoricalTimeSeriesFunction.java:121) ~[classes/:na]
at com.opengamma.engine.calcnode.SimpleCalculationNode.invoke(SimpleCalculationNode.java:813) [classes/:na]
at com.opengamma.engine.calcnode.SimpleCalculationNode.executeJobItems(SimpleCalculationNode.java:467) [classes/:na]
at com.opengamma.engine.calcnode.SimpleCalculationNode.executeJobItems(SimpleCalculationNode.java:578) [classes/:na]
at com.opengamma.engine.calcnode.SimpleCalculationNode.executeJob(SimpleCalculationNode.java:360) [classes/:na]
at com.opengamma.engine.calcnode.SimpleCalculationNodeInvocationContainer.executeJobs(SimpleCalculationNodeInvocationContainer.java:595) [classes/:na]
at com.opengamma.engine.calcnode.SimpleCalculationNodeInvocationContainer.access$0(SimpleCalculationNodeInvocationContainer.java:583) [classes/:na]
at com.opengamma.engine.calcnode.SimpleCalculationNodeInvocationContainer$1.run(SimpleCalculationNodeInvocationContainer.java:403) [classes/:na]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_45]
at java.lang.Thread.run(Thread.java:744) [na:1.7.0_45]

Just some more info on the failure… Would like some feedback to make sure that I’m not going down the wrong path, but is seems that there is a problem in

AbstractEHCachingSourceWithExternalBundle.java in the method “getSingle”

The problem seems to be that _eidToUidCache is returning an empty list. Because this is not null. the next set of code returns it as null rather than caching the item.

There have been major changes to curves, with a new curve system. Separately, there have been major changes to conventions and their interactions with securities.

Although there may be issues in AbstractEHCachingSourceWithExternalBundle, I would suspect that the issue is deeper than that, and probably in the area on conventions.

http://jira.opengamma.com/browse/PLAT-6267

I think it’s both deeper and simpler. It looks like the problem is that the sample server is using old naming conventions that don’t work with the new securities model.

Also, is there documentation on the naming conventions and securities systems? If there isn’t I’ll try to put together some notes as I go along.

Originally, the security referred directly to the convention. Now it refers to the index, which refers to the convention. So, yes its partly a naming issue (which would benefit from some notes!)

There are some notes on setup here although this is now legacy…
http://developers.opengamma.com/docs/user-guides/curves-currencies

Just a sanity check before I start coding to make sure that I’m coding the right thing…

The problem is that ConventionBundle is obsolete so the code that generates the conventions in com/opengamma/examples/simulated/convention

The new and better way is to put the IborIndex into the list of Securities.

So the fix is to allow the example server to read in IborIndexes from a file (if that’s not there already), so that the conventions are soft coded rather than hard coded in java.

Right?

FYI, I just put in a proof of concept fix that hard codes IborIndex additions for the australia conventions.

I’m looking into a more general/less ugly way of doing this. One thing that occurs to me is that the synthetic convention module in the example server seems to be really unnecessary. It’s possible to put in securities for the indices that are being used, and then have them use the conventions that are in the main code.