Consolidate instead of Feeding / Feeders

[Kingsley]

Is it true that instead of having feeders for certain calculations, we can add the elements as the child to the calculated element?
It was suggested to me by a consultant but I never understood why it worked.

Ex. ['ConsolidatedElement1'] = ['Element1'] * ['Element2'];

Instead of having:
['Element1'] => ['ConsolidatedElement1'];
['Element2'] => ['ConsolidatedElement1'];

We can simply add Element1 and Element2 as a child of ConsolidatedElement1

+ConsolidatedElement1
- Element1
- Element2

Can someone clarify this to me?
Thanks

[jim wood]

When a calculated value consolidates and it isn't fed then there is no flag in place to tell the consolidation that the value is there. What your suggesting effectively flips this. Your making the calculated element a consolidation. This means as a consolidation it's children retain their flags as they are not calculated, meaning the element would consolidate normally if there was no rule. In your case you can change your rule to:

Code: Select all

['ConsolidatedElement1'] = C: ['Element1'] * ['Element2'];

As it becomes a consolidation override rule rather than a rule that applies at level 0. Keep one thing in mind, this could become very confusing to users as say having Sales as the consolidation of Price and Sales units wouldn't make much sense. In some cases you could may be hide the children but in the example above it wouldn't be a good fit. This is main reason we don't just all use consolidations instead.

I hope that makes sense,

Jim.

[Kingsley]

Our cube goes through a lot of heavy calculations and we are trying to minimize feeding in hopes to improve performance. You are right about the model being very confusing, but could this be a workaround/improvement in terms of speed?

[jim wood]

The first question to ask is, do the calculations have to be real time? If not could they be moved to a TI process. Then you should look at fine tuning your feeders. If your still having issues then you could look at something like you've suggested. Keep in mind that nothing performs worse than a bad feeder. You may also want to research variable feeders Vs. over feeding on the forum.

Hopefully that should give you something to start with,

Jim.

[Kingsley]

Thanks Jim.

[lotsaram]

Is it true that instead of having feeders for certain calculations, we can add the elements as the child to the calculated element?
It was suggested to me by a consultant but I never understood why it worked.

Ex. ['ConsolidatedElement1'] = ['Element1'] * ['Element2'];

Instead of having:
['Element1'] => ['ConsolidatedElement1'];
['Element2'] => ['ConsolidatedElement1'];

We can simply add Element1 and Element2 as a child of ConsolidatedElement1

+ConsolidatedElement1
- Element1
- Element2

Can someone clarify this to me?
Thanks

I use this technique all the time. It can be very effective, especially for KPI type measures calculated by division or multiplication that need to be used with zero suppression. Performance is good in these situations and users aren't typically confused by the element displaying as a consolidation as it can be easily explained and is relatively intuitive that the child elements are driving the calcultion. However be very very wary of using this method for any measures that need to be consolidated as the only way to do this is with ComsolidateChildren which doesn't perform we'll at all.

[jim wood]

Lotsa,

While I agree it can be used effectively for some KPIs, it's not a sweeping replacement for all feeders. I do however agree that in the cases you mentioned it can be easily explained away, but again in these cases, not all. It can also depend on the user base. I've worked with people that flat out refused this. Which of course makes no sense, but you know what they say, there's nothing more queer than folk.

I do however go back to the steps I mentioned above, this should be used in conjunction with other options,

Jim.

[Wim Gielis]

It's indeed very effective and a very clever trick.

The usual situation is that it can avoid rules and feeders in the case of "thousands values" (,000) or millions (,000000):
add a child, change its element weight to 0,001 or 0,000001.

The use of consolidations instead of feeders, can be important in heavy cubes. Year-over-year changes, ratio's, currency conversions, ... can all lend themselves to this approach.

I don't share the experience that users tend to find it confusing - obviously it also depends on the way of reporting.
if the user cannot double click on the consolidated element, he will not see the children.

Once users see the benefits of this approach, they fully agree and vote for it.

[lotsaram]

I don't share the experience that users tend to find it confusing - obviously it also depends on the way of reporting.
if the user cannot double click on the consolidated element, he will not see the children.

Once users see the benefits of this approach, they fully agree and vote for it.

I agree. I have never seen an end user object to this or for that matter have an opinion one way or the other. I have seen developers reject it though due to it being new and turning some design principals on their heads. But it is a good, tried and true method for the right circumstance and old dogs gotta learn new tricks.

[Sukumarwithyou]

When a calculated value consolidates and it isn't fed then there is no flag in place to tell the consolidation that the value is there. What your suggesting effectively flips this. Your making the calculated element a consolidation. This means as a consolidation it's children retain their flags as they are not calculated, meaning the element would consolidate normally if there was no rule. In your case you can change your rule to:

Code: Select all

['ConsolidatedElement1'] = C: ['Element1'] * ['Element2'];

As it becomes a consolidation override rule rather than a rule that applies at level 0. Keep one thing in mind, this could become very confusing to users as say having Sales as the consolidation of Price and Sales units wouldn't make much sense. In some cases you could may be hide the children but in the example above it wouldn't be a good fit. This is main reason we don't just all use consolidations instead.

I hope that makes sense,

Jim.

This is really a good trick to improve the system performance. To avoid user confusion, Create invisible node under the consolidation and add elements to this invisible node. Manage through security not to show this invisible node to all users. I hope this helps.

Sukumar.

[Gabor]

Feeding via natural consolidation is the only option to handle large data volumes in dynamic (rule driven) cubes.
It took a long time until Ver. 8.2.2 introduced the ConsolidateChildren function to really make it usable across multiple dims.

Together with C-level calculations both features can be a strong booster for clever TM1 rules in large cubes.

[Kingsley]

When a calculated value consolidates and it isn't fed then there is no flag in place to tell the consolidation that the value is there. What your suggesting effectively flips this. Your making the calculated element a consolidation. This means as a consolidation it's children retain their flags as they are not calculated, meaning the element would consolidate normally if there was no rule. In your case you can change your rule to:

Code: Select all

['ConsolidatedElement1'] = C: ['Element1'] * ['Element2'];

As it becomes a consolidation override rule rather than a rule that applies at level 0. Keep one thing in mind, this could become very confusing to users as say having Sales as the consolidation of Price and Sales units wouldn't make much sense. In some cases you could may be hide the children but in the example above it wouldn't be a good fit. This is main reason we don't just all use consolidations instead.

I hope that makes sense,

Jim.

This is really a good trick to improve the system performance. To avoid user confusion, Create invisible node under the consolidation and add elements to this invisible node. Manage through security not to show this invisible node to all users. I hope this helps.

Sukumar.

Hi Sukumar,

Can you walk me through on how to create an invisible node under a consolidation?

[jim wood]

As he mentioned you'd do it through security, specifically dimension level security. You just need to set the security to none for the items underneath the new consolidation. The only issue you have is if you are adding children that are somewhere else and need to be seen. You can get around this by adding 2 levels to the hierarchy. For example create ConsolidatedElement2 which is a parent of ConsoldiatedElement1. Then element1 and element2 rolls in to CE1. If you set the element access to CE1 as none, users still get CE2 but they can't expand any lower as they have no access to CE1. I hope that helps,

Jim.

[jim wood]

I agree. I have never seen an end user object to this or for that matter have an opinion one way or the other.

Not surprising for small implementations in small companies. With larger implementation in large companies you have a wider scope of users, some more proficient than others. So I can only guess that you've never come across this situation?

old dogs gotta learn new tricks.

We never stop learning, but I'm curious what you meant by that? Are you saying there are many people developing TM1 that think that their way is the only way?

[lotsaram]

I agree. I have never seen an end user object to this or for that matter have an opinion one way or the other.

Not surprising for small implementations in small companies. With larger implementation in large companies you have a wider scope of users, some more proficient than others. So I can only guess that you've never come across this situation?

Don't know what would give you that idea. Actually I see it as the boot being very much on the other foot. In smaller implementations it is much more likely that the TM1 support and development person will be someone from finance (or appropriate department if it is more of an operational model) and so the users will tend to be technically more hands on and more likely to know something about developing in TM1 and have some sort of opinion, whether informed or not. However the bigger you go the more that end users are hands off (whether through disinterest of bing held back by IT with pitchforks at the ready). And, in big shops regardless of whether there are good quality internals or not, most systems tend to get developed by externals (the internals are too busy managing operations on existing systems and managing the consultants on any new projects.) But I stand by the comment, I think you would be genuinely hard pressed to find any end user who gave two hoots that there was a little plus next to an element in the cube viewer that didn't expand when they clicked it. If the numbers are correct and it enables massive savings on rule save time, server load time and memory then developers shouldn't care either (IMHO).

I'm curious what you meant by that? Are you saying there are many people developing TM1 that think that their way is the only way?

In every walk of life, I don't think our little niche is any different in that respect.

[paulsimon]

Hi

A classic example of this is currency conversion where you put the Transaction Currency as an N level element under multiple reporting currencies at the C level. However, as soon as you do that you have to start carrying out other rules at the C level too. In my view if you are only converting to 2-3 reporting currencies then it is not worth the extra complexity. However, the complexity tends to affect the developer, and need not necessarily affect the end-user.

Regards

Paul Simon