TM1 Forum

Hi all,

I have two cubes "linked" by rules. In particular, first cube rule has the following feeder:
['tot amm'] => DB('CE budget', !Azienda, ATTRS('immobilizzazioni', !immobilizzazioni, 'Piano dei Conti'), !Progetti, !Struttura, !Tempo, 'f10', 'Bdg');

while in the rule of the second cube I have the following statement:
['f10','Bdg'] = N:
IF ( (DIMIX('immobilizzazioni', !Piano dei Conti) > 0),
DB('Ammortamenti', !Azienda, !Tempo, !Struttura budget, !Progetti, 'tot amm', ELPAR('immobilizzazioni', !Piano dei Conti, 1)),
0
);

In this way the element f10 of the measure dimension 'Bdg' is fed by the feeder wrote above.
"Sometimes", this mechanism doesn't work (see the attached images, please) In fact, some cells in the 'CE budget' are well consolidated while others are not consolidated. Using "Check feeders" I noticed that leaf cells are not fed. What does this mean??
Moreover, I don't understand the following behavior:
1. I commented the feeder wrote above and saved the rule
2. I uncommented the feeder wrote above and saved the rule
3. All works well!!!!

Why? Does anybody can help me to understand how can I solve this issue?
I'm using TM1 10.2.2
Many thanks in advance

Possibly due to using an attribute in your target - does reprocessing feeders or changing feeders and saving give you the correct result?
I know you said that you made changes to the rule but can you check if when you have the non-feeding scenario, change rule (to re-feed) do you get the correct results with each update/save?

hi,

After you had changed the attribute, the rule recalculated well, because rule recalculates every time you open a view.
The feeders fed 1 time to the old attribute value, when you entered the values to source cube. After the attribute value had changed, the feeders difn't refire (and sould not) to the new attribute.
Note that the feeder tracer vurtually "feeds" the whole feeder chain, so if you use it, it will show "Fed".

For this cases I make a websheet to edit the attribute values with big red "REFEED AFTER ATTRIBUTE CHANGE" and with action button which unloads the target cubes and refeeds the source and target cubes

gtonkin wrote:Possibly due to using an attribute in your target - does reprocessing feeders or changing feeders and saving give you the correct result?
I know you said that you made changes to the rule but can you check if when you have the non-feeding scenario, change rule (to re-feed) do you get the correct results with each update/save?

Yes, the result is correct.
As said, because when I perform the two operations described in my previous post about the feeder, the result is correct, I'm trying to delete .feeder files in my Tm1 data folder (even if PersistentFeeders is not enabled....)

A better solution may be to remove the attribute requirement from the feeder. Create a system rollup of the chart of accounts based on the attribute and then feed from this (ELPAR of the COA) - if the structure of the system rollup changes, you would need to refeed.

Elessar wrote:hi,

After you had changed the attribute, the rule recalculated well, because rule recalculates every time you open a view.
The feeders fed 1 time to the old attribute value, when you entered the values to source cube. After the attribute value had changed, the feeders difn't refire (and sould not) to the new attribute.
Note that the feeder tracer vurtually "feeds" the whole feeder chain, so if you use it, it will show "Fed".

For this cases I make a websheet to edit the attribute values with big red "REFEED AFTER ATTRIBUTE CHANGE" and with action button which unloads the target cubes and refeeds the source and target cubes

I don't understand....because the feeders logic is related to attribute, do I need to refeed each time I insert an element in the dimension related to the attribute?
Or...is this behavior caused only when I insert an element with an attribute and then I edit this attribute?
At the end...how can i refeed without entering in rules, edit the code and save (as described in my frist post)?
Sorry..I'm confused...

The numeric feeders fire Once, when you enter the numeric value to source cube. If the condition changes (attribute, dimension change), the rule in target cube realculates correctly every time you open view. But nobody tell feeders to refire, so they remain in their old positions.

Another way to refeed: create a process with "Reprocessfeeders" in it. You can also want to unload a target cube to erase old feeders prior to refeed.

There is an extremely useful document about feeders, hope it will help you to pal up them: http://www.ibm.com/developerworks/data/ ... ge620.html

Elessar wrote:The numeric feeders fire Once, when you enter the numeric value to source cube. If the condition changes (attribute, dimension change), the rule in target cube realculates correctly every time you open view. But nobody tell feeders to refire, so they remain in their old positions.

Another way to refeed: create a process with "Reprocessfeeders" in it. You can also want to unload a target cube to erase old feeders prior to refeed.

ok, I thought i was a bug in my code....
So, I'll create a ReProcessFeeders as you adviced to solve the problem
But ...why doesn't IBM improve this behavior?

But ...why doesn't IBM improve this behavior?

Not to put words in IBMs or others mouth but I think most would consider the current behaviour to be the best compromise.

Re-firing feeders is fairly expensive in terms of time and resource and scales quickly as the volume of data increases, having feeders re-fire at every possible event that could be involved in a feeder statement would result in very soggy system.

Feeders currently fire in the following cases, when a cell changes from 0 to non-zero, at server launch and cube load from unload. Given this it is more sensible to ask have I designed the system the best I can rather than to ask IBM to change the way the software works to fit your design.

Depending on several factors you may be better off overfeeding so that you never need to retrigger the feeders.
These factors include.
How often the attribute / structure changes?
How good are the long term internal controls going to be so that the retrigger happens?
Can I put a TI in place so that the need to refire can be detected and executed?
How long will it take to take refire in production when it is full of data?
What is the impact of overfeeding on RAM and calc time of the rule?

I'd lean towards overfeeding and a maintenance free piece of functionality if the impact of overfeeding was not dramatic.


Cheers

Many thanks to all for precious advices!

Steve Rowe wrote:Feeders currently fire in the following cases, when a cell changes from 0 to non-zero, at server launch and cube load from unload.

There is also a (documented) config parameter ForceReevaluationOfFeedersForFedCellsOnDataChange that tells TM1 to run the feeder statement whenever a cell value changes, instead of just when it changes from 0 (default) to non-zero. There is of course the performance cost of running the feeder more often, but this can sometimes be useful for conditional feeders whose condition depends on data values.

Sure, I was trying to keep things a little simple and for the general case, though the standard install does seem to activate this cfg as a default position now, allegedly due to the inner workings to TM1 Apps Web or maybe to make sure that PM driven wizard codes works, not sure.

Would this help in this exact situation, where the condition / reference value changes? I think not, you would have to wait for the source cell value to change to get the feeder to re-evaluate.

In this case, the feeder statement is only executed when all feeders are (re)processed, or when ['tot amm'] goes from zero to non-zero (as you already enumerated). Changing the config option would cause the statement to be executed anytime the value for ['tot amm'] changes. Just changing the attribute would still NOT execute the feeder again.

I know PM often requires the config switch, but I wasn't aware it was a default from the install now.