trendmanagement / Tmqr-framework-2

3 stars 0 forks source link

CL V1 futures and hedge legs not matching. #55

Open nikolas-joyce opened 6 years ago

nikolas-joyce commented 6 years ago

https://10.0.1.2:8888/notebooks/campaign_management/Campaign_Bidirectional_CL_ContFut_DSP%20for%20production_Sept5_w_enhancement.ipynb

looks like the futures and the V2 hedge legs are not matching after the transaction time.

image if things are working we should not have an open tail. image

futures have flattened but the hedge legs are unchanged.

spickering-git commented 6 years ago

@alexveden, We did a quick analysis by breaking out each of the alphas. Using the deltas as an indicator of in or out it looks like this problem is probably just on the last day.

alexveden commented 6 years ago

We did a quick analysis by breaking out each of the alphas. Using the deltas as an indicator of in or out it looks like this problem is just on the last day.

Are you sure that V2 Risk-reversal hedge alphas are calculated strictly after V1?

What will happen if you rebuild V2 alphas and indexes from scratch using run_indexes_forced_run.py script?

spickering-git commented 6 years ago

this is a notebook that will do the same thing, but it is just running each of the indexes and associated alphas

https://10.0.1.2:8889/notebooks/indexes/index_deployment_samples/Step%202%20-%20Load%20deployed%20index%20from%20the%20DB.ipynb

for a specific instrument

spickering-git commented 6 years ago

@alexveden There is still a problem. In analyzing 2 campaigns we can highlight some of the errors. I believe the

alpha.run() alpha.save() are NOT working correctly

CL campaign with deployed alphas probably on Sept 26 2017 the position is wrong https://10.0.1.2:8888/notebooks/campaign_management/CL_Bidirectional_W_Risk_Reversals%20V1%20test%20sept28_V2_PAYOFF1_TEST.ipynb name:'CL_Bidirectional_W_Risk_Reversals V1 test sept28' OLD_CL_CAMPAIGN.txt

CL campaign with re-deployed (this afternoon Sept 28 2017) alphas after re-deploying the alphas, the position makes sense. https://10.0.1.2:8888/notebooks/campaign_management/CL_Bidirectional_W_Risk_Reversals%20V1_V2_PAYOFF2_TEST.ipynb name:'CL_Bidirectional_W_Risk_Reversals V1' NEW_CL_CAMPAIGN.txt

now comparing the currently deployed alphas to the alphas deployed a few days ago we can see that when comparing old and new exposure and delta they are different. Also equity is different https://10.0.1.2:8889/notebooks/indexes/index_deployment_samples/Run%20indexes%20and%20alphas.ipynb

even if we do a alpha.run() and alpha.save(). The values do not change and line up.

the below image only shows the comparison of 2 of the alphas.

image

alexveden commented 6 years ago

now comparing the currently deployed alphas to the alphas deployed a few days ago we can see that when comparing old and new exposure and delta they are different. Also, equity is different

That is correct because alpha.run() just updates new position and exposure records and does not overwrite full history.

For example, you have run alpha yesterday, and now it has 2017-09-28 record for position and exposure series if you do alpha.run() later today it will calculate series but only add record 2017-09-29 but will keep the old record for 2017-09-28 disregarding its new value.

There is alpha position processing code: https://github.com/trendmanagement/Tmqr-framework-2/blob/master/tmqrstrategy/strategy_base.py#L624

spickering-git commented 6 years ago

Ok I see that alpha just gets appended

But when calling alpha.run again does the last value get overwritten

spickering-git commented 6 years ago

We should be able to call alpha.run and alpha.save again and update the very last value in the series. Don’t you think? If we happen to call alpha.run and alpha save for some unknown reason (manually or in error), we want to be able to call again to fix. We are supposed to be calling alpha.run and alpha.save at decision time correct?

alexveden commented 6 years ago

But when calling alpha.run again does the last value get overwritten

No, it does not

alexveden commented 6 years ago

@spickering-git yes, you are correct, this looks like an issue

spickering-git commented 6 years ago

Let’s say we call index.run and index.save alpha.run and alpha.save But it was too 7am and decision time is 10am Will something get written to alpha collection for the current day? Will any subsequent run and save of the alpha not get written to the alpha for the current day?

spickering-git commented 6 years ago

Because we have done exactly what I wrote in the last comment over that last few days. We were thinking that the alpha was updated. This is the source of our errors

alexveden commented 6 years ago

Will something get written to alpha collection for the current day?

yes

Will any subsequent run and save of the alpha not get written to the alpha for the current day?

no

alexveden commented 6 years ago

This is the source of our errors

looks so, I will fix that tomorrow