TM1 Forum

Hi All,
We've a problem in our TM1 system...We've a few cubes with data which hold day-level data.

When we write a rule/feeders in these cubes with day-level data and save, it takes a huge amount of time (say more than 1 hr), the screen grays out and we don't know whether something is being processed or not. At last, we have to force close the window.

I've a few doubts on the rules/feeders file:
a) What should be the ideal size of the files (.rux, .feeders) etc in terms of the .cub file? For one of these day-level cubes, my .feeders file is twice the size of the cube. My cube file (.cub) is 3 GB whereas my .feeders file with the same name as the cube is twice the size - 6 GB. Rule file is just 2 Kb.
b) Is there any known limitation with TM1 that beyond a certain threshold of data, it becomes unstable.
c) What is overfeeding? How can we find out that we're not overfeeding the cube? and of course, what are the workarounds?

Sorry if my questions sound too vague. Please note that I'm a beginner...

Regards,
Deepu.

deepu_sree wrote:a) What should be the ideal size of the files (.rux, .feeders) etc in terms of the .cub file?

There is no "ideal" size. That's like asking what is the ideal size of a database. The size all depends on how big your cube, i.e., database, is.

deepu_sree wrote:For one of these day-level cubes, my .feeders file is twice the size of the cube. My cube file (.cub) is 3 GB whereas my .feeders file with the same name as the cube is twice the size - 6 GB.

A 3 GB cube is pretty damn big but it doesn't surprise me if you are tracking day-level data. Unfortunately, you haven't provided any more details about your cube so I have no way of knowing whether that number actually makes sense. I'm assuming it does because it represents raw data.

deepu_sree wrote:Rule file is just 2 Kb.

A rule file is just raw, uncomplied code. It's size is really meaningless.

deepu_sree wrote:b) Is there any known limitation with TM1 that beyond a certain threshold of data, it becomes unstable.

That all depends on the RAM in your server. If TM1 uses up all the available RAM then the system will crash. Simple as that.

deepu_sree wrote: c) What is overfeeding? How can we find out that we're not overfeeding the cube? and of course, what are the workarounds?

You seem to be aware of what feeding means. Overfeeding just means you have told TM1 that there is going to be data in an intersection(s) where no data actually exists. It does not result in an error, data-wise, it just needlessly wastes resources. Whether or not you have overfed really depends on the logic you have used to do the feeding. This is one of the most difficult aspects of developing in TM1. Since you are a newbie it is highely likely you have overfed, but not necessarily, Review your feeder logic carefully and make sure it makes the most sense. If your rule calculations are simple then the feeding is simple. If you have gotten fancy with your calcs then overfeeding could be an issue. One hour to calculate feeders seems excessive but not necessarily so, it all depends on how many calculated intersections you have in the cube,

deepu_sree wrote: c) What is overfeeding? How can we find out that we're not overfeeding the cube? and of course, what are the workarounds?

You seem to be aware of what feeding means. Overfeeding just means you have told TM1 that there is going to be data in an intersection(s) where no data actually exists. It does not result in an error, data-wise, it just needlessly wastes resources. Whether or not you have overfed really depends on the logic you have used to do the feeding. This is one of the most difficult aspects of developing in TM1. Since you are a newbie it is highely likely you have overfed, but not necessarily, Review your feeder logic carefully and make sure it makes the most sense. If your rule calculations are simple then the feeding is simple. If you have gotten fancy with your calcs then overfeeding could be an issue. One hour to calculate feeders seems excessive but not necessarily so, it all depends on how many calculated intersections you have in the cube,

On a simple example. We have a rule ['Cost'] = N:['Price']*['Qty']. By a rule we should in a "feeders" to define dependence of cost on the price and quantity, but we know that price is not discharged in difference from quantity. Therefore it makes sense to set a feeder only on quantity, and feeder definition on the price and quantity also is called "overfeeding"

I can't help myself, just wanted to clarify the definition of overfeeding.

There are two kinds of overfeeding.
[Source]=>[Destination];
Overfeeding the Destination
In general terms if a ruled cell is fed that evaluates to zero then you have overfed the destination, i.e. the destination area is bigger than it needs to be. This leads to slower rule saving and slower rule calculation if you are requesting the zero areas from the cube
Overfeeding from the Source
This is where the source area for the feeders is bigger than it needs to be, it leads to slow saving of rules but doesn't impact the performance. Of course if you overfeed from the source you will often overfeed the destination too.

In fliptops example ['Cost'] = N:['Price']*['Qty']; we want to feed with the least populated of the values on the right, the reason we pick Qty to feed with and not Price is that for a given period we will have a price for every product we sell but only have Qty when we make a sale.

So the number of populated data points for Qty will always be less than Price so we should feed with Qty
HTH
Cheers

Although you never want to waste anything, including time, overfeeding from the source is not that big a deal. All it costs you is time. Overfeeding the destination as far worse because it wastes RAM. I would more concerned about overfeeding the destination. That's the real killer.