Unable to set lower bound to -Inf. To remove the bound, use delete_lower_bound.

[DimaLPorNLP]

Dear all,
This is a common error with Matpower case files. Check for examples this

solve_opf("../matpower/data/case3012wp.m", ACPPowerModel, Ipopt.Optimizer)
ERROR: Unable to set lower bound to -Inf. To remove the bound, use delete_lower_bound.

Is there any solution? Why PowerModels do not replace Inf with the appropriate constant member representing Inf while parsing Matpower files? Is there any other way to import such files with an additional option that is a Matpower file so that the conversion of the Infs takes place only when Matpower cases are parsed?

What is delete_lower_bound ? Is it a function? If yes why isn't it called automatically where it is needed to convert the Inf to PowerModels::Inf ? If it is a function how to call it and at which stage (importing networks data possibly?). If it is not a function that can be called then what does it suggest? To manually open the .m file with a text editor and replace Inf by a big number?

I tried export_matpower of my network_data but unfortunately it seems that it also exports the Inf as well, so when you read the exported case back for solve_opf it, you get the same message. I assumed that an export_matpower function would make internally the necessary conversions so that the exported case is a case that can be solved with PowerModels since there is not an import_matpower which should be the right one for this purpose. I understand that export_matpower is supposed to export a case to a format readable and understandable by Matpower, but due to the fact that there is no import from Matpower which would take care of the necessary conversions, I assumed that the export_matpower is provided for converting pure Matpower cases to PowerModels cases.

Thank you for your time!

[ccoffrin]

The approach to solve this is to first read in the Matpower file with the function parse_file, manipulate the data in Julia to remove the Inf values, and then pass the revised data to solve_opf.

Alternatively, you could use the datasets that are part of PGLib-OPF, where data cleaning procedures like these have already been applied.

The function export_matpower is used to take PowerModels data and export it to a Matpower data file and attempts to replicate it as consistently as possible. So it will preserve Inf values, if they exist.

Also, for the fastest response I suggest posting questions like these to the Julia forms in the Optimization category, https://discourse.julialang.org/c/domain/opt/13

[DimaLPorNLP]

Hi Carleton,
thanks for your quick response, I really appreciate. Well, I have downloaded the PGLib-OPF, but some Matpower cases I have are not there. I was under the impression that a parser (converter) from a Matpower case to a PowerModels case should automatically perform the necessary substitutions on the fly internally since the Matpower issue is standard and well documented. If a parser is doing half the job and it expects the other half to be done by the user, then you cannot call it a parser anymore. So, when you write a parser for Matpower/Matlab files, Matlab is standardized for decades and Inf in Matlab will remain for the next decades to come. So, a parser for Matpower files, since and as long as Matpower is Matlab based, will have to handle Inf and translate it to whatever PowerModels understand as Inf. Then you can call it a PowerModel's parser for Matpower case files.

Finally, I have noticed that some cases in Matpower are not identical to the same cases in PowerModels. Some warnings mention that angles bounds are replaced with [-60, 60] when in Matpower they are defined as [0, 0]. This modifications and other possible ones may lead to different results. Is that right or am I missing something? I already noticed PowerModels with IPOPT/MUMPS converging for the same case twice as fast (in terms of iteration counts) compared with Matpowers (IPOPT/MUMPS) for the exact same case. This is weird and I am wondering if it is due to slightly different flat start or possibly different internal handling of Q allocation in group of generators.

Best wishes!