Understanding the opencog.conf file
The /lib/opencog.conf is loaded by default when you start the cogserver. For development purposes, that is when running from the build directory without installing, /lib/development.conf file is prefered. There might be other additional sections or some of the sections below may be missing depending on the type of configuration file being used.
The long-term plan is to avoid the use of the configuration file, and possibly remove it completely, one day. Maybe. Configuration files have multiple problems:
- The are ignored, if you don't run the CogServer, and many important subsystems in OpenCog do not use the CogServer.
- The configuration file can only be loaded once, on cogserver startup; there is no way to reload it.
- There is no way to change the values of configured parameters. For example, one might want to change, during run-time, most or all of the ECAN parameters below. One might be able to do this by providing scheme or python bindings for them. Putting them in the config file means that you have to stop everything to change them. Sometimes, this is inconvenient. More often, this is a fatal design flaw.
- The config file is a key-value store. The AtomSpace is a key-value store. Do we really need two different types of key-value stores?
Thus, for this reason, system developers are strongly discouraged from adding new config parameters. If you've got a parameter, write a scheme or python API for it.
More generally, OpenCog has an unsolved system management problem. We want to provide users with some way of starting and stopping various different subsystems, possibly on a distributed network of machines. We want to be able to easily find and load the correct dataset or datasets (the "memories" and "knowledge" of the system), to checkpoint the system, in case it crashes, and to save partial or final results. We want to manage the configuration of the system. We want to allow the user to make sure that the appropriate systems are not starved for CPU time, and to monitor overall system performance. Finally, large parts of this need to be automated and automatable, so that the attention allocation subsystem can control overall resource scheduling. The config file is one small piece of this more general problem: a need for managing and controlling the system.
The default contents are as follows:
- The section below specifies the default port that the Cogserver will be running on and where it will write log entries to.
# # This file provides an example configuration for a production OpenCog # server. Particularly noteworthy is the list of automatically loaded # modules. # SERVER_PORT = 17001 LOG_FILE = /tmp/cogserver.log
- The logging section allows you to change the granularity of logging. You will be using the 5 variations here when you write logging code. For most purposes, 'debug' or 'info' should suffice. You can use SERVER_CYCLE_DURATION to give agents more time to complete their work. The IDLE_CYCLES_PER_TICK setting is used to change the frequency with which an agent's Run() function is called.
# Other possible log levels are "error", "warn", "info", "debug" and "fine" # LOG_LEVEL = debug LOG_LEVEL = info LOG_TO_STDOUT = false SERVER_CYCLE_DURATION = 100 IDLE_CYCLES_PER_TICK = 3
- Command prompt settings
# Use the commented PROMPT instead if telnet/terminal doesn't support ANSI PROMPT = "opencog> " # Prompt with ANSI color codes ANSI_PROMPT = "�[0;32mopencog�[1;32m> �[0m" # Global option so that modules know whether they should output ANSI color # codes ANSI_ENABLED = true
- This section loads a number of modules which add extra features to the OpenCog shell environment. If you find that the command list that is shown from the Opencog shell when you type 'help' is shorter than normal you may have commented some of them out.
# Cogserver in OSX will automatically change .so extension to .dylib # if .so exists. MODULES = opencog/cogserver/server/libbuiltinreqs.so, opencog/cogserver/shell/libscheme-shell.so, opencog/cogserver/shell/libpy-shell.so
- The following are the settings for economic attention allocation(ECAN). This is used to distribute attention (processor time) between the various agents that may be running simultaneously.
# Economic Attention Allocation parameters STARTING_STI_FUNDS = 10000 STARTING_LTI_FUNDS = 10000 STI_FUNDS_BUFFER = 10000 LTI_FUNDS_BUFFER = 10000 MIN_STI = -400 ECAN_MAX_ATOM_STI_RENT = 15 ECAN_STARTING_ATOM_STI_RENT = 10 ECAN_STARTING_ATOM_LTI_RENT = 0 ECAN_STARTING_ATOM_STI_WAGE = 2 ECAN_STARTING_ATOM_LTI_WAGE = 2 #Used by ImportanceDiffusionAgent class #0 => flat rent, 1 => exp rent, 2 => log rent, 3 => linear rent ECAN_RENT_TYPE = 0 ECAN_RENT_AMNESTY = 5 ECAN_RENT_EQUATION_PARAMETER_0 = 0.05 ECAN_RENT_EQUATION_PARAMETER_1 = 0.0 #End of ImportanceDiffusionAgent class #Used by SimpleImportanceDiffusionAgent class #Maximum percentage of STI that is spread from an atom ECAN_MAX_SPREAD_PERCENTAGE = 0.6 # If false, will diffuse along hebbian links only. If true, # will also diffuse to all non-hebbian incident atoms in the # incoming and outgoing sets ECAN_SPREAD_HEBBIAN_ONLY = false # Maximum percentage that will be available for diffusion to hebbian links HEBBIAN_MAX_ALLOCATION_PERCENTAGE = 0.5 ECAN_CONVERT_LINKS = false ECAN_CONVERSION_THRESHOLD = 15 # spread deciding function type (HPERBOLIC = 0 and STEP = 1 ) SPREAD_DECIDER_TYPE = 1 #END of SimpleImportanceDiffusionAgent params #ForgettingAgent params ECAN_FORGET_PERCENTAGE = 0.001 #END of Economic Attention Allocation parameters
- The rest of the section deals with various configurations for different modules.
# # The sense-similarity tables hold precomputed values or the similarity # of word WordNet-3.0 senses. These tables are referenced in # nlp/wsd/SenseSimilaritySQL.cc These will *eventually* be replaced by # a persistent opencog table of sense similarities. For now, they remain # in use. # SENSE_SIMILARITY_DB_NAME = "lexat" SENSE_SIMILARITY_DB_USERNAME = "linas" SENSE_SIMILARITY_DB_PASSWD = "asdf" # Parameters for ZeroMQ AtomSpace Event Publisher ZMQ_EVENT_USE_PUBLIC_IP = TRUE ZMQ_EVENT_PORT = 5563 # Parameters for RuleEngine # RULE_ENGINE_TRIGGERED_ON = [1 ,2 ,3] # 1-when atom added 2-when atom enters to AF 3-both on 1 and 2 RULE_ENGINE_TRIGGERED_ON = 1