Moving data from cube with different dimension

[AkashGautam]

Hi,

I'm facing performance issues with feeders in my TM1 model, and I'm seeking advice on optimizing a rule. Here's the setup:

Input Cube: IC_Input Cube
Dimensions: CBT, Company Code, Brand, Trading Partner, Business Area, Measure ("Value")

Output Cube: IC_Output Cube
Same dimensions as Input Cube

Allocation Cube: Ratio Cube
Dimensions: Company Code, Brand, Business Area, "Turnover ratio"

Requirement:

For non-dummy brands, values should be directly transferred to their respective brands.
Entries not ending with a dummy brand code should be moved to those specific brands after the initial allocation.
Any remaining unallocated dummy balance should be allocated based on a Business Area rule, which involves multiplying the dummy brand values with the provided ratio and allocating the value to respective actual brands.
The rule I've applied is:
IF(Brand=Dummy, IC_Dummy Cube * Allocation Ratio cube, IC Input Cube)

The issue I'm facing is heavy feeders due to which the RAM exceeds the limit. I've created a separate cube without the brand dimension called IC Dummy Cube to avoid one-on-one mapping from the brand in the original input cube.

I'm considering using TI coding to optimize the process. Any insights or suggestions on how to improve performance and reduce memory usage would be greatly appreciated.

Thank you!

[Wim Gielis]

TI will be the better option here.

[AkashGautam]

Yes, but I need help with the TI code

[rrizwansayed10]

Hello TM1 Team,

@WimGielis please help with this TI, if similar TI available please send.

@AkashGautam Thanks for posting this question I am also having the same challenge.

Thanks & Regards

[Wim Gielis]

Yes, but I need help with the TI code

As is the case for many TI processes, the Prolog tab code contains a zero out of the target cells. Also, the Prolog tab contains the code for creating a view collecting the input cells - those that need to be allocated.

After that, the Data tab contains code to loop over subsets in the dimensions over which you need to allocate. Each iteration will probably need to retrieve percentages. If non-zero, apply the multiplication and do a CellIncrementN() in the target cell.

To speed up the code, the Prolog tab code can create static subsets to contain the elements over which we need to loop (non-zero percentage value).
No need to loop over countless elements that don't have non-zero percentages anyway.

Also, in TI, generic Bedrock processes can take away most of the coding complexities in the Prolog tab code and speed up your work.

If performance is still quite slow, you might want to look at parallel data processing instead of sequential operations. Alternatively, a TM1py solution in Python: the heart of the allocation could be faster in Panda's or similar constructions - rather than looping in TI.

You may want to team up with the other person requesting a solution in this topic, together you can maybe advance quicker. I am not going to provide a detailed code solution here. This is not an easy job.

[Wim Gielis]

2 people who do not reply anymore because no one wrote down all the code they needed ?

[AkashGautam]

Yes, but I need help with the TI code

As is the case for many TI processes, the Prolog tab code contains a zero out of the target cells. Also, the Prolog tab contains the code for creating a view collecting the input cells - those that need to be allocated.

After that, the Data tab contains code to loop over subsets in the dimensions over which you need to allocate. Each iteration will probably need to retrieve percentages. If non-zero, apply the multiplication and do a CellIncrementN() in the target cell.

To speed up the code, the Prolog tab code can create static subsets to contain the elements over which we need to loop (non-zero percentage value).
No need to loop over countless elements that don't have non-zero percentages anyway.

Also, in TI, generic Bedrock processes can take away most of the coding complexities in the Prolog tab code and speed up your work.

If performance is still quite slow, you might want to look at parallel data processing instead of sequential operations. Alternatively, a TM1py solution in Python: the heart of the allocation could be faster in Panda's or similar constructions - rather than looping in TI.

You may want to team up with the other person requesting a solution in this topic, together you can maybe advance quicker. I am not going to provide a detailed code solution here. This is not an easy job.

Thank you for the idea