TM1 Forum

Hi all,

I'm encountering an issue in version 9.5.2, but I don't think it is specific to this version. When I open a cube, it takes about 1 minute to open the default view.

I have gone through the rules and feeders in an attempt to optimize the cube. I have also set the Default view to display only data in Actual version which has very little rules applied. So I expect this view to open fast.

The main dimension in this cube is BS Account and it has about 6000 elements, both parents and children. In this dim, there are a lot of parents that only have one child below. For example:

Parent 1
Parent 2
Parent 3
Parent 4
Only child of Parent 4

The dim is set up this way as per client's request. This of course has a usability issue as user has to drill down many levels unnecessarily.

I suppose the impact on memory will be that TM1 now has to store the consolidated value in memory for all such parents. Am I right to say that, if I remove all the parents and leave Parent 1 as the direct parent of the only child, then the memory usage will be reduced?

Will this also help in opening up the default view much faster?

Next question is, data in Actual version is repeated in Budget version using rules i.e. ['Budget'] = ['Actual'] if Period and Year are already actualised in that Budget version.

So when TM1 generates a view with only Actual data, does it also start to calculate the data in Budget version even if the view does not show the Budget data at all?

Hi,
did you try to turn off the "ViewConsolidationOptimization" setting in tm1s.cfg?

If this does not help ...
I have had a similar issue after moving from version 7 to 8. The dim is not part of the grid, used for rule based what-if's and has a ratio of 1 N- to approx. 1800 C-elements above.
I was able to change the behavior by creating a public default subset, which still had all consolidations, but not the N-elements below.

I still have this solution in place, I never rechecked the behaviour under later versions.

Gabor

harrytm1 wrote:When I open a cube, it takes about 1 minute to open the default view.

It probably depends on how the "default" vew is structured. If your default view is set up to show the entire BS Account tree, or at least a very large subset of it, then you can expect it may be rather slow, especially if you have a lot of data in the cube. The answer is to make the default view very small, just a select number of items from the BS Account dimension so that it opens fast. Then users can select and/or drill into what they need after the view has been opened.

harrytm1 wrote:So when TM1 generates a view with only Actual data, does it also start to calculate the data in Budget version even if the view does not show the Budget data at all?

No, not in the scenario you've given.

ViewConsolidationOptimization is set to T. Here are the tm1s parameters:
CheckFeedersMaximumCells=1000000
AllowSeparateNandCRules=T
AllRuleCalcStargateOptimization=T
PersistentFeeders=T
UseStargateForRules=T
ViewConsolidationOptimization=T
DisableWorksheetView=F

In the Default view, I deliberately show only the top 2 levels of the dimension in question. So it looks like this for the Row dimension:
Balance
=>Assets
=> Equity & Liabilities
==> Equity
==> Liabilities

Hence, the view only shows high level data and allow users to drill down. So the issue lies in the calculation that needs to generate the high level numbers.

Will removing those redundant parents help to make the calculation faster?

Hello

TM1 will skip calculating consolidated levels in between n level elements and the consolidations you ask for, if the consolidated values are not asked for.
For instance: if "World" is the top conso, with children (C) for continents and these have children for countries (type n).
If you ask for "World" data in a view (only that element), TM1 will not calculate the intermediate continent consolidated values.

This being said, I do not see any obvious reason why the view would be slow
(of course, we have no information on cube size, other dimensions, rules & feeders that are written efficiently or not (you had a question on feeders yesterday), how many records are written in the cube, ...)

Can you elaborate on that please?

Wim

thanks Wim.

The cube is Balance Sheet. i have isolated the cause to the rule that brings Profit after Tax (PAT) from Profit Loss cube into Bs cube as Retained Earnings (RE).

The feeder from PL cube is:
['PAT', 'YTD Jan', 'Value'] => DB('Balance Sheet', !Entity, 'RE', 'Jan', !Year, !Version, 'Value');

When the default view for BS cube is called, it takes 2 or more minutes to generate the view, despite the fact that it is Actual version where the above RE rule is the only one applicable to that version.

Likewise, there is no rules being applied in PL cube in Actual version.

So is it because there are feeders from other sub-cubes that fed into PL cube for the underlying PL accounts that roll up to PAT? So this will cause a long string of calculations to return PAT values that are needed by BS to show the values in the default view?

I'm quite stumped by this as i have done the PAT to RE thing before and this issue has never happened.

Hello again

This seems rather strange, 2 or more minutes for what should be a usual task for TM1. Even in different cubes, that will not matter.

The first remarks I can make by now, are:

- try dimension order reorganizing. If you have large accounts dimensions, try to move them to the end of the cube. I bet months, years and versions will be much smaller, much more straightforward and more 'dense'.
- you do have the Skipcheck and Feeders statements included?
- how big are the cubes? In terms of Memory used, number of distinct records (per month) that go into the cubes, how scattered are the data, what are the dimensions in the PL cube, and so on.

Wim

harrytm1 wrote:The feeder from PL cube is:
['PAT', 'YTD Jan', 'Value'] => DB('Balance Sheet', !Entity, 'RE', 'Jan', !Year, !Version, 'Value');

You are aware, of course, that feeding to or from a consolidated element has the effect of feeding to or from all the leaf level children of that element. Using PAT to feed from means you are feeding from EVERY SINGLE P&L ACCOUNT! Not good.

tomok wrote:

harrytm1 wrote:The feeder from PL cube is:
['PAT', 'YTD Jan', 'Value'] => DB('Balance Sheet', !Entity, 'RE', 'Jan', !Year, !Version, 'Value');

You are aware, of course, that feeding to or from a consolidated element has the effect of feeding to or from all the leaf level children of that element. Using PAT to feed from means you are feeding from EVERY SINGLE P&L ACCOUNT! Not good.

Yes, I'm aware. But given the nature of the rule, I have to feed the entire PAT. As long as there is value in one PL account, it will result in PAT which must then fire a feeder to feed Retainted Earnings in BS.

Having look at the whole issue, isn't feeder suppose to fire only when the feeding cell has value, whether it is calculated or manually entered? In this case, feeder will fire only if a PL acct under PAT parent has a value.

What if I create a dummy PL account "Dummy PAT" in Pl Acct dim. Then use rule to push the entire PAT into Dummy PAT. Of course I have to feed

['PAT'] => ['Dummy PAT'];

Then the rule in BS will bring the value from Dummy PAT to Retainted Earnings. The feeder will then only be Dummy PAT feeding to RE.

Will this help? I actually don't think so coz all elements under PAT will still have to be fed into Dummy PAT. The only thing i can think of is that feeding within the same cube is better.

Any views?

It's time to think outside the box. If the rule you are talking about is only for Actual, like you say, then why do you even need the rule at all? Why not make RE a data point in the BS cube and load it in via TI. Then no feeder is needed at all. My general rule of thumb in building any TM1 model is to rule calculate only numbers that need to be dynamic and TI load everything else. Actual doesn't need to be dynamic because the numbers are coming in from GL, not being calculated in TM1. Why make the model overly complicated when it doesn't need to be. Every rule you use is going to degrade performance so only use them when they need to be there. Budgeting and forecasting numbers, yes, but almost never for Actuals.