Hello, thank you for the update!
I ran into an issue with the solver configuration. When I use a configuration file that contains solver=cbc, this setting seems to be ignored, and OptiType tries to use glpsol instead. Since glpsol is not installed on my system, the run fails:
root@3c76f309505c:/outputs# /usr/local/bin/optitype run -c /soft/OptiType-1.5.0/test/test_config.ini -i /input/input_1.fastq.gz -i /input/input_1.fastq.gz --dna -p test1 -o /output/optitype_test1_no_config 2>&1 | tee /output/test1_no_config.log
WARNING: Initializing ordered Set R with a fundamentally unordered data source
(type: set). This WILL potentially lead to nondeterministic behavior in Pyomo
WARNING: Could not locate the 'glpsol' executable, which is required for
solver 'glpk'
Solver does not support multi-threading. Falling back to single-threading.
WARNING: Could not locate the 'glpsol' executable, which is required for
solver 'glpk'
Error: No executable found for solver 'glpk'
I'm using the test configuration file from the repository, which does contain solver=cbc:
root@3c76f309505c:/outputs# grep "solver=cbc" /soft/OptiType-1.5.0/test/test_config.ini
solver=cbc
However, when I explicitly add --solver cbc to the command line, everything works as expected:
root@3c76f309505c:/outputs# /usr/local/bin/optitype run --solver cbc -i /input/input_1.fastq.gz -i /input/input_1.fastq.gz --dna -p test1 -o /output/optitype_test1_solver
WARNING: Initializing ordered Set R with a fundamentally unordered data source
(type: set). This WILL potentially lead to nondeterministic behavior in Pyomo
============================================================
HLA Typing Results
============================================================
HLA-A: A*01:01 (homozygous)
HLA-B: B*08:01, B*57:01
HLA-C: C*06:02, C*07:01
Reads: 1306
Objective: 1282.49
Results written to: /output/optitype_test1_solver/test1_result.tsv
Coverage plot: /output/optitype_test1_solver/test1_coverage_plot.pdf
If --solver is not provided on the command line, OptiType should use the value from config.ini (or the built-in default if the configuration file does not specify one). This is the expected behavior and matches how it worked in v1.3.5
I suspect the issue is related to the following:
- In cli.py, the
--solver option has a hardcoded default value of glpk (link)
- Later in the same file, this value is unconditionally assigned to
pipeline_config.solver = solver (link), overriding any solver setting that was loaded from the configuration file
It's also possible that the same issue affects other configuration options that have command-line defaults.
Thank you for your time and effort!
Hello, thank you for the update!
I ran into an issue with the solver configuration. When I use a configuration file that contains solver=cbc, this setting seems to be ignored, and OptiType tries to use glpsol instead. Since glpsol is not installed on my system, the run fails:
I'm using the test configuration file from the repository, which does contain solver=cbc:
root@3c76f309505c:/outputs# grep "solver=cbc" /soft/OptiType-1.5.0/test/test_config.ini solver=cbcHowever, when I explicitly add
--solver cbcto the command line, everything works as expected:If
--solveris not provided on the command line, OptiType should use the value fromconfig.ini(or the built-in default if the configuration file does not specify one). This is the expected behavior and matches how it worked inv1.3.5I suspect the issue is related to the following:
--solveroption has a hardcoded default value ofglpk(link)pipeline_config.solver = solver(link), overriding any solver setting that was loaded from the configuration fileIt's also possible that the same issue affects other configuration options that have command-line defaults.
Thank you for your time and effort!