Is JuMP the right package for large square models?

Is there a well defined ‘domain boundary’ between ModelingToolkit and JuMP?

I currently use GAMS and the Conopt solver to solve very large square systems of non-linear equations. I.e. exactly as many constraints as free variables. This is not strictly optimization of course, but rather seems to fit better under the ‘modeling’ umbrella. On the other hand, JuMP can obviously be used for this type of problem and the ability interface with GAMS and thus continue to use the Conopt solver is extremely valuable.

I have implemented a number of features in a GAMS pre-processor to help manage large square systems and would like to implement some similar features in Julia. Would features specific to managing square systems (for example easy mapping between endogenous variables and associated constraints) belong in JuMP (or an extension package)?

1 Like

An extension package is usually the correct first step. It gives you freedom to try out different approaches without waiting for the JuMP release process or compatibility guarantees.

Here’s the documentation for writing an extension
https://jump.dev/JuMP.jl/dev/developers/extensions/

Thanks for the link and don’t worry - I won’t spam you with half-baked pull requests. I was just wondering what the scope of JuMP is. Also I have not figured out if ModelingToolkit is simply a new package trying to compete with JuMP or if there are clear separate areas of responsibility.

The scope of JuMP is really “nice syntax for MathOptInterface.” There’s a couple of exceptions, like sensitivity analysis and an infeasibility checker. But in general there’s a high bar for adding new utilities.

ModelingToolkit is part of SciML. There are a few similarities, and there might be more scope for closer collaboration in future, but at present they’re separate things.

1 Like