There are many customizable pieces of code scattered over the `polymake` rules, such as colors or font sizes for visualization, paths and optional settings for external software, and so on. While the default settings corresponds our experience and taste, you don't have to share these with us. And some settings, like the paths, can be done only locally.

In order to make the local customization easier, `polymake` release 2.1 introduced a special user configuration directory ~/.polymake with several files in it. They are automatically created for each `polymake` user and updated after each `polymake` version upgrade. The user configuration files are thought to be edited manually, therefore contain exhaustive comments. The contents of the files must obey the perl syntax rules.

~/.polymake/customize.pl
This file contains copies of all variables declared as customizable in the `polymake` rules. The variable definitions are grouped by applications or modules they are defined in (look for package commands). Within an application section, they are sorted alphabetically by package and variable name.
If you want to change some setting, you simply remove the comment sign in front of the definition line and change the value. The hash arrays are stretched over several lines, so you have to remove comments in the first and last lines too, in order to preserve the valid perl syntax. You don't need to uncomment all hash elements, however, as long as you are happy with their default values.
To revert later to the default setting, you just comment the definition line again.
Some definitions are uncommented from the very beginning, they are executed under condition CONFIGURED. These settings have been made by auto-configuration sections of rule files. They don't have any default values. If you want to change such values, you should remove or at least comment out the preceding line with CONFIGURED condition, otherwise you will definitely loose your changes by the next polymake --reconfigure call.
If you have built `polymake` with multiple architecture support, the auto-configuration steps will be repeated on every platform. Thus for each custom variable set from the auto-configuration section, the customization file will eventually contain several assignments, guarded by different CONFIGURED conditions. The rest custom variables are treated shared for all architectures.
Note that most of the color settings for visualization tasks can be also overrided dynamically, using optional arguments in the visualization method calls. See the overview and the notes to the methods' decoration arguments.
The rulefiles hash arrays defined in this file have special meaning: `polymake` doesn't load the rule files whose names are mapped to 0 there. Normally, it's the auto-configuration sections in the rule files that make these settings. If you want to exclude some rule file despite successful autoconfiguration, you can do it by changing the corresponding 1 to 0 manually.
~/.polymake/prefer.pl
This file contains the preference settings for various competing production rules (such as convex hull algorithms) and visualization engines. Like the customization file, this one is also divided into application-specific sections. The preference settings included in the rule files are repeated here in commented form, signalling that they are already active.
If you want to change some setting, you should just remove the comment sign and edit the label list. You can also add further "prefer" commands, since not all labels defined in the rules occur in this file from the very beginning. The complete list of available labels can be found on the "Preferences" page of the corresponding application.
In this file you can also store other commands and settings which have to be executed immediately after loading the application rules, as well as the locations of your individual rule files and directories. The comments in the foreword contain detailed instructions and examples how to do it.

### Regenerating user configuration files

The files introduced above are created automatically once and then don't change, unless edited by the user. There are ways, however, to enforce `polymake` to regenerate these files; in any case, the changes made manually will be kept.

1. An application is used for the first time. The configuration files contain independent sections for each application. If you have been used only one application the whole time before, and then start to use another one, it will append new sections to the configuration files.
2. The user calls polymake --reconfigure . All settings made under CONFIGURED conditions are removed and recomputed by auto-configuration sections.
3. `polymake` installation is upgraded. The configuration files record the `polymake` version under which they were created. After an upgrade, a version mismatch is detected and the configuration files are rewritten. This allows to fill them with new variables and to get rid of obsolete stuff.
4. the central (system-wide) configuration file is changed. In the `polymake`'s top installation directory there is a short file configured.pl. Initially it is (almost) empty, but the system administrator or whoever else in charge of looking after `polymake` can fill it with new definitions. For example, if some external software was lacking, the corresponding autoconfiguration routines have written the failure flag in the users' configuration files. Later on, you have installed this software; you can either recommend all users to run polymake --reconfigure by themselves, or just do it once for you and copy the new settings into the system configuration file. Then all other users will take over the changes by the next regular `polymake` call.