Rules stack limit

[Carolyn]

I am converting a TM1 Vers 6 database to TM1 Version 9. I am "almost" done.

I found a new error on the Vers 6 side, which remains the production version until the conversion is complete. We have rules that calculate Inception To Date. They are recursive, that is , Month 1 is added to Month 2, etc.

This month, which is #229 in the recursive series, I got the error about "circular references in the rules". I looked that up and found that it is probably due to the recursive rules going over the maximum stacking limit. OK...

Over on the Vers 9 side, with an identical query, there are no errors, even 10 years in the future.

My burning question: Can I assume that Vers 6 has a stack level limit somewhere in the neighborhood of 229, and that Vers 9 has a larger stack level limit? Can anyone tell me approximately what that limit is?
I inherited the Vers 6 database and have kept it running while I get Vers 9 ready. I don't really want to make any substantive changes in Vers 6, as it will be dumped in the near future.

[qml]

Before someone addresses your actual question, can I just state the obvious that using rules to add numbers together is the absolutely wrong way to do it. When you rebuild the model, better use consolidations for this, even if you need to update them periodically.

[Carolyn]

You are preaching to the choir. I just need to keep the old model working for a while longer, and don't want to waste time on it unnecessarily.

Learning the new stack limit, if there is one, would be of great help for many reasons.

[paulsimon]

Carolyn

I can't remember what the stack limit was in version 6, but something like 255 would not be a surprise.

As a way to keep Version 6 running a little longer I would suggest using some of the intermediate consolidations so it doesn't have to add up numbers from the first month each time. I am assuming that your current rule says something like

[Cumulative] = N: This Month + Cumulative Last Month

Assuming that the first year is eg 2009, change this to

[Cumulative,2009-12] = N: [2009] ;

[Cumulative,2010-12] = N: [2009] + [2010] ;

[Cumulative] = N: This Month + Cumulative Last Month

That will just put a few break points in to keep it going a bit longer.

However, in version 9 I would definitely go with qml's suggestion of using consolidation. Consolidation is around 100 times faster than the same rule based calculation and you don't need to feed it so your cube will be smaller.

You need something like

2011-09 Cumu
2011-09
2011-08 Cumu
2011-08
2011-07 Cumu
...

This is easy to create using TI or a Dimension Spreadsheet

Regards

Paul Simon

[Carolyn]

I agree, consolidations are the way to go. I have to deal with the plethora of user spreadsheets set up for the current system.

No one said it would be easy...

[Alan Kirk]

Carolyn

I can't remember what the stack limit was in version 6, but something like 255 would not be a surprise.

Interestingly, on page 11-7 of the Perspectives 2.6 manual (which would relate to server 6; yup, I have 'em back that far, which suddenly if transiently makes me feel old) it is claimed that:

A rule statement can refer to a cell in a cube that is defined by another rule statement, and so on. TM1 stacks these rule statements until it can obtain a final value, and then works back to return a result. The number of levels of stacking that can be accommodated is limited by available memory.

If a circular reference occurs within a rules stack, or the maximum level of stacking is exceeded, TM1 returns the error message:
Error Evaluating Rule: Possible Circular Reference

Of course, what was theoretical in version 6 and what was real world practical... I'm not claiming that the two coincide exactly.

[Steve Rowe]

I still see the same stack error coming in v 951 so I would not rely on it not existing you may just not be triggering it. I don't believe there has been any change since v6 on this.

It tends to be the feeders forward rather than the rules backwards that fail though so maybe they upped the rule stack but not the feeder one.
I deal with the issue in a manner similar to Paul's suggestion with breakpoints in the rules and feeders.

My problem is a daily cash flow, where todays closing balance = tomorrows opening balance, time and balance being different dimensions. I don't think there is away to do this type of calc using a consolidation but I would love to hear of one. It is a long term pain for me.

Cheers,

Steve

[Carolyn]

I did what everyone suggested and changed the system to a bunch of consolidations, in place of recursive rules.

The system runs much faster, it's simpler, more elegant and works great.

Thanks!!!