How do feeders actually work?

zerofeng111

I started an Olapedia article on TM1 Feeders, explaining them as I understand them and promptly got corrected by another user.

I said

"SkipCheck;" indicates that the rules should only calculate cells with a feeder flag.

He said

Not quite correct
"Skipcheck" turns the Sparse Cosnolidation Algorythm back on which by default gets turned of once there is a rule on a cube. The rule will always calculate but the result will not necessarily (unless fed) consolidated. Skipcheck doesn't mean 'don't calculate unless fed'.

I was aware of the term sparse consolidation algorithm, but ignored it for simplicity's sake. I was however surprised by the assertion that rules always calculate. To my mind, the calculation is what actually takes the time, so if all the zero cells are still being calculated and then ignored at consolidation, it will still take a long time.

Surely an unfed cell will not be calculated AND it will also be ignored by the consolidation?

Martin

itoto

It's a pretty fine distinction.

An _N_ level rule based cell will always get calculated if you ask for the result in an un-zero suppressed view, this is ture irrespective of skipcheck and feeder status.  This holds even if the cell is dependant on other unfed _N_ level values, but not if it is dependant on C level values that are ruled/skipchecked and unfed.

The feeder flags indicate to the system that a cell might have a value if you are using zero-suppression at the N level, or if the system is calculating a consoldated value.

An unfed cell will not be displayed (or calculated?) if looking at the cube zero suppressed, it will always be ignored by the consolidation.

I think the above is true, whish is mostly the same as what you said.

It does get confusing though as even in a zero suppressed view you can get un fed values displaying.

Say you have a cube viewer laid like with 9 N level values like this and zero suppression on.

A B C
D E F
G H I

Say value E is unfed, it will still display the correct result in the cube viewer since you are forcing the system to return the value as it is required to complete the layout of the cube viewer.  If you were to reorientate the cube viewer so all the values appeared as a column then value E will not display since it is not fed and the cell is not required to complete the display.

This is probably confused the issue even more  

mmkjzz

Steve Rowe wrote: An unfed cell will not be displayed (or calculated?) if looking at the cube zero suppressed, it will always be ignored by the consolidation.

Your question in the parenthesis is precisely what I'm getting at.  If an unfed cell is not displayed, is it actually calculated?  The more I think about it, the more I think it makes no sense for it to be calculated.  If it was calculated and all that skipcheck did was prevent it being consolidated, that would mean only a minimal time saving as consolidations are pretty straight forward once the number is there, whereas calculations to arrive at the number (that is subsequently being ignored by the consolidation) can be all over the place.

It does get confusing though as even in a zero suppressed view you can get un fed values displaying.

Yes, I think the fact that sometimes you can see unfed numbers being calculated does confuse things a lot.

Last time feeders came up we had a veerrry long conversation.  And there's a note in that thread that the original Yahoo group also had a really long discussion about them.  Funny how it's really difficult to completely understand them!

Martin

315196952

Scary isn't it that some of the most experienced and sharpest TM1 brains around with decades of experience between us are sill not QUITE sure how feeders work.

Dealing in relatively dense and high level models as I generally do in planning, and where the rules can get quite complex, I generally avoid feeders wherever I can in the interest of maintainability. (I know this is probably heretical, but I am sure I am not really alone). In my experience over 13 years now, only seasoned admin have anything approaching a decent understanding of feeders and even then the potential for error is still vast.

When I tested the difference in our OTB model, we were seeing a model with skipcheck and feeders calculating top level consolidations in about 5 second instead of 15. With most of the planning taking place at low level and 1000 lines of rules the benefits of maintaining feeders for the performance increase just don't stack up to me. The only thing that makes me wonder about it is the abysmal performance over a WAN in Excel, where any performance increase would be welcome.

I do realise that with large sparse reporting model with a  few simple rules the performance gain is well worth the candle.

What still worries me is the fact that when I last checked ASCII export was still unreliable for calculated variables in cubes without skipcheck and feeders. I haven't checked in 9.1.4 and all my enquiries have now been resolves  - or should that be "disappeared" so I have no idae if they thik they fixed it.

西山红叶

John Hobson wrote:I do realise that with large sparse reporting model with a  few simple rules the performance gain is well worth the candle.

Most definitely.  I recently fine tuned some feeders that cut down a high level view from 90 seconds to 30 seconds.  I hate to think what it'd be without the feeders at all.

I agree though, for small or dense cubes they're often not worth the extra work.

Martin

jsyyrs

I think you can infer that the unfed cells do not get calculated in a suppressed view from the response time you get.
Also logically since the cell is unfed the calculation engine does not know that there might be a value there and so doesn't calculate it.  The trouble is you cannot actually prove this since looking to see if the value is there forces it to calculate. Quantum Physics in action! Sort of...

Actually you might be able to prove it by looking in the performance monitor at the calculated cell counts?

I think the problem with both the statements in the OP is that they don't make a distinction on zero-suppression.  Your statement is true if looking at zero-suppresed views, the other true if not.

On the subject of deep technical understanding, I did do a document when I was working at InfoCat that I thought did a pretty good job of explaining what was going on under the hood, not sure if they would be prepared to post it...

Esuom

The rule will always calculate

The distinction that is missing from this quote is " ... if queried directly" for example in an non zero supressed view or directly in Excel via DBRW. The result of the calculation however won't necessarily be correct if the rule is not fed or intermediate calculations that it relies on are not fed.

If one rule calculation flowed into another and the first was not fed and the downstream cell was then queried the first cell would NOT calculate if it were not fed* due to the sparse consolidation algorithm (provided SkipCheck was turned on of course.)

* unless it were a C level rule and leaf cells below it contained real input data

Complicated ain't it.

碧·染

Hi

Starting to read the thread I was going to add Scott's bolt statement to clear things up.
As far as I understand it this applies to both calculations and consolidations: they are only calculated if queried. But imo it would be incorrect to state that a rule is not calculated if not fed.
The other way around: a rule calculated cell is skipped (not caclulated) when consolidating if it is not fed.

Cheers

cswing_5

Gregor Koch wrote:Hi

Starting to read the thread I was going to add Scott's bolt statement to clear things up.
As far as I understand it this applies to both calculations and consolidations: they are only calculated if queried. But imo it would be incorrect to state that a rule is not calculated if not fed.
The other way around: a rule calculated cell is skipped (not caclulated) when consolidating if it is not fed.

Cheers

or, phrased differently: If a tree in a forest falls, with nobody around to hear it, does it make a sound?

G

wanglinyangling

or, phrased differently: If a tree in a forest falls, with nobody around to hear it, does it make a sound?

Schr?露dinger's cube?