Jedox GPU Accelerator Advisor


Related links: Requirements of Jedox GPU Accelerator, Jedox GPU Accelerator Installation, Using the Jedox GPU Accelerator

As of Jedox 7.0, Jedox Excel Add-in provides the GPU Accelerator Advisor. It is a cube-level check for compatibility with Jedox GPU Accelerator and can be started in the Modeler submenu of the Jedox Ribbon.

In the first dialog window you will specify a database and cube of the connected OLAP server for running the check, or you can load the results of a previous GPU Accelerator Advisor instance:

The result of the check is a usage recommendation level (e.g. highly recommended or not recommended) that reflects the expected speedup potential of the Jedox GPU Accelerator on the specified cube. Along with this result, the graphical overview displays the most important cube features that were taken into account for the evaluation, as well as their respective evaluated values:

The sliders show the evaluated values calculated by the Advisor for Cube (% suitability for GPU) and Rules (% supported by GPU) properties. In the bottom panel, the result of the Advisor is displayed below Usage of Accelerator. It can be any of the following:

  • highly recommended (speedup expected)
  • recommended (speedup is likely)
  • candidate (potential for speedup)
  • not recommended (no speedup expected)

The result is represented as a link that leads to an information page providing next steps for custom GPU Accelerator tests in cooperation with Jedox.

Here is a full description of all evaluated parameters, as shown in the screenshot above:


  • data volume: can be low, medium, high, or big, according to cell count
  • cell count: number of filled cells in the cube
  • storage size: expected cube size (in megabytes) in GPU memory
  • string elements: aggregated number of string elements in all dimensions of the cube


  • X of Y are supported: X = number of rules that are supported on GPU Accelerator; Y = number of active rules
  • total coverage: percentage of rule-calculated cells in the cube
  • supported coverage: percentage of GPU-supported rule-calculated cells in the cube
  • cube dependencies: number of cubes that are referenced as data sources in rules in the specified cube
  • show rule by rule evaluation: link to a listing of all active rules with respect to GPU support (see screenshot below)

Description of columns:

  • #: rule position as shown in Rule Editor
  • Definition: rule definition as shown in Rule Editor
  • Rule ID: Rule ID as shown in Rule Editor
  • Support type: GPU engine rule support status. Can be any of the following:
    • supported: the rule can be calculated by the GPU engine.
    • partial: parts of the rule can be calculated by GPU engine.
         Example: [‘2016’, ‘Budget’] = B: [‘2015’, ‘Actual’] with unspecified dimension Month containing string element Comment.
         The rule is supported for all Month elements except the string element. Hence, the support type is partial.
    • unsupported: the rule cannot be calculated by the GPU engine (see Reason below).
  • Reason: If the rule is not fully supported on the GPU, the reason can be any of the following:
    • non-numerical storage: source data of the rule is (in part) non-numeric, e.g. references string type elements.
    • legacy rule: the rule is not compliant with the DDE rule engine, but might be supported in future releases. For more information about legacy rules and DDE, please read the article Rule Engines and Algorithms.
    • rule error: the rule cannot be calculated due to an error. Reasons can be circular references (e.g. [‘2016’] = B: [‘2016’] + 1), invalid database or cube name (e.g. [‘2016’] = B:PALO.DATA(“MissingDB”, “DeletedCube”, …), rule parsing errors, etc.
    • rights check: rule calculation depends on user rights.
    • string constant: rule definition contains string constants (e.g. [‘2017′,’Comment’] = B:”important”).
    • median function: rule involves median calculation.
    • evaluation error: an unexpected error occurred during rule evaluation.

Next steps

Try before you buy! If you are interested in the performance of your model on a state-of-the-art GPU server, please contact us at
If you already host a GPU system, there is good news: as of Jedox 7.0 the use of non-Tesla™ GPUs by NVIDIA is supported for testing purposes (viable support)!

Best practices

Analyzing rule issues

If a rule support result is not obvious at first glance (e.g. rule evaluation error, rule error, or unsupported type) it will be helpful to isolate the rule of interest. Note that dependencies between rules can lead to scenarios in which many rules will have issues if a bottom level rule in the dependency chain has issues.  

R1 = A * B
R2 = R1 * C

If there is a rule error in R1 this will propagate into R2, as R2 operates on results of R1.

In order to isolate a rule, following procedure is recommended:

  • initially deactivate all rules (only active rules are taken into account in the check)
  • iteratively reactivate (blocks of) rules in the order of their dependency level (start from the bottom; R1 in the example above) and restart the check

In the example this would clarify that R1 is not erroneous itself, but only in combination with R2, such that R2 would be the rule of interest.

An already isolated rule can be analyzed in more detail by temporarily removing parts of the rule.
R1 = A * B can be temporarily rewritten as R1 = A, or R1 = B. Restarting the Advisor on the changed rules might give further insights about problematic parts.

Note that in rule constructs involving the CONTINUE() statement lower ordered rules targeting the same area or a subarea will not be listed in the Advisor result.

R1: [‘2018’] = B: IF([‘2017’] > [‘2016’], STET(), CONTINUE())
R2: [‘2018’, ‘Jan’] = B: 100

In this example R2 will not be listed in the Advisor result. Still, if R1 is shown as “supported” this will imply that R2 is supported as well. If R1 is shown as “unsupported” this will imply that any of R1, R2 is unsupported.

It is recommended to disable the highest ordered rule (R1 in the example) and run the Advisor again in order to obtain the support status of lower ordered rules (R2 in the example).

Avoid long running checks

When a cube contains many complex rules (e.g. hundreds of rules with dependencies on other rules) the Advisor check can take several minutes or even hours to complete. If the timeout (default is 5 minutes) is reached the check will stop without a result. In order to obtain complete results the timeout needs to be increased via Dialog options. Status information about a running check can be obtained by viewing the OLAP Server log file which is updated in regular intervals during the check.
Note that the check requires system resources on the server, such that it is not recommended to run the check on servers running low on resources.

In order to approximate the complete results more quickly, following procedure is recommended:

  • initially deactivate all rules (only active rules are taken into account in the check)
  • iteratively reactivate (blocks of) rules in the order of their importance
  • restart the Advisor check in each iteration

Whenever the Advisor check takes more than a few seconds or minutes it is recommended to export the result by clicking the “Save result” button in the result panel. Result exports can be imported/reloaded by clicking the “Load from file” button (next to the “Start” button) in the main panel, if the corresponding connection is available and the cube was not changed since the last Advisor check.

If you want to cancel a running check choose either of the following options:
a) stop the corresponding cube/info job via Jedox Web -> Administration Panel -> Sessions -> select corresponding <User> to list active jobs and stop the job.
b) close Excel (forcefully, if necessary).
Note that closing the loading panel does not stop the active job on the server. Hence, following either a) or b) is vital to free system resources on the server.


Was this post helpful?
NoYes (0 rating, 2 votes)