What's New in 2.0.0¶

The main goal of 2.0.0 is that finding a better dimension order becomes a repeatable, auditable workflow rather than a one-off script run. In 1.x you described a run with command-line flags; in 2.0.0 each cube is described in a JSON file you can keep, share and run again, or you drive the whole thing from a local web UI. This page is the tour; the CHANGELOG is the record.

New to OptimusPy? We'd recommend starting with the User Guide instead, because it walks you through a first run end to end.

New¶

Web UI. Start it with optimuspy ui, or double-click the executable. It opens at http://127.0.0.1:8765 with these pages: Optimize, Reports, Sync Order, Optimize DB and Settings, plus a Jobs list. See the UI Overview.
Modes. optimize benchmarks orders for one cube, in one of four ways: Greedy (with an optional Fast mode), Predefined (orders you list), Position (the best dimension for one slot) and Dimension (the best slot for one dimension). Alongside it, set applies one order without benchmarking, scan lists the cubes worth optimizing, and optimize-db reorders every cube on an instance by leaf-element count within a time limit, benchmarking nothing except the last slot of the cubes you pick.
Several views and TI processes per run. views and processes take lists, and process_parameters sets parameters per process. Each runs executions times, and the median counts, so one slow execution doesn't skew the result. See Multi-View / Multi-Process.
The same greedy search as 1.x. It fills the slots from the outside in, last slot first, and measures every remaining dimension at each one; Fast mode stops after the last and first slots. A run logs how many orders it will measure before it starts, and each progress line reads Iteration k of N. See The Greedy Search.
Dimension position rules. dimension_position_rules keeps a dimension at a fixed position while the rest are tested, and orders_to_ignore skips orders you don't want tested. See Dimension Position Rules.
An HTML report for every run. Summary cards, the recommended order, a chart of memory against query time relative to the original order, a podium with the best order per metric, and the full sortable table. See the Reports Page.
Checkpoint and resume. Run the same optimize command again and it continues where a stopped or failed run left off, including the order that was in flight. --no-resume starts over, and --tm1-checkpoint keeps the checkpoint in TM1's file storage for environments without a persistent disk. See Checkpoints & Resume.
Sync Order and exported orders. The Sync Order page copies storage orders from one instance to another, and can export them to exports/ as JSON configs that optimuspy set applies. See the Sync Order Page and Exporting & Importing Orders.
Settings page. It links the config.ini you already keep for RushTI or your scripts, or copies it into config/config.ini, then shows each instance read-only with Test Connection. The choice is shared with the CLI. See the Settings Page.
A settings file. config/settings.ini remembers the linked config.ini, the UI's port and whether it opens a browser. It's optional; the bundle ships config/settings.ini.example. See Settings File.
TM1 v12 (PAoC / PAaaS) alongside v11. Memory is read through TM1py's Metrics service on both, and the VMM / VMT override only happens on v11, where those settings exist. See VMM / VMT Handling.
-v / --verbose logs the reason each skipped order was refused. See Optimization Logging.
Windows and Linux bundles. Each holds the executable, config/config.ini.example, config/settings.ini.example and the sample cube configs, so nothing needs installing. See Installation.

Changed¶

Command line. The command is now optimuspy <mode> <cube_config.json> (or python -m optimuspy, or python optimuspy.py from a clone), and the 1.x flags are gone. See the CLI Reference.
Where config.ini lives. It's read from the file given with --config, else the file linked on the Settings page, else config/config.ini in the folder you run from (for the bundle, the executable's folder). OptimusPy doesn't edit it, so it can be shared with other TM1py tools. See TM1 Connection.
Where the log is written. logs/optimuspy.log in the install folder: the executable's folder for the bundle, the repository root for a clone. 1.x wrote optimuspy.log in the folder you ran from.
Result files. They go in results/<instance>/, named <instance>_<cube>_<timestamp>, without the view or process in the name. An HTML report is always written, and it replaces the 1.x .png chart.
Python 3.11 or later, installed with pip along with the dependencies (TM1py 2.3.0 or later). matplotlib and seaborn are no longer needed.

Removed¶

Benchmarking every cube with one command. In 1.x, leaving out -c benchmarked every cube that had the given view. 2.0.0 benchmarks one cube per config. To cover a whole instance, use scan --output to write a config for each candidate cube, or run optimize-db, which reorders every cube by leaf count and measures only the last slot of the cubes you pick.

Upgrading from 1.x¶

Install 2.0.0. Unzip the Windows or Linux bundle, or with Python 3.11 or later clone the repository and run pip install -e .. See Installation.
Move config.ini into a config folder. 2.0.0 reads config/config.ini; a config.ini sitting next to the executable is not read. The instance sections keep the same format. To leave the file where it is, pass --config path/to/config.ini.

Turn each command into a JSON cube config. A 1.x command stops with error: unrecognized arguments or invalid choice, exit code 2, before it connects. For example, this 1.x command:

optimuspy.py -i my_instance -c Sales -v Optimus -e 10 -f True -o csv -u True -t load.csv.file -d Time,Version

becomes optimuspy optimize sales.json, where sales.json contains:

{
  "instance": "my_instance",
  "cube": "Sales",
  "views": ["Optimus"],
  "processes": ["load.csv.file"],
  "executions": 10,
  "fast": true,
  "output": "csv",
  "update": true,
  "dimensions_to_exclude": ["Time", "Version"]
}

1.x flag	2.0.0
`-i`, `--instance`	`"instance"`
`-c`, `--cube`	`"cube"`, now required (see Removed)
`-v`, `--view`	`"views"`, a list. On the command line, `-v` now means `--verbose`
`-e`, `--executions`	`"executions"`, now required (1.x defaulted to 15)
`-d`, `--dimensions_to_exclude`	`"dimensions_to_exclude"`, a list instead of a comma-separated string
`-f`, `--fast`	`"fast"`, `true` or `false`
`-o`, `--output`	`"output"`, `"csv"` or `"xlsx"`, now required. On the command line, `--output` is now scan's folder for generated configs
`-u`, `--update`	`"update"` (or `"auto_apply"`)
`-p`, `--password`	Unchanged: `-p` / `--password` on the command line
`-t`, `--process`	`"processes"`, a list

Every field is listed in the JSON Config Reference. 4. Look for results in a folder per instance. Each run writes results/<instance>/<instance>_<cube>_<timestamp>.html, plus a .csv or .xlsx of the same name. See the Reports Page.

Design notes¶

The pages above describe how to use each feature. For the reasoning behind the bigger design decisions (the order frame and the locked slot, the Optimize DB pass, the checkpoint format, position rules, and what changes between v11 and v12), see the Design Notes section.