Config

The application contains a config file (app_config.json) that is located in the config directory of the kidney server. An example of this config file is shown below: 

{
	"log_level" : "info",
    "solver": "coin",
	"log_file" : "kidney_log.txt",
    "templates_dir" : "./templates",
    "constraints_dir" : "./constraints",
    "optimal" : "size:weight"
    "max_ip_run_time_secs": 55,
    "max_heuristic_time_secs": 180,
    "abacus_logging": false,
    "abacus_print_lp": false,
    "pricing_steps": 1,
    "farkas_pricing_steps": 100,
    "max_col_gen_iteration_time": "00:30::00",
    "strong_branching_candidates": 5
    "random_seed_limits": [[200,0],[400,20000]]
    "col_gen_detect": {"coin": 100000, "cplex": 400000}
}

A description of each item follows:

log_level
the level that the logger should output messages at. For the list of possible values see the logging section of this site
solver
the solver to use can be either coin or cplex (default: coin)
log_file
the path where the log file should reside
templates_dir
This is the location where the template files that control how the output is displayed can be found. When the ruby server is run in daemon mode (i.e. -d flag) then this path must be an absolute path. Usually the template files will be located in the root of the install folder. So in the case of running the application in daemon mode and you have installed the kidney server in say "/opt/kidney", this value would read "templates_dir": "/opt/kidney/templates"
constraints_dir
This is the location where the constraint files can be found - that is the lua files that describe the constraints that are available to the system. These will normally be stored in the root of the installation folder and if running the server from the directory this values default setting of ./constraints will suffice. However, like the template_dir option above, if the server is run in daemon mode (-d then the full path must be specified. For example, "templates_dir": "/opt/kidney/constraints", when the application is installed in the /opt/kidney directory
optimal
The optimal setting controls the set of constraints that are enforced when finding the optimal solution - that is, you supplied operation as optimal when making an API call. An example of the value given to the optimal key is shown above, in this example we seek to find the optimal solution where the total number of transplants is first maximised (size option), then subject to this, the total weight is maximised (weight option). A constraint is supplied by giving its short name, this name corresponds to the name of the lua file that holds the constraint. So in the case of size above, we would expect to find a constraint file with the name size.lua in the constraints_dir folder. Note, there is an exception to the rule where the short name corresponds to the lua file name. This happens when the constraint is implemented in C++ and cannot be modified (or represented) using a lua file. At the moment there only exists a single constraint where this is the case. The name of this constraint is quick_effective and this is a constraint that uses a graph theoretic approach to construct a constraint that maximises the number of effective pairwise exchanges - this is a much faster approach than using integer programming to obtain the constraint. If this constraint is used then it must come first in the list of constraints, failing to do so will result in unpredictable behaviour. Should you wish to maximise the number of effective pairwise as the second or greater priority, then you must use the effective constraint. Finally we observe the set of constraints is specified by separating the list of constraints using a colon - as in the example above. The default value for this option is quick_effective:size:pairwise:backarc:weight
max_ip_run_time_secs
the maximum run time in seconds before giving up trying to find a solution. For use with non column generation solvers, has no effect if using column generation. The value of 0 indicates that no time limit will be set.This parameter is for advanced use only.
max_heuristic_time_secs
the maximum time in seconds to allow the primal heuristic to run before giving up and starting the branching process. A value of 0 means do not run the heuristic , and -1 indicates that it should run until the IP has been solved. Default value is 120 seconds. This parameter is for advanced use only
abacus_logging
indicates whether abacus should output its logging information when undertaking column generation. Set to true if you want to observe progress or debug the application. Default is false. This parameter is for advanced use only
abacus_print_lp
if set to true will print out the full lp model every time it runs the lp solver. Default is false
pricing_steps
the number of cycles that should be added on every pricing iteration. Default 100. This parameter is for advanced use only.
farkas_pricing_steps
the number of cycles that should be added at every iteration when we are doing Farkas pricing. Default 100. This parameter is for advanced use only
max_col_gen_iteration_time
string with format "HH:MM:SS" indicating how long we should continue with a column generation iteration before just returning the best solution we have so far. Default "00:30:00". This parameter is for advanced use only
strong_branching_candidates
set to 0 if we don't want to use strong branching otherwise indicates the number of candidates to try when using strong branching. Default 0. This parameter is for advanced use only
random_seed_limits
Any array of values that contains the number of random seeds to apply to an instance of a specific size during column generation. For example, [[200,0],[400, 20000]], indicates that if we have 200 patients then we don't want any random seeds, and if we have between 200 and 400 patients then there should be 20,000 random seeds, anything over 400 patients will lead to 400000 random seeds. Default value [[200,0],[400,1000],[600,10000],[800,100000]]. Advanced use only.
col_gen_detect
this is a json object with key/value pairs indicating after how many cycles with a particular solver we should resort to column generation. For example, {"coin": 100000, "cplex": 400000}, states that if we identify more than 100,000 when using coin then column generation will automatically be used, similarly if we are using cplex and identify more than 400,000 cycles then we should use column generation. A value of -1 for a particular solver states that we should never use column generation, and a value of 0 means always use column generation. Default for this parameter is {"coin": 100000, "cplex": 400000}. Advanced use only.
v1.0.0