Feeders when stetting out rules

[Wim Gielis]

Hello all

I am currently in the process of replacing rules-calculated cells with hard values: I export the data, 'stet' out the rules and import data again. Not a big deal
This happens for the years 2005, 2006, 2007, 2008, 2009 in the Years dimension. For the years 2010, 2011, 2012, ... the rules should still apply.
For rules, this is straightforward. For feeders though, will I need to limit the left-hand side of the feeders to the years after 2009?

The idea is that 2005-2009 is populated with hard values, but there can still be feeders associated to these cells. But the feeders serve no purpose anymore since there are no rules active for 2005-2009.

Would it be wise and useful to insert {'2010','2011','2012'} in the left hand side of all the feeders? Or will there be no effect on cube size and memory usage if I do not add them?

Thanks for your insight,

Wim

[Catherine]

Hi,

I think you have to limit your feeders. Otherwise you will increase your memory used uselessly.
Let's say that when I met the same problem in the past, I did it

[John Hammond]

If a feeder attempts to feed a value that is not overridden by a rule then there will be no additional memory allocated.

What will cost you is the start up processing on 2005-2009 where it is checking to see if a feeder is needed.

[qml]

As John has already stated, feeding cells that are not rule-calculated, but store normal values, will not result in a bigger memory usage. In a way these cells are already "fed", that is internally marked as non-empty and usable for consolidation calculations.

[Wim Gielis]

Thanks for the replies.

I was aware that these cells are already marked as "known" or "fed". I did not know whether there was an additional memory overhead or not.

So the effects in the case of NOT adding {'2010','2011','2012'}, are:

- start-up of the model, saving the rules editor and changing a cube value will take more time (since TM1 checks whether the target of the feeder needs to be marked as "fed")
- BUT there are less hard-coded elements in the model because 2013 is now not fed

Thanks all.

[Gregor Koch]

Hi
Let alone that I would definitely limit the Feeders on the LHS as much as possible anyway.

But I beg to differ on John's and qml's comment about what makes the feeder to be set and whether it is using memory or not.

If you do trust the Performance Monitor and the data that gets recorded in "Number of Fed Cells" and "Memory Used for Feeders" (this is also discussed in another thread so this time I made sure I restarted the server in between different scenarios) you can make the following observation:

A feeder flag will be set whether there is a rule on the target cell or not (empty cell, not calculated).
A feeder flag won't be set if there is actual data in the target cell.
Memory will be used if flags are set, with or without rules but it only will be recorded after you restart the server.

EDIT: After reading both John's and qml's comments more carefully I guess that we are actually saying the same thing with the sole distinction that there does not need to be rule for the feeder flag to be set.
Sorry that I jumped the gun on this.

Cheers

[rmackenzie]

I agree that the general best practice is to limit the feeder wherever possible.

Another option could be to try a conditional feeder. Although this may have other downsides, it will allow you to limit the feeder without additional hard-coding.

However, you would need a control cube with a 'Calc from year' parameter and some attribute setup. Something like:

Code: Select all

['YOUR_MEASURE'] => DB(
  IF(ATTRN('Year',!Year,'Year_Index')<DB('Control Parameters','Calc from year','Number'),'', 'YOUR_CUBE_NAME'),
  !Dim1,!Dim2,Dim3,...!DimN,'ANOTHER_MEASURE');