TM1 Forum

I'm going crazy on trying to correct a feeder (without overfeeding)

Basically I have a capex line item type situation whereby I have specified two dimensions as data items in the source cube and calculate depreciation there. I then want to transfer this depreciation calc to another cube where the two dimensions are real. so the feeder I have (in the line items cube) is something like this.

['Depreciation_calc'] =>
db('summary',
db('line_items', !item, !Version, 'Asset Category', 'basedata'),
db('line_items', !item, !Version, 'Asset Type', 'basedata'),
, !version, !business Unit, !months);

Depreciation calc (in the line item cube) appears to be properly fed using a dnext over the time dimension.

The feeder is not correctly feeding the summary cube but when I resave the rules files some of the summary cube data is being fed properly.

as an aside when I use trace feeders from the source cube it details the exact area I want to feed correctly and says its fed. When I check feeders on the detination cube it says its not fed. I went as far as to print screen the two windows and manualy check the dimensions and they were the same??

Any help is greatly appreciated

Steve
(feeling fat and full from overfeeding this cube before christmas)

2 questions for you
- How long is the "feeder chain"?
- When you save the rule file do you get any "stack overflow" messages in the server log file?

Both these questions get at the same issue, namely that there is a limit to how many cells can be fed from a single cell. TM1's "calculation stack" is not unlimited and for this reason it is a good idea to place breakpoints into recursive calculations such as projected depreciation (or opening/closing stock, etc.). I think this is highly likely to be your problem.

If this is your issue the solution is to STET out every nth period and use TI to copy in the balance from the n-1th period and then restart the recursive calculation and the feeder chain from the breakpoint.

Thanks Lots,

I've reduced the feeder chain so that it is only feeding 12 months/elements, but still experiencing the problem. (No stack overflow messages in server log file)

It looks like when the rule is saved it evaluates the feeders based on current data, but does not change when the data in the input cube is changed. Its like its not rechecking the feeders when the dimensional data in the list changes. (I added the reevaluate feeders statement to tm1s.cfg). Out of curiosity is my feeder statement a correct approach or should I doing a conditional feeder.


Steve

I will admit I haven't looked hard at the feeder you posted, but as a general point, if you change the content of a conditional feeder, you have to refire it, by
a) Resaving the rule; or
b) Running a TI to execute CubeProcessFeeders on the cube(s) affected'; or
c) Restarting the server.

We use conditional feeders a _lot_ to manage system size. To get the benefit of turning feeders off you can unload the cube(s) and reprocess the feeders, but it can get quite fiddly. I recommend restarting.

Thanks for the help so far but I'm still experiencing problems with the design of this aspect.

The basic approach of having the list is that I want to be able to change the dimensionality quickly and easily and have live results. Maybe I'm just approaching this problem the wrong way in TM1 (having recently used EP and Alea). Which begs the question how can you use the pick lists in 9.5 if you cant use them to feed a real dimension in another cube?.

If I dimensionalise the data entry cube then when it is changed the user will have to "move" the data between the dimensions. This would be a bit painful and I wouldnt trust the users to remove the existing data. (the term users always reminds me of a favourite quote, "build it idiotproof and they'll build a better idiot"). It also seems a bit prone to error if the user has to resave the rule after data is changed.

Just curious how TM1 gurus would approach this problem,

Steve

Steve

Let me see if I understand your requirements correctly.

You want the user to be able to enter into a cube that has measures representing an amount and a text measure saying where the value should go. You then feed from the amount using the text measure to direct the feeder to the appropriate spot in the other cube.

I notice that you seem to reference another cube to get the text measure. Perhaps pulling the value into the input cube will help. You may also find that feeding from the original asset value rather than the depreciation values will help. However, I think that the key answer may be to specify feedstrings after the skipcheck, and to then feed from the string element to the value in the other cube as well

I set up a simple demo using:

Cube zTD_Test_Input with an Item dimension and a measures dimension of Amount and a String element, Centre.

Cube zTD_Test with Item and Centre dimensions and a measures dimension of just Amount

# zTD_Test_Input rules
skipcheck ;
feedstrings ;

feeders ;

['Amount']=>
DB('zTest',
!zTD_Item,
DB('zTest_Input',!zTD_Item,'Centre'),
!zTest_Input_Meas
) ;

# Feed from String element Centre to the Amount
# so that any change in Centre will result in a
# feeder being fired to Amount in the other
# Cube for the appropriate Centre

['Centre']=>
DB('zTest',
!zTD_Item,
DB('zTest_Input',!zTD_Item,'Centre'),
'Amount'
) ;

# zTD_Test rules
skipcheck ;

# Rule ensures that the value for the Centre only appears
# against one Centre, as once fed, a feeder marker is
# not necessarily removed so we need to ensure that
# value only appears against the currently selected
# Centre.

['Amount']=N:
IF( !zTD_Centre @= DB('zTest_Input',!zTD_Item,'Centre' )
,
DB('zTest_Input',!zTD_Item,!zTest_Meas)
,
0
) ;

You can replace the two feeders with

[{'Amount','Centre'}]=>
DB('zTest',
!zTD_Entity,
DB('zTest_Input',!zTD_Entity,'Centre'),
'Amount'
) ;

(By the way I also have ReevaluateConditionalFeeders in the config - though generally I have found it to be as much use as a chocolate teapot).

Regards


Paul Simon

Thanks Paul,

I took your logic and it works fine now.

Funny thing with feeders it all looks so obvious when its working. Of course when I changed the category etc it wasnt changing as I wasnt feeding the category string.

doh
steve

Steve

I wouldn't be too concerned that you didn't figure this one out yourself. This is actually a bit of an odd case. From what I can remember feedstrings was originally introduced to allow rule derived string values to show up in zero suppressed views. However, a while back I realised that you could feed a numeric value from a string. The unusual thing is that feeders from numeric cells only fire when the value goes from 0 to something non-zero. However, for strings, the feeder appears to fire whenever the string value is changed, not just when it goes from blank to something non-blank. This is obviously very handy in the example because, eg when I change the Centre Number from C_05 to C_06 in the string cell, I want the feeder to fire so that in the second cube Centre element C_06 will get fed.

By the way I would guess that feeding from strings works like feeding from numbers, once a feeder marker has been placed in a cell to say that it will get a non-zero rule derived value from a rule, then the feeder marker is never removed, even if the feeding value is changed to 0 or the feeding string is changed. Therefore it is a good idea to restart the Service periodically to free up memory.

The fact that the feeder stays means that you need to put a check on the pulling rule to make sure that it will only pull over the value to the currently selected Centre.

Regards

Paul Simon

Sorry to revive a topic where the information is already accurate and complete, but I thought I'd mention that I'm building a model right now where I'm using this technique a lot.

There was a previous version of TM1 (I think it was one of the 9.4s) that didn't seem to re-feed from the string everytime the value changed, which made this technique difficult to use without re-starting the server a lot or writing chores that periodically drop the feeders.

However in 9.5 this all appears to work as expected, and I love it.

Why? I've found it can be really useful to have a single flat cube with tabular data in a format users can understand and input easily, then feed one or more reporting cubes with the dimensionality required for analysis purposes.

If the reporting requirements change later, no problem. It's just a case of adding a new measure, importing the data (or setting a logical default), making the reporting cube, and adding a feeder.

The rules get a bit tricky sometimes, but the technique is very flexible!