What are FEEDERS?
FEEDERS are used by the IBM TM1 calculation engine to assist with handling sparsity in cubes with SKIPCHECK enabled. Some cubes may have rule calculations but be extremely small or dense and may not need SKIPCHECK. FEEDERS identify the cells in a cube that may contain a rule-based calculated value and insures these values are included in aggregation calculations.
For a more in-depth overview on FEEDERS,
see this document. What's the difference between FEEDERS and Rules?
Unlike rules, FEEDERS only ever apply to leaf level cells and never to consolidated cells. However, consolidated elements can be used in the specification of a FEEDER statement as a shorthand way of specifying all leaf elements within the consolidation. When specifying a consolidated element in a FEEDER statement the following occurs:
- Feeding from a consolidation means all leaf descendants of the consolidation will feed if there is a value present. For example, if the consolidated element contained four leaf elements but only two of these contained a value, then only those two would feed.
- Feeding to a consolidation means that all leaf cells under the consolidation will be fed. For example, if the consolidated element contained four leaf elements then all four-leaf elements would be fed.
This is an important principle as some people mistakenly believe that it is the consolidation that is doing the feeding or being fed. This can make debugging rules and feeders more difficult if this principle is not well understood.
When a FEEDER is applied, it sets a single byte “flag” or “pseudo data” in a leaf cell to signal that it should be consolidated. This ensures that the sparse consolidation algorithm does not skip this cell when computing consolidated values. Once fed, a cell stays fed until either the server is restarted or the cube is unloaded.
In general, FEEDERS are not required for C level rules. The only exception is when a rule is applied to a consolidated element where it does not have values in any of its child elements.
Common FEEDER mistakes
Underfeeding FEEDERSUnderfeeding occurs when some or all of the values that are being calculated are not fed. In most cases this will lead to incorrect results when reviewing consolidated data in the cube. Underfeeding must be avoided, as it undermines the integrity of the model. When writing FEEDERS, you should start with the inverse of the rule you are feeding to ensure feeding is adequate.
Overfeeding FEEDERSOverfeeding occurs when
(a) cells that don’t contain rule calculated values are being fed; or
(b) when rule-calculated cells that result in a zero value are being fed.
Both of these situations should be avoided but especially while overfeeding. Overfeeding will not result in incorrect values in the cube, however it has a detrimental effect on system performance. The time taken to feed cells that don’t require feeding is wasted, and all unnecessary feeders occupy memory which is also wasted. Overfeeding can cause a significant explosion in memory and can increase the execution time of consolidated queries.
Maximize performance using persistent FEEDERS
Persistent FEEDERS help a TM1 server start up quicker. When the persistent feeders’ parameter is set to T, the TM1 server will create feeder files for each cube that has FEEDERS in their rule files. When the TM1 server starts up it matches the FEEDERS for each cube by the coordinates in the feeder files and loads them, removing the need to recalculate the feeders and that in turn saves time. A drawback of persistent feeders is the use of disk space. Feeder files can be huge and you must take extra care when using them.
For more information on persistent feeders,
see this document.
Tips for controlling FEEDER Generation#administrator#ExpertPost#modeler#performance#PlanningAnalyticswithWatson#PlanningAnalytics#Tips#TM1Models#Video