Organization/repository structure

[klamike]

Here is what I'm thinking for the structure now (subject to change of course):

Main repo

This should have all the generic/shared code. In particular it should be designed such that implementing a new method is as easy as possible.

• LearningToOptimize.jl -- implements some basic methods, but nothing more than penalty.
• LearningToOptimize.jl/lib/L2OCore.jl -- most of the generic code lives here, e.g. AbstractProxyModel, AbstractL2OMethod
• LearningToOptimize.jl/lib/L2OKernels.jl -- Batch evaluation of problem data #33
• LearningToOptimize.jl/lib/L2OData.jl -- dataset utilities
• LearningToOptimize.jl/lib/L2OModels.jl -- some common models i.e. neural network architectures

Methods

These will have specific methods. The four below should be a good start since they cover Primal, Dual, and Primal+Dual methods.

• L2ODLL.jl -- https://arxiv.org/pdf/2402.03086 and https://arxiv.org/pdf/2402.02596
• L2ODC3.jl -- https://arxiv.org/abs/2104.12225 and https://arxiv.org/abs/2506.00362
• L2OLDF.jl -- https://arxiv.org/abs/2001.09394
• L2OALM.jl -- https://arxiv.org/pdf/2403.03454

The main L2O repo allow for all the functionalities to be customized by a specific method. For example, consider opt_model::JuMP.Model and a function like generate_data(opt_model). Instead, we'd have generate_data(opt_model, ::AbstractL2OMethod). It is important to have sane defaults/fallbacks, so L2OLDF.LDFMethod <: L2O.PrimalMethod can fall back to a default generate_data(opt_model, ::L2O.PrimalMethod) which e.g. generates a dataset where inputs are all parameters and outputs are all primal variables. But L2ODC3 can define a generate_data(opt_model, ::L2ODC3.PrimalDC3) that for instance stores only the independent primal variables.

[klamike]

Something to look into is how docs work for the /lib/ setup, i.e. how much of a pain is it to set up Documenter.jl to let those subpackages have their own docs...