This article will be collecting useful information about how TM1 FEEDERS work.

1. TM1 has a sparse consolidation algorithm which allows to skip calculations of empty/zero cells and significantly improve the performance. If you have a cube rule, by default TM1 turns off this algorithm because one or more empty cells may in fact be calculated by a rule and skipping rules-calculated cells will cause consolidated totals to be incorrect. When the sparse consolidation algorithm is turned off, every cell is checked for a value during consolidation. This can slow down calculations in cubes that are very large and sparse.

Use **SKIPCHECK;** in the beginning of your rule to enable sparse consolidation algorithm. You must also include a **FEEDERS;** declaration and that all rules-derived cells are identified by feeder statements. If you need to feed from string-type elements, you should include **FEEDSTRINGS;** before SKIPCHECK, so the entire rule structure will be:

FEEDSTRINGS; SKIPCHECK; ## your rules FEEDERS; ## your feeders

2. Use a consolidation whenever you can if you need to calculate aggregation (you can also play with elements’ weight to build some formulas). A consolidation will be fed if there is any value for one of its children.

3. Feeders work on N-level only.

Feeding from a C-level (consolidated element is on the left hand side of a feeder statement) is a shortcut for all the ultimate N element descendants of that C element.

Feeding a C-level (consolidated element is on the right hand side of a feeder statement) is a shortcut to feed all the ultimate N element descendants of that C element.

Below there is an example to understand it better.

We have a source cube feeding the target:

The target cube has the following rule:

SKIPCHECK; [] =N: DB('sourceCube', !month, !acc2);

Now let’s look at a few possible rules for our sourceCube:

sourceCube **RULE 1**

SKIPCHECK; FEEDERS; [{'B','C'}] => DB('targetCube', !month, !acc1);

Result: As feeders work on N-level, we will have ‘C’ feeding ‘C’. ‘A’ element will not be fed in the target cube, so the target element ‘D’ will be equal to 20.

sourceCube

**RULE 2**

SKIPCHECK; FEEDERS; ['A'] => DB('targetCube', !month, !acc1);

Result: ‘A’ on the left hand side of the feeder statement is equal to ‘A’ element n-level descendants (‘B’ and ‘C’), as result we will have the same situation as with rule 1, so the target element ‘D’ will be equal to 20.

sourceCube

**RULE 3**

SKIPCHECK; FEEDERS; ['A'] => DB('targetCube', !month, 'A');

Result: ‘A’ on the left hand side of the feeder statement is equal to ‘A’ element n-level descendants, meaning elements ‘B’ and ‘C’ feeding only element ‘A’ in the target cube. Element ‘C’ will not be fed, so the target element ‘D’ will be equal to 30.

The only possible way to feed all elements in the target cube is to have some overfeeding:

sourceCube **RULE 4**

SKIPCHECK; FEEDERS; ['A'] => DB('targetCube', !month, 'D');

“Use a consolidation whenever you can if you need to calculate aggregation”

Please correct me if I am off the mark here, I guess, above statement is not correct.

Feeding to and from should be avoided at all times as it lead to feeding to all children underneath the consolidation ,same logic goes for feeding from consolidation.

Hi, that point means the following: if you have any kind of aggregation or a simple formula that could be implemented by setting elements’ weights, you should use a consolidation element instead of a leaf one calculated by a rule.

If you cannot implement calculation using elements weights, you can still have that element as a consolidation with a C-rule and children feeding that element.

In both cases you don’t need to write any feeders for your calculated element as it will be automatically fed by its children.

Thanks Vlad ,I am sorry if I am not getting your point. But I wonder how many time do write a rule at C level just to forgo feeders! I have seen C level rules mostly at ratio and averages based calculations. I would again reiterate that C level feeding leads to unnecessary overfeeding which should be avoided. Perhaps an example would help a great deal if we are not on the same page here.