During development of CCOpt.jl and MPCCModels.jl I have had the chance to develop some ideas about how to improve the NLPModels ecosystem. Namely there are a few major pieces of the current state which make it difficult to develop new model types and to exploit knowledge of the model type at the solver level. Three particular things are:
- The forest of booleans which live in the
NLPModelsMeta defining what parts of the NLPModels API a given model supports.
- The linear/nonlinear API.
- The difficulty of writing wrapper types which can expose to the solver their characteristics in a multiple-dispatch friendly way.
To improve 1,3, I propose to move as much of the forest of booleans to type parameters of the AbstractNLPModel type.
This would allow much cleaner specialization of solvers to particular model types (particularly things like QuadraticModel or LinearModel where we could implement avoiding function reevaluation easier). It also would allow better specialization for solvers in cases where some of the optional api methods are implemented. In principle this is all possible now but requires messy if-else cases throughout solver code.
For point 2 I think the suggestion made in #511 makes a lot of sense. Paying a quadratic-in-nonzeros price or having to re-implement everywhere the api for the linear/nonlinear split is quite painful, and not always possible (e.g. in some cases a downstream model which you wrap may call the default slow implementation anyway, because someone didn't implement things correctly).
Additionally I would propose standardizing on the fact that meta.* fields should not be directly accessed. Direct access means that (as is done in some places) wrapper meta's are forced to implement the whole list of fields rather than be more cleanly implemented as composition of AbstractNLPMeta structs (as is done in MPCCModels.jl and CCOpt,jl). This will make migration less painful when fields of NLPModelMeta change.
I will slowly start implementing these ideas in a PR, so they should become more clear as that implementation takes shape, but I am happy to discuss.
During development of
CCOpt.jlandMPCCModels.jlI have had the chance to develop some ideas about how to improve theNLPModelsecosystem. Namely there are a few major pieces of the current state which make it difficult to develop new model types and to exploit knowledge of the model type at the solver level. Three particular things are:NLPModelsMetadefining what parts of theNLPModelsAPI a given model supports.To improve 1,3, I propose to move as much of the forest of booleans to type parameters of the
AbstractNLPModeltype.This would allow much cleaner specialization of solvers to particular model types (particularly things like
QuadraticModelorLinearModelwhere we could implement avoiding function reevaluation easier). It also would allow better specialization for solvers in cases where some of the optional api methods are implemented. In principle this is all possible now but requires messyif-elsecases throughout solver code.For point 2 I think the suggestion made in #511 makes a lot of sense. Paying a quadratic-in-nonzeros price or having to re-implement everywhere the api for the linear/nonlinear split is quite painful, and not always possible (e.g. in some cases a downstream model which you wrap may call the default slow implementation anyway, because someone didn't implement things correctly).
Additionally I would propose standardizing on the fact that
meta.*fields should not be directly accessed. Direct access means that (as is done in some places) wrapper meta's are forced to implement the whole list of fields rather than be more cleanly implemented as composition ofAbstractNLPMetastructs (as is done inMPCCModels.jlandCCOpt,jl). This will make migration less painful when fields ofNLPModelMetachange.I will slowly start implementing these ideas in a PR, so they should become more clear as that implementation takes shape, but I am happy to discuss.