Feed C level rules

jxs0103

Hi,

I have a problem of an instance RAM growing too much because of feeders.

In a few words:
-My main cube has 14 dimensions.
-Most of data are stored, a few calculation rules getting data from another cube.
-About 10 ratios and indexes calculations. Those calculations are the source of my problem. They are ratios so my rules do not have neither N: nor C:
The calculation works perfectly well, but my users want to be able to use suppress zero functionality. So I had to feed those rules. This makes the RAM grow from about 4 Go (without feeding the ratios) to 21 Go (feeding the 10 ratios).

Here is an exemple of one ratio and its feeders:
['U_WBrand']=['U_TOT']['U_TOT','B1G']*100;
['U_TOT']=>['U_WBrand'];

Any idea why the RAM grows so much?

Thank you

kbswangyang

Is U_TOT a consolidation?

0o小坏o0

jim wood wrote:Is U_TOT a consolidation?

Yes, it is. But it only has two children.

315196952

What about U_WBRand? Also are any of the chikdren calculated? How big is your cube dimension wise? Do you have any large dimensions?

messiahxu

You can't feed a consolidation. Referencing a consolidated node in the feeder rule has the effect of feeding all the children underneath the consolidation. So, if you write your rule to calculate the ratio based on all nodes (bascially leaving out the N: or C: before) then the ratio will calculate correctly, but it won't be fed and a zero suppress will hide the ratio, if shown by itself. The only way I know around this is to structure your view so that the row or column that the ratio is in won't be suppressed because there are other values on the same row and/or column that have values and the ratio just comes along for the ride.

yseen

tomok wrote:The only way I know around this is to structure your view so that the row or column that the ratio is in won't be suppressed because there are other values on the same row and/or column that have values and the ratio just comes along for the ride.

There are better ways to do this.
For example, turn the ratio into a consolidation by adding a child that is fed correctly or contains base level data.
This will make sure the ratio is fed.
Basically, a component of the ratio could be a valid candidate to be the child. It could be a consolidated element in itself just as well.
Consumes no extra memory at all.

sysease

Wim Gielis wrote:For example, turn the ratio into a consolidation by adding a child that is fed correctly or contains base level data.
This will make sure the ratio is fed.

If you make the ratio a consolidation and have other children underneath it that contain anything other than zero then your ratio won't be correct. A ratio of 20% plus another child that has a 1 is now equal to a consolidated ratio of 120%. Not the right answer. You would have to add a child with a zero balance and feed that child. Sorry, I just wouldn't do this.

yagami_ren

Hello Tomok

Maybe I did not understand, or maybe I expressed myself in a not so clear way
The ratio will change from N to C level but it will contain the exact same rule (this is, no qualifier for N as this is useless now).
The children of the ratio will just be denominator or numerator of the ratio, depends.

Wim

wzsycdh

tomok wrote:[quote]Wim Gielis wrote:For example, turn the ratio into a consolidation by adding a child that is fed correctly or contains base level data.
This will make sure the ratio is fed.

If you make the ratio a consolidation and have other children underneath it that contain anything other than zero then your ratio won't be correct. A ratio of 20% plus another child that has a 1 is now equal to a consolidated ratio of 120%. Not the right answer. You would have to add a child with a zero balance and feed that child. Sorry, I just wouldn't do this.
[/quote]
I don't think Wim was suggesting to replace the rule with a consolidation but rather to keep the rule for U_WBrand and do away with the feeder as this would now be unnecessary.  Provided the rule is written as generically as it is then there isn't any risk as such of the calculated value not being correct as the rule overrides the consolidation.  I find this is frequently a very good approach, but in this instance with this kind of ratio calculation I don't really see a need to feed the calculation at all.

恭喜发财1

Wim Gielis wrote:There are better ways to do this.
For example, turn the ratio into a consolidation by adding a child that is fed correctly or contains base level data.
This will make sure the ratio is fed.
Basically, a component of the ratio could be a valid candidate to be the child. It could be a consolidated element in itself just as well.
Consumes no extra memory at all.

Hi Wim,

You conclusion sounds very well but I did not understand the way of doing it   
Could you detail it taking into account my context?

Let me just give some additional explanation on my context/rule.

My rule is the following:
['U_WBrand']=['U_TOT']['U_TOT','B1G']*100;
U_TOT is a consolidation of two elements but I think it has nothing to do with my problematic. It could be as well a leaf element.
U_WBrand is a leaf level element, and is part of the same dimension as U_TOT.
B1G is a consolidation of all elements on my Brand dimension.
So in functional terms, U_WBrand is an element on which I can read the weight of a brand relatively to all brands, on all contexts of the cube (for a specific customer or for all, for a specific country or a group of countries, etc.).

As we have big numbers of elements on all dimensions, we need to be able to suppress zeros when looking at that ratio.

Thanks in advance