38

Я использую CPLEX для решения огромных оптимизационных моделей (более 100 тыс. Переменных), теперь я хотел бы узнать, могу ли я найти альтернативу с открытым исходным кодом, я решаю смешанные целочисленные проблемы (MILP) и CPLEX отлично работает, но это очень дорого, если мы хотим масштабироваться, поэтому мне действительно нужно найти альтернативу или начать писать нашу собственную специальную библиотеку оптимизации (что будет болезненно)Лучший оптимизатор оптимизации с открытым исходным кодом с открытым исходным кодом

Любые предложения/идеи были бы очень полезны

+0

100k переменные - очень большая проблема! Я думаю, что вы можете сосредоточиться на исследовании большего количества времени при изменении моделирования. Lpsolve и glpk не поддерживают такое количество целых переменных, которые должны быть разрешены в разумные сроки. – 2012-11-18 17:03:34

ответ

16

Я лично нашел GLPK лучше (т.е. быстрее), чем lp_solve. Он поддерживает различные форматы файлов, а дополнительным преимуществом является его интерфейс библиотеки, который обеспечивает плавную интеграцию с вашим приложением.

8

Я рекомендую проверить проект COIN. COIN OR

Много хороших решателей здесь, в том числе ipOPT для нелинейных задач и пара смешанных целочисленных решателей, а также.

2

100k переменные - большая проблема. Многие из библиотек с открытым исходным кодом не очень хорошо работают с множеством переменных. Из того, что я прочитал, lp_solve проверен только на 30k переменных. Использование коммерческой системы может быть вашим единственным выбором.

15

Еще один индоссамент для COIN-OR. Мы обнаружили, что компонент линейного оптимизатора (Clp) был очень сильным, и смешанный целочисленный компонент (Cbc) можно было хорошо настроить с некоторым анализом. Мы сравнили с LP-Solve и GLPK.

Для действительно сложных проблем коммерческий решатель - это путь.

0

Не открытый исходный код, но если у вас есть лицензия Microsoft Academic Alliance, включена корпоративная версия Microsoft Solver Foundation (MSF). Gurobi также свободен для академических целей, я использовал его в своем диссертационном исследовании.

+0

Этот продукт - конец срока службы. –

6

Scip - не плохо!

+1

+1 Сцена действительно хорошая. :) – Ali

+0

SCIP не является открытым исходным кодом. – Nubok

12

Попробуйте решение SCIP. Я использовал его для проблем MILP с более чем 300K переменными с хорошей производительностью. Его производительность MILP намного лучше, чем GLPK. Gurobi также имеет отличную производительность для проблем MILP (и обычно лучше, чем SCIP (май 2011 г.)), но это может быть дорогостоящим, если вы не являетесь академическим пользователем. Gurobi будет использовать multicores для ускорения решателя.

+3

SCIP, к сожалению, не является программным обеспечением с открытым исходным кодом. –

+1

У вас действительно было более 300 тыс. Переменных? Сколько из них имеет целые ограничения? – ldog

7

Если бы я был вами, я бы попытался использовать интерфейс с несколькими решателями, такой как Osi (C++) или PuLP (python), чтобы вы могли написать свой код один раз и протестировать его со многими решателями.

Если целые программы, которые вы собираетесь решить, огромны, я бы порекомендовал python над C++, потому что ваш код будет выглядеть чище, и 99% времени будет потрачено на решателя.

Если, наоборот, проблемы малы, то время для копирования проблемы из памяти питона в решатель (туда и обратно) не будет пренебрегают: в этом случае вы можете экспериментировать с некоторыми замечательными улучшениями производительности, используя скомпилированный язык.

Но если проблемы в подавляющем большинстве огромны, то скомпилированные языки собираются снова выиграть, так как объем памяти будет примерно разделен на 2 (без копирования проблемы на питоне).

+0

Я ранее использовал lp_solve, затем переключился на использование целлюлозы. По умолчанию используется COIN-OR. Чтобы решить проблему MIP, у меня было, с 200 переменными решения, lp_solve заняло 55 минут, GLPK взял и 67мин, Coin - или занял 0.2 секунды. – Ant6n

+0

Простите за возрождение, но является ли память незаменимой для всех реализаций решателя? (например, даже с коммерческим решателем, подобным Gurobi?) Это было бы огромным недостатком использования python. – ashgetstazered

+0

Я так считаю. Все реализации python действуют как обертки вокруг библиотеки C. Поэтому для каждой переменной вы получаете переменную python, которая указывает на значение C = в два раза больше необходимой памяти. Это верно для любого языка-обертки, поэтому вы получите ту же самую проблему с C++. Если вы хотите минимизировать используемую память, вам нужно использовать plain C и построить там матрицу проблем. Я бы не стал беспокоиться об этом слишком много: производительность, получаемая от использования хорошей абстракции, позволит вам испытать еще много вещей и привести к лучшей реализации. Прибегайте только к чистому C, если у вас нет выбора – user48678

6

Хотя, возможно, это не то, что вы хотите услышать, но между коммерческими решателями CPLEX и Gurobi, с одной стороны, и с открытым исходным кодом, с другой стороны, существуют светлые годы.

Тем не менее вам может быть повезло, и ваша модель отлично работает с GLPK, монетой и т. П., Но в целом решения с открытым исходным кодом идут за коммерческими решателями. Если бы все было иначе, никто бы не заплатил 12 000 $ за лицензию Gurobi и даже больше за лицензию CPLEX.

В последние годы я видел много, много моделей, которые были просто трудными для решателей с открытым исходным кодом. Поверьте мне ...

Это не столько размер, сколько числовые трудности.

+0

Можете ли вы рассказать что-то еще о том, какие типы моделей слишком сложны для решателей с открытым исходным кодом? –

+1

Мы работаем, например, с моделями для газовой промышленности и газораспределения, а также были десятки моделей, которые были слишком сложными для разработчиков с открытым исходным кодом. Обычно модели LP не являются большой проблемой, но когда речь идет о моделях MIP, только коммерческие решатели преуспевают. Обычно наши модели имели несколько десятков тысяч переменных. Но дело не столько в размерах. – Knasterbax

+1

Я не обязательно не согласен с вашим комментарием, но есть случаи, когда разработчики openource работают так же хорошо, как и коммерческие. Вот почему я рекомендую обращаться к библиотекам с несколькими решателями. Таким образом, вы сможете обрабатывать решателя как движок и легко переключаться с решателем и сравнивать даже между коммерческими решателями. Не запирайтесь на технологии и не используйте общие рамки! – user48678

2

Я использовал DICOPT с помощью сервера NEOS (http://www.neos-server.org/neos/solvers/minco:DICOPT/GAMS.html) для решения больших (приблизительно 1k переменных и 1k ограничений) смешанных целочисленных нелинейных программ и нашел отличным.

Для моей проблемы DICOPT сделали гораздо лучше, чем другие MINLP решателей, перечисленных на сервере ОСЗ BARON/KNITRO/LINDO/SBB и т.д.

Есть определенные ограничения для предоставления рабочих мест ОСЗ, и это немного громоздким но свободный доступ к мощному коммерческому решателю более чем компенсирует его.

0

Я добавлю следующие к уже отличным ответам.

Хотя, как указывали другие, коммерческие решатели намного быстрее и эффективнее, чем свободные альтернативы, важно подумать о том, какую часть оптимального разрыва вы можете принять. Для больших проблем со многими целыми переменными вы можете получить гораздо более быстрое решение, если вы можете принять 1% или даже больший разрыв в оптимальности (значения по умолчанию составляют около 0,01% или меньше).

Конечно, если вы решаете проблему, когда 1% переводится в миллионы долларов, это неприемлемо - следовательно, рынок для первоклассных решателей. (Некоторые сравнения Gurobi с бесплатными решателями here)

Я согласен с другими, что использование платформы, которая генерирует независимые от проблемы файлы проблем (такие как * .mps, * .lp-файлы), стоит того, другие решатели. Я использую PuLP и нахожу его, и бесплатный решатель COIN_CBC, отлично. Хотя они ограничены для проблем со многими целыми переменными.

0

Я удивлен, что никто не упомянул MIPCL (http://www.mipcl-cpp.appspot.com/index.html). Он является открытым исходным кодом по лицензии LGPL (источник: http://www.mipcl-cpp.appspot.com/licence.html), что также подходит для использования в приложениях с открытым исходным кодом.

Hans Mittelmann совсем недавно (10 сентября 2017) сделал целочисленного линейного программирования Benchmark: http://plato.asu.edu/ftp/milpc.html (вы также можете быть заинтересованы в поиске на главной странице http://plato.asu.edu/bench.html или слайды его разговора: http://plato.asu.edu/talks/informs2017.pdf).

В смешанном целочисленном линейном программировании Бенчмарк с 12 потоками и лимит времени в 2 часа MIPCL удалось решить 79 экземпляров. Только коммерческие решатели CPLEX, Gurobi и XPRESS смогли решить больше по заданным ограничениям (соответственно 86 или 87 экземпляров).

Также с точки зрения выбранной метрики производительности (опять же, используя 12 потоков) MIPCL быстрее, чем тестируемые производные SCIP (FSCIPC, FSCIPS) - напомните, что SCIP не является решателем с открытым исходным кодом - и решателем CBC с открытым исходным кодом. Опять же только коммерческие решатели CPLEX, Gurobi и XPRESS значительно превосходят MIPCL с точки зрения производительности.

Смежные вопросы