Support for matrix style model construction (MathProgBase/LinearQuadratic style) in modern Julia + MOI
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
Direzione di ricerca
Non vengono indicati file o test. Inizia esaminando le interfacce di costruzione attuali di MatrixOptInterface.jl e MathOptInterface, quindi confrontale con il workflow descritto per le matrici A, b e c; il lavoro sarebbe completato se fosse disponibile un workflow supportato e documentato oppure una limitazione chiaramente dichiarata per i modelli LP/MILP di grandi dimensioni.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
I’m reaching out about support or example workflows for constructing optimization models from raw matrix data in modern Julia, similar to how it was done with MathProgBase’s LinearQuadratic interface.
A bit of background on my situation:
• Years ago I implemented a large scale unit commitment MILP in Julia 0.6.4, using MathProgBase.jl and specifically the LinearQuadratic models interface, together with Gurobi as the solver.
• The model is truly large: on the order of ~2 million variables and constraints. I built the model from big matrices and vectors (A, b, c, etc.) in a Matlab style fashion and handed that directly to the solver.
Now I’d like to move the codebase to a current Julia version, but without changing the overall program structure—i.e., keeping a MathProgBase / LinearQuadratic style formulation rather than rewriting everything in JuMP or another high level modeling layer.
Question / request:
Is there any officially supported or recommended way in the current Julia / MOI ecosystem to construct a large LP/MILP directly from matrices and pass it to a solver, similar to the old MathProgBase LinearQuadratic approach?
Thanks for any pointers or suggestions. Even a small example or outline of how to plug matrix data into MOI, or a note on current limitations, would be very valuable.
- Lingua principale
- Julia
- Stelle
- 12
- Fork
- 4
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di jump-dev/MatrixOptInterface.jl
-
bug
Difficoltà 3/5 1-2 giorni Idoneità per principianti 30/100
-
documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 38/100
jump-dev/MatrixOptInterface.jl#24 · 1 reazione ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
jump-dev/MatrixOptInterface.jl#19 · 3 commenti ·
-
Standard conic formAperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
-
Register packageAperta
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
jump-dev/MatrixOptInterface.jl#12 · 7 commenti ·
Tutte le issue di jump-dev/MatrixOptInterface.jl
Issue simili
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 83/100
JuliaMath/Polynomials.jl#647 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
OpenSourceAWE/SymbolicAWEModels.jl#431 ·
I maintainer di solito rispondono entro 1 giorno
-
Make PDAQP an optional extraAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
JuliaArrays/StaticArrays.jl#1365 ·
-
`@fastmath` reductions are 2–5× slower: no `neutral_element` for `Base.FastMath.max_fast` and co.Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
JuliaGPU/GPUArrays.jl#833 ·
I maintainer di solito rispondono entro 1 giorno