Page 1 of 1
Stack overflow evaluating feeders
Posted: Sun Apr 24, 2016 9:57 pm
by 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
Re: Stack overflow evaluating feeders
Posted: Mon Apr 25, 2016 1:38 am
by BariAbdul
Re: Stack overflow evaluating feeders
Posted: Mon Apr 25, 2016 6:37 am
by 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
Re: Stack overflow evaluating feeders
Posted: Mon Apr 25, 2016 8:47 am
by Steve Rowe
No it needs to be fixed, the system can behave erratically, sometimes working and sometimes not.
Re: Stack overflow evaluating feeders
Posted: Mon Apr 25, 2016 2:25 pm
by 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
Steve Rowe wrote:No it needs to be fixed, the system can behave erratically, sometimes working and sometimes not.
Re: Stack overflow evaluating feeders
Posted: Mon Apr 25, 2016 2:37 pm
by lotsaram
vladino wrote: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?
Re: Stack overflow evaluating feeders
Posted: Mon Apr 25, 2016 2:41 pm
by 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’];
lotsaram wrote:vladino wrote: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?
Re: Stack overflow evaluating feeders
Posted: Mon Apr 25, 2016 2:54 pm
by tomok
vladino wrote: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.
Re: Stack overflow evaluating feeders
Posted: Mon Apr 25, 2016 3:09 pm
by 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.
Re: Stack overflow evaluating feeders
Posted: Mon Apr 25, 2016 3:58 pm
by 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
Re: Stack overflow evaluating feeders
Posted: Mon Apr 25, 2016 4:08 pm
by jim wood
tomok wrote: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.
Re: Stack overflow evaluating feeders
Posted: Mon Apr 25, 2016 4:25 pm
by tomok
jim wood wrote: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.
Re: Stack overflow evaluating feeders
Posted: Mon Apr 25, 2016 8:42 pm
by 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
Re: Stack overflow evaluating feeders
Posted: Mon Apr 25, 2016 9:15 pm
by 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
Re: Stack overflow evaluating feeders
Posted: Mon Apr 25, 2016 9:27 pm
by declanr
vladino wrote: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:
vladino wrote: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.
Re: Stack overflow evaluating feeders
Posted: Tue Apr 26, 2016 6:05 am
by 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