Should AbstractBatchNLPModel be a subtype of AbstractNLPModel?

[sshin23]

I think the batched problem can be solved as a monolithic NLP problem, and in that regard, should we make AbstractBatchNLPModel a subtype of AbstractNLPModel? For example, an obj can be implemented simply by

function NLPModels.obj(m::AbstractBatachNLPModel, x)

# query nx and ns from the proper place

    return sum(NLPModels.obj(m, reshape(x, nx, ns)))
end

[klamike]

When we want to solve batch instances independently (ie not the stochastic opt setting), don't we need the individual objective values? I am relying on it for the batched MadIPM: https://github.com/klamike/MadIPM.jl/blob/3a4927f29254a7ad250ae0ffa1f95d38fbdcb5f3/src/batch/madnlp/nlpmodels.jl#L79

[dpo]

I've only recently noticed the work that you have done on parametric and batched models. Thank you for all that. However, I feel that they really belong in separate packages, where they would be easier to maintain. That is also because this package is already quite difficult to maintain as it stands. That would also be in line with other similar packages (e.g., ManualNLPModels, ADNLPModels, etc.).

Of course, I'm totally happy to host the two extra repos in this organization.

Would that be agreeable?

[klamike]

That makes sense! I am curious how @amontoison thinks about this now, IIRC he was in favor of having the batch and parametric APIs be here in NLPModels.jl. I don't feel strongly either way. It would be nice for code live in this organization rather than just under my profile though.

One annoying technicality is that the batch API has been released, so moving it (unless we re-export here, I suppose) would be breaking. But the only code using it AFAIK is my mk/nativebatch branch of MadIPM (which I am happy to update), and @amontoison's branch of ExaModels, neither of which have been merged/released.

[amontoison]

Hi everyone,

I am fine with everything as long as it is convenient for you.

For the batch API, we just added a symbol obj!, two abstract types AbstractBatchNLPModel and AbstractBatchNLPModelMeta, and the structure BatchNLPModelMeta.
Even if the symbols are the same, the signatures of the functions are slightly different.
For example, obj_weight is no longer a keyword argument in the batch case because the in-place variants are not truly in-place if we allocate a keyword argument (vector in the batch case).
It was transformed into a regular argument.

If we want AbstractBatchNLPModel to be a subtype of AbstractNLPModel, it makes sense to unify the API by making obj_weight a regular argument rather than a keyword argument.
However, this would mean a release 0.22.1 with a deprecated signature and all the impacts on compact entries and dependent packages.
If we unify the API, then having an AbstractBatchNLPModel would no longer be relevant.

The advantage of keeping these minor differences in NLPModels.jl (for now) is that we have an abstract interface for a batch model in ExaModels.jl, ADNLPModels.jl, and QuadraticModels.jl and we stay with NLPModels.jl v0.21.x.
I also documented the abstract interface here.
The goal was to provide a common API for implementing batch models.
In the end, I did my best to keep it as minimal and non-intrusive in NLPModels.jl as possible.

For the parametric API, I am less convinced that it should be included here because it is quite specific to MadDiff.jl and introduce a number of new symbols in the namespace.
I would suggest moving ParametricNLPModels.jl to the JSO organization and continuing to prototype it there.
This will also give you more flexibility to make changes than adding it here.

For the batch API, I discussed a few weeks ago with Michel, François, Sungho, and you, and we converged to what we have now.
I am quite convinced by the current signatures.
In all cases, it is not an issue to remove the batch API from here if you have a better alternative.

My goal was also to leave you with all the building blocks to continue the research on batch solvers that we started.
I started my new position this Monday and haven't requested yet authorization to continue collaboration on the open-source projects.
I will finalize something with @cvanaret this week, but I will be low-profile starting next week and will only answer messages if you tag me.
However, they will likely never approve maintaining JSO, Exanauts, MadSuite, Uno, GALAHAD, ralna, ... organizations/packages like I did in the past.
I will need to make choices and keep the ones that are most GPU-related (like Krylov.jl) or those with active collaborations (MadSuite / Uno).
My hands are tied right now, and I also want to reduce the workload after the post-doc adventure, so it's not too bad in the end.