Variable name with space in solution file
I noticed that solution files with variables that include space character are read incorrectly with SCIPreadSol.
Example code to reproduce.
#include <scip/scip.h>
#include <scip/scipdefplugins.h>
using namespace std;
int
main(
int args,
char ** argv
)
{
SCIP* scip = NULL;
SCIP_CALL( SCIPcreate(&scip) );
SCIP_CALL( SCIPincludeDefaultPlugins(scip) );
SCIP_CALL( SCIPcreateProb(scip, "test", NULL, NULL, NULL, NULL, NULL, NULL, NULL) );
SCIP_CALL( SCIPsetObjsense(scip, SCIP_OBJSENSE_MAXIMIZE) );
SCIP_VAR* var;
std::string var_name = "x 1";
SCIP_CALL( SCIPcreateVar(scip, & var, var_name.c_str(), 0.0, 1.0, 1.0, SCIP_VARTYPE_BINARY, TRUE, FALSE, NULL, NULL, NULL, NULL, NULL) );
SCIP_CALL( SCIPaddVar(scip, var) );
SCIP_CALL( SCIPsolve(scip) );
FILE * file;
if ((file = fopen("Solution.sol", "w")) != nullptr)
{
SCIP_CALL( SCIPprintBestSol(scip, file, FALSE) );
}
SCIP_CALL( SCIPfreeReoptSolve( scip ) );
SCIP_CALL( SCIPreadSol(scip, "Solution.sol") );
return EXIT_SUCCESS;
}
Output when trying to read the generated Solution.sol:
unknown variable <x> in line 2 of solution file <Solution.sol>
(further unknown variables are ignored)
Solution read correctly, variable names should just not contain whitespaces because they are required as delimiters.
If one reads each line of the solu file from the end (check for the optional (obj:...), then the solution value), one could support spaces in variable names.
Sounds dangerous if there is a comment behind containing (obj:...). So we never know which of the (obj:...) are part of a variable name. And LP files would still be corrupted by those variables.
One could try the "dangerous" way only if reading it the sane way failed. Implementing this would be labeled with ~students if this existed here.
But I don't mind if the resolution here is a no can do.
I just believe that supporting whitespaces goes along with a lot of painful code, which will not resolve that standard file formats do not support them. One could also think about automatically replacing whitespaces by underscores while checking that there are no name clashes. But this can also lead to confusion so properly unsupporting those names by rejecting them at creation still seems best.