Skip to content

JOSS Review

Part of https://github.com/openjournals/joss-reviews/issues/4158

I haven't tested the software yet, but a few major questions and a few minor points with regard to the paper:

  • Why create an entirely new language + parser instead of extending an existing modeling language? You discuss the drawbacks of extending an AML, but not the drawback of creating an entirely new AML.
  • Why the discussion of ASMFs? My understanding is that GBOML is an AML with special handling of block-structures. That seems more in line with StructJuMP and Plasmo.jl than PowerModels etc. I think you should tighten the discussion and say that your intended application area has lots of block structure that some solvers can exploit, but existing AMLs do not provide a way to communicate this information to the solver. Some AMLs have extensions like StructJuMP and Plasmo, but these have drawbacks, such as assuming specific structures and not being fully integrated into the AML with regard to maintenance and documentation (StructJuMP is effectively unmaintained at this point). GBOML is a new AML with special support for describing block structures in mixed-integer linear programming.
  • It would be useful to see an example of GBOML in the paper.
  • You should analyze SMS++ and Plasmo in more detail. What do they do similarly and differently?
  • p2l47: How do AMLs lack modularity? What is modularity in this context?
  • p2l60: which AMLs are notoriously slow?
  • p2l64: you could argue the Plasmo is intended for nonlinear graph models of complex systems, not exploiting block structure in MILP
  • p2l68 and l70: aren't these common to all AMLs? It's not something unique to GBOM
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information