Stack overflow evaluating feeders

[vladino]

Hi gurus,
may I ask you - is this error message something I should be worried about? Or is it "just a message" but the data is calculated (and feeded) correctly and I can leave it unattended?

BR
Vladino

[BariAbdul]

There are couple of posts on this specific topic,Please go through it:
http://www-01.ibm.com/support/docview.w ... wg21457414
http://www.tm1forum.com/viewtopic.php?t=1170
http://www.tm1forum.com/viewtopic.php?t=11289

Also,Worth posting your actual rule.Thanks

[vladino]

Hello,
I know what the error message means. I just want to be sure whether do I need to solve it to have correct numbers or the numbers displayed in views are correct even if there's this error.

BR
Vladino

There are couple of posts on this specific topic,Please go through it:
http://www-01.ibm.com/support/docview.w ... wg21457414
http://www.tm1forum.com/viewtopic.php?t=1170
http://www.tm1forum.com/viewtopic.php?t=11289

Also,Worth posting your actual rule.Thanks

[Steve Rowe]

No it needs to be fixed, the system can behave erratically, sometimes working and sometimes not.

[vladino]

I thought so...

I have heard about "skip ahead feeders" but I can't find anything about it. It should resolve the issue. Can anybody describe this method please?

BR
Vladino

No it needs to be fixed, the system can behave erratically, sometimes working and sometimes not.

[lotsaram]

I thought so...

I have heard about "skip ahead feeders" but I can't find anything about it. It should resolve the issue. Can anybody describe this method please?

BR
Vladino

I haven't heard of "skip ahead feeders". Could you describe what you mean?

[vladino]

http://www-01.ibm.com/support/docview.w ... wg21457414

To help resolve the problem, engineering has suggested using a method called "skip ahead feeders". Here is an example:

A feeder written like this may (depending on the size of the model) eventually blow the stack. The reason is that the feeder comes from a single fed intersect:
[‘jan’,’2006’]=>[‘feb’,’2006’];
[‘feb’,’2006’]=>[‘mar’,’2006’];
[‘mar’,’2006’]=>[‘apr’,’2006’];
…
[‘nov’,’2006’]=>[‘dec’,’2006’];
[‘dec’,’2006’]=>[‘jan’,’2007’];
[‘jan’,’2007’]=>[‘feb’,’2007’];

To implement skip ahead feeders (which will break the stack into smaller chunks and alleviate the problem), do the following:

[‘jan’,’2006’]=> [‘jan’,’2007’], [‘feb’,’2006’];
[‘feb’,’2006’]=>[‘mar’,’2006’];
[‘mar’,’2006’]=>[‘apr’,’2006’];


[‘nov’,’2006’]=>[‘dec’,’2006’];
[‘dec’,’2006’]=>[‘jan’,’2007’];
[‘jan’,’2007’]=> [‘jan’,’2008’], [‘feb’,’2007’];

I thought so...

I have heard about "skip ahead feeders" but I can't find anything about it. It should resolve the issue. Can anybody describe this method please?

BR
Vladino

I haven't heard of "skip ahead feeders". Could you describe what you mean?

[tomok]

A feeder written like this may (depending on the size of the model) eventually blow the stack. The reason is that the feeder comes from a single fed intersect:
[‘jan’,’2006’]=>[‘feb’,’2006’];
[‘feb’,’2006’]=>[‘mar’,’2006’];
[‘mar’,’2006’]=>[‘apr’,’2006’];
…
[‘nov’,’2006’]=>[‘dec’,’2006’];
[‘dec’,’2006’]=>[‘jan’,’2007’];
[‘jan’,’2007’]=>[‘feb’,’2007’];

Why would you want to implement feeders in this way? I can only think of few instances where something like this would be necessary. I've been using TM1 for 20 some odd years and I can only think of a couple times where I needed to feed like this.

[declanr]

The "skip ahead" method as IBM coin it is one way of dealing with stack overflows on balance sheet style calculations where you have a brought forward balance and closing balance; the point they miss is that to blow a stack you need to hit give or take 250 (from memory) feeders. In most financial planning models you are only likely to go down to a month granularity so unless you are doing a 20 odd year plan by month its actually unlikely to be an issue.
Where it is most commonly seen is Cashflows where your balance sheet feeds your cash flow and your cashflow feeds back in to the balance sheet and so on.

Long story short there are a million and one reasons that you could have a stack overflow and each of them probably has a different way of "fixing" it - if you could provide your rule statements and the current feeders statements then you might get a good answer.

[Steve Rowe]

Typical situation is as follows, which I have hit the two times I have had to do daily cash flow models

[Closing Balance] => DB ( 'Cube' , 'Opening Balance' , Attrs ('Day', !Day , 'Next'));

This will break the stack since Day 1 will feed every day in front of it.

My solution (and others, don't think it was mine originally, it has been put up here a few times).

Every six months leave the Next attribute blank so the feeder fails and write a "manual" feeder to bridge the gap. This way no single cell every feeds more than 180 days in the future. (I blank out the 1st June and 1st Jan as it is easier to keep track of than a 249 day cycle).

[Closing Balance] => DB ( 'Cube' , 'Opening Balance' , Attrs ('Day', !Day , 'Next'));
['Day 180' , Closing Balance] => ['Day 181' , 'Opening Balance' ];
['Day 360' , Closing Balance] => ['Day 361' , 'Opening Balance' ];

In my situation I don't think the IBM solution would help and may just be wrong or for a different use case.

[‘jan’,’2006’]=>[‘feb’,’2006’];
[‘feb’,’2006’]=>[‘mar’,’2006’];
[‘mar’,’2006’]=>[‘apr’,’2006’];
…
[‘nov’,’2006’]=>[‘dec’,’2006’];
[‘dec’,’2006’]=>[‘jan’,’2007’];
[‘jan’,’2007’]=>[‘feb’,’2007’];

Is broadly longhand for (ignoring differing period types).

[Closing Balance] => DB ( 'Cube' , 'Opening Balance' , Attrs ('Day', !Day , 'Next'));

Changing it to this

[‘jan’,’2006’]=> [‘jan’,’2007’], [‘feb’,’2006’];
[‘feb’,’2006’]=>[‘mar’,’2006’];
[‘mar’,’2006’]=>[‘apr’,’2006’];


[‘nov’,’2006’]=>[‘dec’,’2006’];
[‘dec’,’2006’]=>[‘jan’,’2007’];
[‘jan’,’2007’]=> [‘jan’,’2008’], [‘feb’,’2007’];

Would still mean that Jan 2006 triggers a feeder in every period in front of it eventually leading to a stack overflow.

HTH

[jim wood]

I've been using TM1 for 20 some odd years

Quite a few of us on here have been doing it for that long as well and we continue to learn. We don't know everything. Anybody who thinks so is only fooling themselves. We should always be open to new methods, as over 20 years we can develop our own style and our own way of doing things that not be optimal.

[tomok]

Quite a few of us on here have been doing it for that long as well and we continue to learn. We don't know everything. Anybody who thinks so is only fooling themselves. We should always be open to new methods, as over 20 years we can develop our own style and our own way of doing things that not be optimal.

You completely missed the point. The point is that in 20 years of use, I've hardly ever come across the need to daisy-chain feeders like this. So, instead of just responding to the stack issue, I questioned the need for the daisy-chained feeders in the first place.

I am always open to new ideas and methods. However, daisy-chaining feeders is neither.

[vladino]

Hi guys,
first of all thanks a lot for the discussion.

Are you trying to tell me that if I have 20 members on year dim (I have separate year and period dims) and I'm calculating beginning and ending balances I will always blow the stack?

And to solve the issue I need to feed let's say Jan ending balance with Jan beginning balance from previous year? So really like the example from IBM?

BR
Vladino

[Wim Gielis]

Vladino,

With that many years, and 12 periods a year, yes.
But most likely you will benefit from the approaches discussed.

Next to that, there will be benefits from having hard-coded values in your cube rather than rules-calculated cells that are fed.
Meaning that you should export your data, turn off rules and feeders, and import them again.

Also, add years in the dimension as they come, and do not add many years in the future. What's the purpose of that ?
Or do you have let's say a history of 16/17 years in the balance sheet ?

Wim

[declanr]

Are you trying to tell me that if I have 20 members on year dim (I have separate year and period dims) and I'm calculating beginning and ending balances I will always blow the stack?

"ALWAYS" is a strong word. Essentially it depends on your feeder and your values which is why I asked for the rule and feeder statements you have.

For example; lets assume your rule is roughly:

Code: Select all

['Opening Bal']=N:
DB ( 'Cube', If ( !Month @= 'Jan', AttrS ( 'Year', !Year, 'Prior' ), !Year), AttrS ( 'Month', !Month, 'Prior' ), 'Closing Bal' );

Where "Closing Bal" is a consolidation of "Opening Bal" and a cell you can populate called "Movement"

The feeders roughly as below:

Code: Select all

[{'Opening Bal','Movement'}]=>
DB ( 'Cube', If ( !Month @= 'Dec', AttrS ( 'Year', !Year, 'Next' ), !Year), AttrS ( 'Month', !Month, 'Next' ), 'Opening Bal' );

In this case if you have a Value in "Jan" of "Year 1" then the feeder would shoot all the way through to "Dec" in "Year 25" which is 300 feeders in the stack.
BUT if you didn't have a value until the "Movement" cell in "Jan" of "Year 10" then things would be different as that is where the feeder starts.


Now - that above example assumes that you only go forward in a direct line but there is the very possible example that there is a cycle of feeders within the Month itself; for example if it is your cash account - the closing balance could feed the interest calculation in the next month which then comes back in to feed the Movement; in that example your feeder would go "Closing Jan" => "Interest Feb" => "Movement Feb" => "Closing Feb" and all of a sudden the time duration which the stack can last is significantly reduced.


BUT:

And to solve the issue I need to feed let's say Jan ending balance with Jan beginning balance from previous year? So really like the example from IBM?

Essentially, yes. With the caveats above that it does depend on your specific scenario as to whether the resolution is quite as simple as IBMs example.
I do understand IBM's example being quite basic as it's not the easiest thing to explain with mocked up data.

[vladino]

Hello guys,
it seems that "skip ahead" method in combination with removing some year members has solved the issue.

I would like to thank you all for helping me!

BR
Vladino