I have an optimization model. I run it on my computer without any problem. I have the following for loop to assign values to Gurobi parameters:
for paramrow in eachrow(solver_params)
if paramrow.Type == "Integer"
set_optimizer_attribute(Expansion_Model, paramrow.Parameter, Int(paramrow.Value))
else
set_optimizer_attribute(Expansion_Model, paramrow.Parameter, paramrow.Value)
end
end
My colleague recently installed JuMP, Gurobi, etc. in his computer, but can not run due to the following error:
Academic license - for non-commercial use only - expires 2023-08-21
LoadError: MethodError: no method matching set_optimizer_attribute(::Model, ::String15, ::Float64)
Closest candidates are:
set_optimizer_attribute(::Model, ::MathOptInterface.AbstractOptimizerAttribute, ::Any) at C:\Users\admin\.julia\packages\JuMP\bm7X3\src\JuMP.jl:824
set_optimizer_attribute(::Model, ::String, ::Any) at C:\Users\admin\.julia\packages\JuMP\bm7X3\src\JuMP.jl:802
in expression starting at F:\UCSD_File\Sanbox_oct\uced-model\Run.jl:36
I assume this is related to the differences in JuMP versions. My version is 0.21.9. His version is 1.2.0.
Could you please tell me how to modify this for loop to make it work again in his version? Error already gives some suggestions, but I could not figure it out.
Thank you in advance for all your help,
Kind regards
This error would also occur in JuMP 0.21.9 (I can reproduce that error in that version).
I assume that solver_params is a DataFrame, and more recent versions of DataFrames rely on a package called InlineStrings: this is where this String15 type comes from, often from creating a DataFrame by reading a CSV file.
I would guess that since you are using an older version of JuMP, you are also using an older version of DataFrames.jl/CSV.jl that doesn’t yet use InlineStrings.
As Oscar’s work-around showed, you can convert your String15 parameter from your dataframe to a string, by either string interpolation
"$(paramrow.Parameter)"
or by a function
String(paramrow.Parameter)
or you can even give the column types when reading in the DataFrame/CSV explicitly as String.
Do you think it could support String15 (or rather, InlineStrings in general)?
In this case it might “just” be an issue of widening the type signatures accepted by set_optimizer_attribute to AbstractString (I’m using “just” in the loosest possible sense here - I have no insights into the internals of JuMP and the potential implications of this widening). I find that in many of my (data-sciency) workflows InlineStrings are absolutely crucial to ensuring that the GC load brought be regular Strings doesn’t make my sessions unusable, so having them more widely supported would be great.
Also just to clarify a little bit @jd-foster’s comment: DataFrames does not “rely” on InlineStrings, so this is unrelated to DataFrames versions. InlineStrings were an optimization targeted at reducing GC stress in string-heavy workflows introduced into CSV.jl with version 0.9 (iirc). Since then, the default setting is to parse identified string columns into InlineStrings, this can be changed with the stringtype kwarg in CSV.File/CSV.read, i.e. CSV.read("myfile.csv", DataFrame; stringtype = String) will revert to the old behaviour of storing strings as Strings.
You’re right, maybe I should have said “can use” or “is compatible with”. The verbs we usually use don’t always work in the context of abstract types and multiple dispatch.
