CL (Light Sweet Crude) patch

[Marcus Williford]

For those who might be interested, I wrote support for the NYMEX Future of CL (Light Sweet Crude).  The NYMEX security expires 3 business days prior to the 25th, and if the 25th falls on a weekend, add more days.  So it follows these rules.

It has one setting that is important, the VOLUME_CROSSOVER_BEFORE_EXP.  This controls when the system will switch to the next months contract.  Currently, for my test, this is set to 8 business days.  I think this might be slightly too early to switch over, I'll need to collect some data before I'll know for sure.

I have included the patch, as well as unit test in hg diff format.

hg import <patchname>

I am sending this out for review, and I'm collecting CL.

I forget, was there a list of other securities people wanted?  Let me know what the priorities are.

NOTE:

While writing this, I noticed something about contract switchover (in general) in jbooktrader.  It only appears to happen when the strategy is created in the constructor.  So, if my theory is correct, we may have a bug if someone kept their jbooktrader open for a long long time, across the futures crossover date.  I have not confirmed this, but to be safe I'd recommend restarting jbook every day on securities that have expiration close in.  I have opened issue #28 in our bug system to track this.

Marcus

[Eugene Kononov]

While writing this, I noticed something about contract switchover (in general) in jbooktrader.  It only appears to happen when the strategy is created in the constructor.  So, if my theory is correct, we may have a bug if someone kept their jbooktrader open for a long long time, across the futures crossover date.  I have not confirmed this, but to be safe I'd recommend restarting jbook every day on securities that have expiration close in. 

That's correct, Marcus. The contract will not rollover until JBT is restarted. It's not an issue for me, as I restart every day, but some people run JBT continuously weeks and months at a time. So this would be good to fix.

[Marcus Williford]

Ok, it is in our bug db.  In the mean time, the workaround as you suggested is very very simple for people, just restart when you are near the volume crossover days.  I was more worried if anyone traded something like CL which expires each month, because not everyone has a oil pipeline to Crushing to take actual delivery.

Speaking of running this for days.  Is it me, or does TWS force everyone to physically restart it each day.  Is there a way to work around this?

On Wed, Jan 9, 2013 at 2:08 PM, Eugene Kononov <eugene....@gmail.com> wrote:

While writing this, I noticed something about contract switchover (in general) in jbooktrader.  It only appears to happen when the strategy is created in the constructor.  So, if my theory is correct, we may have a bug if someone kept their jbooktrader open for a long long time, across the futures crossover date.  I have not confirmed this, but to be safe I'd recommend restarting jbook every day on securities that have expiration close in. 

That's correct, Marcus. The contract will not rollover until JBT is restarted. It's not an issue for me, as I restart every day, but some people run JBT continuously weeks and months at a time. So this would be good to fix.

--
You received this message because you are subscribed to the Google Groups "JBookTrader" group.
To post to this group, send email to jbook...@googlegroups.com.
To unsubscribe from this group, send email to jbooktrader...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jbooktrader?hl=en.

[Judson Wilson]

JBT is setup to close all positions at the end of the day. So
hopefully this will not happen. This adds more reason to restart JBT
every day (you SHOULD be monitoring whats going on if you are live
trading!)

As for restarting JBT, you need to look into this special program:
http://sourceforge.net/projects/ibcontroller
I think that is the right one. It's a java program which launches TWS,
but intercepts window messages and automatically changes the
auto-logout time.

[Eugene Kononov]

As for restarting JBT, you need to look into this special program:
http://sourceforge.net/projects/ibcontroller
I think that is the right one. It's a java program which launches TWS,
but intercepts window messages and automatically changes the
auto-logout time.

My preference is to use IBGateway instead of TWS. JBT will work exactly the same way with either one. The difference is that IBGateway is lightweight, and can run continuously, without restarts, weeks months at a time.

[nonlinear]

On Wednesday, January 9, 2013 4:29:28 PM UTC-5, mwsailing wrote:

For those who might be interested, I wrote support for the NYMEX Future of CL (Light Sweet Crude).  The NYMEX security expires 3 business days prior to the 25th, and if the 25th falls on a weekend, add more days.  So it follows these rules.Marcus

Marcus, I assigned a "committer" role to you. Feel free to add/commit your code to trunk. I'll review it from there. Thanks for the contribution. 

[Marcus Williford]

Commited the change to my CL feature branch already, so I just merged it to default branch and pushed.

Please review, and report back any concerns.  Note, the setting for when to switch over the contracts is currently 8 business days, which I pulled out of thin air.  So, some follow-up will be done to adjust this to something realistic.

Marcus

--

You received this message because you are subscribed to the Google Groups "JBookTrader" group.

To view this discussion on the web visit https://groups.google.com/d/msg/jbooktrader/-/nfUJGJHA7esJ.

[Eugene Kononov]

Thanks, Marcus. I glanced quickly, it looks solid. I'll review more formally later. Are there any other futures contracts which expire on the same schedule as CL?

[Marcus Williford]

I just looked, I think the only other security that follows this 3 business days before the 25th (or prior business day to the 25th) logic:

• MB - Gulf Coast Sour Crude Oil  

So probably I need to rename my utility classname, sorry I didn't research this before picking the name.

However, I wrote it in such a way, that I can make a base class and reuse it for securities that follow rules like "x business days prior to xyz", etc, etc.  So, if you give me another security you like, I'll write unit tests and refactor in such a way. 

Also, during development, I read something about how IB changes the "label" of the security on expiration day.  I think we are ok, because by the time we get to expiration day, we are already using the next security.  I just point out that IB does something screwy with the NYMEX ones, due to the nominal security name "Feburary", actually expires in January.  I don't think this impacts our logic, but I want to watch the system closely on expiration day to make sure this behavior doesn't translate to anything evil.

Marcus

[Eugene Kononov]

It has one setting that is important, the VOLUME_CROSSOVER_BEFORE_EXP.  This controls when the system will switch to the next months contract.  Currently, for my test, this is set to 8 business days.  I think this might be slightly too early to switch over, I'll need to collect some data before I'll know for sure.

Marcus, I did some digging, and came up with this:

"Rollover will be the morning of the 4th business day prior to the 25th calendar day of the month preceding the delivery month. If the 25th calendar day of the month is a non-business day, the rollover will be the morning of the 4th business day prior to the business day preceding the 25th calendar day" 

As I am planning to add CL to my portfolio, it would be good to know definitively the "volume rollover" rules. This month, according to the rule above, the volume rollover is Monday, January 21, so I'll watch it for confirmation.

[Marcus Williford]

Eugene,

I read that Expiration day is 3rd business days following the same rules, so my code correctly calculates the expire day so far.  Wow, 1-day prior to expiration is rollover, that cuts it close.  This means we should set the volume crossover value to 1 for VOLUME_CROSSOVER_BEFORE_EXP = 1.  

I did this, and the code crossed it over 1-day off, due to a timezone/comparison bug.  So, I made a minor fix and added a unit test to cover your request above, making sure that Janurary 21st trades the March Contract (which expires on Feb 20th).

You can pull to get the changes and fix.

From the unit tests -----------  You can see that Jan 21st grabst he 201303 security now, which is the next months contract, and if the 20th was a trading day it would use the 201302 contract, which expires on Jan 22nd.

         volXDay.set(2013, Calendar.JANUARY, 21, 10,0,0);

        janVolXover = CLNYMEXMostLiquid.getMostLiquidExpiry(volXDay);  // actually this is called the Feb delivery future, exprires in Jan though

        assertEquals("201303", janVolXover);   // this would fetch the March contract, which expires Feb 20th

        volXDay.set(2013, Calendar.JANUARY, 20, 10, 0, 0);

        String notXoverYet = CLNYMEXMostLiquid.getMostLiquidExpiry(volXDay);

        assertEquals("201302", notXoverYet);

[Borg Alexander]

Probably not everything needs to be automated. JBookTrader provides the possibility of rolling over manually by means of an overload of makeFutureContract. When I start TWS and have the CL future on my worksheet, TWS pops up a screen when it is time to roll CL. Whenever that happens I will change the expiration date manually. To do this, just replace

Contract contract = ContractFactory.makeFutureContract("CL", "NYMEX");

by

Contract contract = ContractFactory.makeFutureContract("CL", "NYMEX", "201302");

and adjust the third parameter accordingly.

[Eugene Kononov]

Contract contract = ContractFactory.makeFutureContract("CL", "NYMEX");

by

Contract contract = ContractFactory.makeFutureContract("CL", "NYMEX", "201302");

It is indeed possible to specify the contract expiration directly. What Marcus is attempting to accomplish is to model the CL contract after the ES contract, so that the expiration never needs to be specified. Instead, it's calculated at run time based on the current date and the contract rollover rules, specifically the contract volume rollover rules.