Planning Analytics using twice the memory of 10.1

User avatar
paulsimon
MVP
Posts: 808
Joined: Sat Sep 03, 2011 11:10 pm
OLAP Product: TM1
Version: PA 2.0.5
Excel Version: 2016
Contact:

Re: Planning Analytics using twice the memory of 10.1

Post by paulsimon »

Hi qml

We no longer use Cognos BI to query TM1. However, when we did have it doing that in 10.1 we didn't notice any dramatic increase in RAM when the first cube query was run.

This still seems to be a problem that is unique to PA.

I suspect that if 10.1 was generating MUNs when a cube query occrured, that it was only doing it for the dimensions in that cube, and not every single dimension on the server.

Regards

Paul Simon
User avatar
paulsimon
MVP
Posts: 808
Joined: Sat Sep 03, 2011 11:10 pm
OLAP Product: TM1
Version: PA 2.0.5
Excel Version: 2016
Contact:

Re: Planning Analytics using twice the memory of 10.1

Post by paulsimon »

Hi

The attached might help anyone else having problems with an explosion in size due to the generation of all possible MUNs at start up in PA 2.0

It uses the TM1RESTAPI to get a list of all dimensions on the server, with their Element and MUN Count and the Ratio between them. It seems to be the MUN count that is the important thing. The Ratio just indicates cases where the dimension has a lot of alternate hierarchies leading to potentially a lot more MUNs than elements.

Use at your own risk. It only works in TM1 Authentication Mode.

For those of you that don't know, to get the TM1RESTAPI working you have to put HTTPPortNumber= some value eg 8010 in your TM1S.CFG, and that is the Port Number that you need to enter on this sheet. The UseSSL flag just determines whether the call to the TM1RESTAPI needs to use http or https.

Regards

Paul Simon
Attachments
TM1DimElemAndMUNCountLister 003.zip
(33.53 KiB) Downloaded 468 times
User avatar
Steve Rowe
Site Admin
Posts: 2407
Joined: Wed May 14, 2008 4:25 pm
OLAP Product: TM1
Version: TM1 v6,v7,v8,v9,v10,v11+PAW
Excel Version: Nearly all of them

Re: Planning Analytics using twice the memory of 10.1

Post by Steve Rowe »

Thanks to lotsaram and Paul for sharing this, a very interesting read.

If you are impacted by this you could ended up quite blocked.

- Convert dimension to hierarchy based, this may be complex and won't always result in a natural query structure for the user. Plus we do not (yet, when is it coming??) have DBR type reporting that can address hierarchies. Irrespective existing reporting would need updating.
- Potentially switch to a multi- dimension approach (time, one lump or two) which hierarchies really stops us needing to do. Major rebuild.

Will also impact customers who go to "TM1 11", new server build and stay on Perspectives.

Great info to have when designing a system.
Cheers
Technical Director
www.infocat.co.uk
User avatar
Mike Cowie
Site Admin
Posts: 482
Joined: Sun May 11, 2008 7:07 pm
OLAP Product: IBM TM1/PA, SSAS, and more
Version: Anything thru 11.x
Excel Version: 2003 - Office 365
Location: Alabama, USA
Contact:

Re: Planning Analytics using twice the memory of 10.1

Post by Mike Cowie »

Big thanks to Lotsa, Paul and others for this-- has been a really interesting thread. If anyone needs a pre-REST API method of counting MUNs, just create an MDX subset like this and count/SUBSIZ the elements in that dynamic subset:

Code: Select all

GENERATE( TM1SUBSETALL( [Your Dimension Name] ), DESCENDANTS( [Your Dimension Name].CurrentMember ) )
Should match up exactly with the REST API's member/MUN count across the dimensions I'd tested.

Have definitely seen some RAM increases moving to PA Local 2.0.x, especially with daily time and larger dimensions with alternate hierarchies or rollups. I also isolated, in its own server instance, a larger dimension with a single hierarchy (approx. 50,000 elements) which was 1:1 elements to MUNs and saw an increase of around 50% in RAM usage comparing 10.2.0 to 2.0.5. This was one dimension in isolation, so I'm not saying you'll see a 50% jump in RAM if you upgrade-- just that there's clearly a general RAM increase for dimensions going to PA Local 2.0.x regardless of any MUN/Element factor. I didn't see an increase like this from 10.2.0 to 10.2.2.

Last note is that any "Memory Used" values you can see in Perspectives' Properties pane, which were already pretty inaccurate, are now even more useless in 2.0.x. They don't seem to reflect, at all, the impact of what 2.0.x does to precache all the MUNs for a dimension (unfortunately).

Hope that helps!
Mike
Mike Cowie
QueBIT Consulting, LLC

Are you lost without Print Reports in Planning Analytics for Excel (PAfE)? Get it back today, for free, with Print Reports for IBM Planning Analytics for Excel!
User avatar
jim wood
Site Admin
Posts: 3951
Joined: Wed May 14, 2008 1:51 pm
OLAP Product: TM1
Version: PA 2.0.7
Excel Version: Office 365
Location: 37 East 18th Street New York
Contact:

Re: Planning Analytics using twice the memory of 10.1

Post by jim wood »

I do wonder if this memory increase is down to them adding the attribute based hierarchies? I doubt we'd be able to prove it either way, but for me the biggest difference between the 2 versions,

Jim.
Struggling through the quagmire of life to reach the other side of who knows where.
Shop at Amazon
Jimbo PC Builds on YouTube
OS: Mac OS 11 PA Version: 2.0.7
User avatar
paulsimon
MVP
Posts: 808
Joined: Sat Sep 03, 2011 11:10 pm
OLAP Product: TM1
Version: PA 2.0.5
Excel Version: 2016
Contact:

Re: Planning Analytics using twice the memory of 10.1

Post by paulsimon »

Hi

We are still awaiting a response from IBM.

I have trimmed down our Day level dimension which we only use for user logging so that it only has a single hierarchy. This saved around 4GB of the 13GB increase (13.9 to 27.4GB).

The system has been around for 5 years or so and had lots of old unused cubes. I have deleted them and all the related dimensions some of which had highish (10,000+) numbers of elements with lots of alternate hierarchies.

The server is now using 17.2GB. That is still 3.3GB more than it did on 10.1 with the old cubes. I now have to do some further work to cure the problems caused by deleting the old cubes, which I was hoping to avoid until after the upgrade completed.

Obviously the biggest reduction came from stripping out hierarchies from the Day level dimension so thanks to Lotsaram for that. However, we were only able to do this because most of our data is at the monthly level. In a retail environment where sales at Day level are key this is obviously going to be much more of a problem.

Some of the alternate hierarchies in our dimensions that we have are effectively just combining different attributes so you have eg a split by one categorisation of codes within another categorisation of codes. Potentially we could do this by creating the new Hierarchies. However, virtually all of the system is built in TM1 Web and this will not recognise hierarchies. Similarly we have a number of users who use Perspectives via Citrix. This also will not recognise hierarchies. As the client will not pay the license for PAW, that only leaves PAX as a possible client that can recognise Hierarchies. That would require a lot of retraining of users and re-development of the system. It would need to be deployed via Citrix to reach our remote partners.Even then as I understand it, Hierachies can only be used in Exploration Views and Quick Reports which are limited in their formatting cababilities compared to Dynamic Reports, the new name for Active Forms. Therefore, we are still going to need conventional alternate hierarchies in Dimensions, as well as the new Hierarchies. If we are still going to need alternate hierarchies then we are still going to have the problem of the huge increase in size caused by the MUN issue.

It would seem that the obvious thing to do would be to make the generation of all possible MUNs optional, ideally on a Dimension by DImension basis.

Regards

Paul SImon
User avatar
PavoGa
MVP
Posts: 612
Joined: Thu Apr 18, 2013 6:59 pm
OLAP Product: TM1
Version: 10.2.2 FP7, PA2.0.9.1
Excel Version: 2013 PAW
Location: Cleveland, Tennessee

Re: Planning Analytics using twice the memory of 10.1

Post by PavoGa »

Mike Cowie wrote: Mon Aug 06, 2018 4:03 pm Big thanks to Lotsa, Paul and others for this-- has been a really interesting thread. If anyone needs a pre-REST API method of counting MUNs, just create an MDX subset like this and count/SUBSIZ the elements in that dynamic subset:

Code: Select all

GENERATE( TM1SUBSETALL( [Your Dimension Name] ), DESCENDANTS( [Your Dimension Name].CurrentMember ) )
Should match up exactly with the REST API's member/MUN count across the dimensions I'd tested.

Have definitely seen some RAM increases moving to PA Local 2.0.x, especially with daily time and larger dimensions with alternate hierarchies or rollups. I also isolated, in its own server instance, a larger dimension with a single hierarchy (approx. 50,000 elements) which was 1:1 elements to MUNs and saw an increase of around 50% in RAM usage comparing 10.2.0 to 2.0.5. This was one dimension in isolation, so I'm not saying you'll see a 50% jump in RAM if you upgrade-- just that there's clearly a general RAM increase for dimensions going to PA Local 2.0.x regardless of any MUN/Element factor. I didn't see an increase like this from 10.2.0 to 10.2.2.

Last note is that any "Memory Used" values you can see in Perspectives' Properties pane, which were already pretty inaccurate, are now even more useless in 2.0.x. They don't seem to reflect, at all, the impact of what 2.0.x does to precache all the MUNs for a dimension (unfortunately).

Hope that helps!
Mike
Did the same by removing all but three dimensions, two of over 300K members and one with 13K members. The element to MUN ratio is 1:1 on all three dimensions.

To test, restarted the server, opening and closing the subset editor on each dimension starting with the largest, reopening the dimension and running:

Code: Select all

[dimname].members
# (provides the same results as the GENERATE code above)
then closing the dimension again. I took memory readings after each operation.
  • PA2.0 started out using approximately 44% more memory than 10.2.2. (541.6MB vs 783.1)
  • Opening the subset editor on each dim increased the memory usage in both by a few % points. (<3.5%, <1.6%, < 1%)
  • Opening the subset editor and running the MDX statement from above significantly increased the memory usage in 10.2.2, not so much in PA2.0 (10.2 vs PA 2.0 by dim: 19.9% vs 5.3%, 14.1% vs 1.6%, .2% vs .1%)
So there may be merit to the IBM claim 10.2 does the same thing to some extent. The gap in memory usage dropped 55% after opening the 3rd dimension and running the MDX.
Ty
Cleveland, TN
User avatar
jim wood
Site Admin
Posts: 3951
Joined: Wed May 14, 2008 1:51 pm
OLAP Product: TM1
Version: PA 2.0.7
Excel Version: Office 365
Location: 37 East 18th Street New York
Contact:

Re: Planning Analytics using twice the memory of 10.1

Post by jim wood »

This goes back to the point I raised earlier regarding attribute based alternate hierarchies. Performance would be hit if the dimension had run in memory before the alt hierarchy, if it was already it would be an advantage. You could also argue it would have initial performance updates after restart. Has anybody tracked the memory usage impact of running an update to the dimension in both? When updating the dimension does PA then fully recompile again? Does this have an impact on dimension update times in TI?
Struggling through the quagmire of life to reach the other side of who knows where.
Shop at Amazon
Jimbo PC Builds on YouTube
OS: Mac OS 11 PA Version: 2.0.7
lotsaram
MVP
Posts: 3648
Joined: Fri Mar 13, 2009 11:14 am
OLAP Product: TableManager1
Version: PA 2.0.x
Excel Version: Office 365
Location: Switzerland

Re: Planning Analytics using twice the memory of 10.1

Post by lotsaram »

jim wood wrote: Thu Aug 09, 2018 5:13 pm This goes back to the point I raised earlier regarding attribute based alternate hierarchies. Performance would be hit if the dimension had run in memory before the alt hierarchy, if it was already it would be an advantage. You could also argue it would have initial performance updates after restart. Has anybody tracked the memory usage impact of running an update to the dimension in both? When updating the dimension does PA then fully recompile again? Does this have an impact on dimension update times in TI?
The attribute based hierarchies aren't dynamic. Although yes there is a single function to build an attribute based hierarchy this just builds the hierarchy at a point in time. If attribute values subsequently change, or new leaf elements are added to the dimension this won't impact the hierarchy. (and in fact the last time I tested it the function actually fails if the hierarchy already exists; you need to destroy and then recreate it). Therefore in a production system you would never actually use this feature as is, rather you would use standard hierarchy functions to build and maintain attribute based hierarchies. Then you can control things like the hierarchy name, the number of levels, what to do with blank attribute values, unwinding vs. rebuilding, etc. All of which you can't do using the automatically generated attribute hierarchies.
Please place all requests for help in a public thread. I will not answer PMs requesting assistance.
User avatar
paulsimon
MVP
Posts: 808
Joined: Sat Sep 03, 2011 11:10 pm
OLAP Product: TM1
Version: PA 2.0.5
Excel Version: 2016
Contact:

Re: Planning Analytics using twice the memory of 10.1

Post by paulsimon »

Hi

An update on this.

Still no response from IBM Support or Development :(

I reduced memory requirements by cleaning up all old cubes. This is something that we were going to do anyway, but ideally the other side of the upgrade. I now need to do more testing to ensure that removing references to old cubes has not upset anything.

I also removed all but the bare minimum of hierarchy from the Day level dimension.

This got the memory down to a more reasonable 17GB but still around 4GB more than the 10.1 Server needed with all those old cubes and a fully functional Day level dimension.

That then got us to the point where the TM1 Service would at least start. However, as soon as we put any serious activity through it, ie our typical overnight dim builds and loads, then

On Windows Server 2016 the TM1 Service crashed so badly that it actually took out the Remote Desktop capability of the Server. It was some time before we worked out that the Server was still up but you just could not connect to it.

On Windows Server 2008 the TM1 Service was failing at random points saying that it was unable to write to disk even though there was several GB of free disk space. In some cases it was failing trying to write .vue$ files, in other cases .sub$ files, and in some cases the tm1s.log.

We eventually found a post on the IBM Website which said that random write failures can be caused by the TM1S.CFG setting

LockPagesInMemory=T

In theory this setting is supposed to improve performance by stopping Windows from paging out virtual memory pages to disk when the TM1 Server is idle. In a typical scenario the TM1 Service is idle for some time until someone comes along with a query, so it seemed like a good idea to set this. The description of this TM1S.CFG parameter recommends that it should be set on all Windows 64 bit servers. However, the advice we eventually found on the IBM Support site is that if you encounter random errors writing to disk that you should set this to False. There was no explanation as to why a setting related to virtual memory management should prevent normal files being written to disk. There was no explanation of the likely impact of being unable to use a recommended setting. Anyway changing the setting does seem to have cured the problem.

It would be nice if, having found this problem, IBM had thought to change the documentation on this TM1S.CFG setting said don't ever set this to True, since it doesn't work properly and will cause your server to crash.

I don't think that this File Write Error is related to the original problem of the TM1 Service using far more RAM than before. We did run tests with a minimal CFG and the default if this parameter is missing is False.

Regards

Paul Simon
User avatar
paulsimon
MVP
Posts: 808
Joined: Sat Sep 03, 2011 11:10 pm
OLAP Product: TM1
Version: PA 2.0.5
Excel Version: 2016
Contact:

Re: Planning Analytics using twice the memory of 10.1

Post by paulsimon »

Hi

Just to let you know IBM Support have now reproduced the considerable increase in memory that we were seeing when upgrading from 10.1.1 to PA 2.0.5 and have referred this to Engineering for some sort of improvement.

Regards

Paul Simon
Paul Segal
Community Contributor
Posts: 306
Joined: Mon May 12, 2008 8:11 am
OLAP Product: TM1
Version: TM1 11 and up
Excel Version: Too many to count

Re: Planning Analytics using twice the memory of 10.1

Post by Paul Segal »

Good work Paul, I know how much effort it takes to get IBM to this stage. FWIW, I believe we're seeing similar memory issues.

Regards
Paul
User avatar
paulsimon
MVP
Posts: 808
Joined: Sat Sep 03, 2011 11:10 pm
OLAP Product: TM1
Version: PA 2.0.5
Excel Version: 2016
Contact:

Re: Planning Analytics using twice the memory of 10.1

Post by paulsimon »

Hi Paul

It is likely to be some time before IBM provide a solution. It might be quicker for you to change your design to reduce the number of alternate hierarchies and remove any old cubes, etc, to cut down on memory requirements.

We have encountered several issues when upgrading to PA. I will post them when I get more time, along with the workarounds that we used. I have certainly been writing a lot of VBA recently to fix workbooks, etc.

Regards

Paul Simon
Bakkone
Posts: 119
Joined: Mon Oct 27, 2014 10:50 am
OLAP Product: TM1
Version: 10.2.2
Excel Version: 2013

Re: Planning Analytics using twice the memory of 10.1

Post by Bakkone »

Did anyone hear anything from IBM on this one?
User avatar
paulsimon
MVP
Posts: 808
Joined: Sat Sep 03, 2011 11:10 pm
OLAP Product: TM1
Version: PA 2.0.5
Excel Version: 2016
Contact:

Re: Planning Analytics using twice the memory of 10.1

Post by paulsimon »

Hi Bakkone

Serveral months after we raised the PMR, IBM finally confirmed that PA will use far more memory than 10.1 and even 10.2, and that is related to the MDX MUN issue described above. They see this as a feature rather than a bug so they are not going to make any changes or provide any CFG settings to turn this off.

If you are having memory issues while testing the upgrade, your only option is either buy more memory and/or to redesign your application. We removed any redundant cubes (which we were planning to do anyway, just not in such short timescales). The main change needed is to limit the use of deeply nested hierarchies, which we were able to do since only one cube needed a day level hierarchy and it did not need all the alternate hierarchies. However, this may be much more of a problem for other users depending on their application.

We are now on 2.0.5

The IBM help desk seemed unaware of the double your memory issue. We wasted weeks before I finally got this information from Lotsaram and worked out how to cure the problem.

Other issues we encountered during the upgrade:

a) Change to TM1 Web URL API. This required a complete redesign of the system as the original BI front end made heavy use of this. I kind of thought that APIs were designed to insulate you from changes to the underlying architecture. For example, why someone decided that row numbers should start at 0 instead of 1 I don't know. Excel definitely starts at 1.
b) Documentation on set up of web authentication, certificates, etc, is inaccurate and insufficient. This needed several calls to the IBM help desk to resolve and at times they refused to send us the steps and would only read them out over the phone. I do not understand why steps needed to get the product to work should be considered secret. We do have a more complex setup than most companies but it took months of to and fro with IBM before we eventually got it working. There are still issues preventing PAX from working. However, for the moment we just needed to get the existing Perspectives and TM1 Web facilities working. We do now have a license for PAW and will be exploring that at some point.
c) The Action button and XLS conversion does not work properly and does things to the sheets other than just change the Action button. Some sheets had to be converted manually
d) Text in TM1 Web Cube Viewer is right aligned. This is apparently fixed in 2.0.6 which we are installing at the moment.
e) Buttons such as the +/- in TM1 Web hierarchies are grey and proved too difficult for many users to see. We ended up editing the CSS to change just about everything in TM1 Web back to black.
f) We still have an outstanding issue where TM1 Web is creating multiple CAM logins. In theory this can be solved by a different approach using Session tokens but there is no documentation on doing this. We have an outstanding PMR with IBM on this.
g) Ops Console proved too slow so we have reverted to TM1 Top.
h) TM1 Web ran out of memory so had to upgrade the server - now on 12GB
i) We used a technique to DBS in the last selection so that sheets always open showing the user's last selection. We typically hide all working columns to the left of the main area of the sheet. The DBS stopped working in TM1 Web. To work around this, instead of hiding the column, we have to make it a very thin column width. That needed changes to our macros and macros to update the existing sheets. When you make a column very thin, you need to also right align the text in it to prevent it bleeding over into the cells to the right.
j) Various formatting issues requiring editing of the sheets
k) We had made use of advanced properties in Action buttons. The use of Named Ranges does not work, so we had to change the buttons to hard-code parameters.
l) Lack of clarity on whether TM1 Web is still supported. Still not had anything in writing from IBM to confirm that it is, only verbal assurances.
m) Undo button in TM1 Web causes locking on the server. This was a problem we noticed in 10.1 that has still not been fixed. We removed the Undo changes button altogether by amending the CSS.
n) Certain sheets seem to be causing the IBM Websphere Liberty Web Server to max out the CPU so that no one can even login. This happens on sheets that worked fine in 10.1 but are causing problems in PA. However, there is nothing in the logs to tell you which sheet it is processing at the time this happened. There is an outstanding PMR with IBM for this.

There were probably other problems that I have forgotten to list above.

This was the longest and most painful upgrade I have undertaken. We have fed this back to IBM at fairly senior levels. We are now running with PA 2.0.5 in production having gone live 2 months ago. We are still encountering some issues of which the Liberty Web Server maxing out the CPU is currently the most serious.

Regards

Paul Simon
User avatar
paulsimon
MVP
Posts: 808
Joined: Sat Sep 03, 2011 11:10 pm
OLAP Product: TM1
Version: PA 2.0.5
Excel Version: 2016
Contact:

Re: Planning Analytics using twice the memory of 10.1

Post by paulsimon »

Hi

Another issue was that in 10.1 the TI function ProcessError behaved no differently to ProcessQuit. However, in PA, a ProcessError means that no data gets saved. Therefore the error message from the TI that we were writing to a cube so that the web sheet could retrieve it and show it to the user in the error message part of the TI button, no longer worked. Unfortunately we had used ProcessError in the error handling code in the Epilog of our processes. Once we had identified the problem, running a global replace of ProcessError for ProcessQuit which did not cause this issue resolved the problem.

We also found that rules in }CellSecurity cubes were creating much more of an overhead in PA than they did in 10.1. We therefore spent some time revising our security scheme to use Cube or Element Security wherever possible and TI in other places. We also used the new facility to create }CellSecurity cubes with fewer dimensions than the main cube. This probably helped the remaining }CellSecurity cubes where rules were the only feasible answer to introduce less of an overhead.

Having said quite a lot of negative things about the upgrade it is probably good to say some positive things

Most of the problems we had in getting support were exacerbated by our IBM account manager going AWOL for 6 months so we had no escalation route. We now have a new IBM account manager who is being a lot more proactive.

Apart from the times when something in a web sheet trips up the Liberty Web Server, and makes it use 100% CPU for nothing, the general performance of TM1 Web is much better, although as we skipped 10.2 which is when the main ASPX to Java re-write took place, I cannot say whether it is better than 10.2.

We have converted most of our processes to use Temp Views and Subsets. These have brought about a dramatic reduction in locking and have improved response times. When I checked the TM1Top logs from the busiest day of month end, for post upgrade but pre temp views, vs post temp views, the incidents where a user was in a wait state for more than 5 seconds went down from over a 1000 to under 40.

The only remaining area that we are having to address separately is where previous consultants used the Bedrock View Create function in some older processes. Fortunately these processes are only used twice a year for Financial Accounts and did not feature on the Management Accounts Month End. The problem is that, as the view is created in the called Bedrock process, if it is a temporary view, it is not available to the process that called it. We are therefore manually replacing the calls to Bedrock ViewCreate with standard TI ViewCreate statements. We are also taking the opportunity to introduce permanent subsets for things like all base level elements rather than the original design which used Bedrock to create the subset each time.

We have experimented with the RestAPI and have some good results, but it is early days yet.

Regards

Paul Simon
User avatar
ykud
MVP
Posts: 147
Joined: Sat Jan 10, 2009 10:52 am
Contact:

Re: Planning Analytics using twice the memory of 10.1

Post by ykud »

paulsimon wrote: Tue Jan 22, 2019 7:01 pm
d) Text in TM1 Web Cube Viewer is right aligned. This is apparently fixed in 2.0.6 which we are installing at the moment.
I fixed text alignment with a CSS change in flat.css as well as changing the number font to be Helvetica instead of Helvetica Neue, can't for the life of me understand why would anybody be happy with numbers being unaligned.
User avatar
paulsimon
MVP
Posts: 808
Joined: Sat Sep 03, 2011 11:10 pm
OLAP Product: TM1
Version: PA 2.0.5
Excel Version: 2016
Contact:

Re: Planning Analytics using twice the memory of 10.1

Post by paulsimon »

Hi ykud

Can you remember exactly which style you changed in flat.css. The only one that we could find changed the numbers as well as text to left aligned. We obviously want to keep the numbers right aligned and just get the text to left align, so we are looking for a CSS Style that particularly applies to a cell containing text rather than a cell in general.

Regards

Paul Simon
User avatar
ykud
MVP
Posts: 147
Joined: Sat Jan 10, 2009 10:52 am
Contact:

Re: Planning Analytics using twice the memory of 10.1

Post by ykud »

Hi Paul,

Sure, here you go:
Changes I've done to flat.css in TM1Web:
1) Removing Helvetica Neue as default font to align numbers and increasing size
new:
tm1webDataCell{font-size: 10pt; font-family: Helvetica,Arial,sans-serif;
old:
tm1webDataCell{font-size: 8pt; font-family: Helvetica Neue,Helvetica,Arial,sans-serif;

2) Left aligning text cells:
new
.tm1webTextCell{text-align: left !important;}

GIve it a go, should work for you as well.

Cheers,
Yuri
User avatar
paulsimon
MVP
Posts: 808
Joined: Sat Sep 03, 2011 11:10 pm
OLAP Product: TM1
Version: PA 2.0.5
Excel Version: 2016
Contact:

Re: Planning Analytics using twice the memory of 10.1

Post by paulsimon »

Hi ykud

Thanks - text in the TM1 Web Cube Viewer is now left aligned. You have done a better job than the IBM Support Desk

Regards

Paul Simon
Post Reply