TM1 cube weird fed values without feeders causing incorrect rule calculation

If wonder why some leaf cells are fed even you do not have any feeder, you might troubleshoot it by following the next steps:
1. Stop TM1 server and delete all feeder files, then start TM1 server. This way you ensure all feeders are cleared from TM1 cache (yes TM1 caches feeders and show cells as fed even if the feeder no longer exists). If it does not help, check step #2
2. Stop TM1 server and delete all feeder files, remove cube rule calculation (you can move RUX files to some temporary folder). Start TM1 server. Check if previously fed cells contain any static values, that would cause an implicit feeding.

Basically the last often explains incorrect rule calculation on a cell that was previously editable, though it is the expected TM1 behavior.

Missing feeders are the reason why the real leaf values are seen instead of the rules derived values after the N level rule has been re-instated.

First, the customer disabled the N level rule. Second, they manually entered values into the leaf cells formerly covered by the N level rule. Third, they re-instated the N level rule. After that, when the values of the leaf cells are requested by another rule, due to the missing feeders there is no indication that the values of the leaf cell are anything but simple leaf values i
nstead of rule calculated values thus the sinple leaf values will be delivered instead of the rule calculated values.
If rules are to apply to cells, when the cells also may contain leaves, then these cells must be ‘fed’. This marks the cell as ‘a rule may apply’, so that when the value of the cell is reques
ted as part of running another rule, the rule for the cell is run.

The issue seen here is a direct result of an optimization when editing rules, and an indirect result of some TM1 functionality.

When feeders for a cube are processed, TM1 goes through all of the real leaf cells and runs the feeder rules (if they apply) to each of those cells. In the process TM1 determines if a rule applies to the particular leaf cell, and if it does TM1 applies a ‘feeder’ flag to that real leaf cell, if it is not already so marked. The presence of this feeder flag will trigger later rule evaluation on the cell, even though there also a real leaf value and there is no actual feeder rule which references this cell.

Prior to TM1 10.2.2, whenever any edit was made to a cube’s rules, the feeders for that cube would be re-calculated. Even if just a comment in the rules was changed, the feeders would be re
calculated. The recalculation of feeders for a large cube can be very time consuming (on the order of hours in some cases). An optimization in TM1 10.2.2 functions such that unless the actua
l feeder rules have changed, feeders are not rerun since the feeders which result from the feeders rules will not have changed.

In this particular case, the rules are edited to turn off a rule, so that values can be manually entered into some leaves. The rules are then edited to re-establish the rule that covers the c
ell values just entered. Prior to TM1 10.2.2 this second edit of the rule file to re-establish the rule would trigger a complete recalculation of all of the feeders. In the process the feeder flag would be set for the newly entered values, since they would be used as starting points for feeder calculation and it would be found that a rule applied. Since the feeders have not changed, starting TM1 10.2.2 the feeder rules are not rerun. This means that the feeder flag for the newly entered cells will not be set, which results in the effect seen.

If, for some reason, edits of this nature are to be made, a TM1 developer can force a recalculation of the feeders with the TurboIntegrator (TI) function “CubeProcessFeeders()”:
The TM1 developer has to write a small TI process containing the line
and run it after the cube’s rules are edited to re-establish the rule. After that the results will be as expected.

The reason that unloading and reloading the cube seemed to ‘fix’ the problem is that the feeders are completely rerun when the cube is reloaded.

You also need to run feeders where you are feeding based on a reference to an attribute or from a consolidation that may have changed. I seem to recall a model where we were feeding to an intersection to a target cell which included referenced few DB reads to the cube to bring back the elements required. We had to trigger feeders periodically. FEEDSTRINGS had no impact in this situation.

Recent Posts

Recent Comments


Written by:

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *