Support pure Java solver for constraint-based modeling

[draeger]

On some platforms, it might be difficult to run the Java Native Interface (JNI) needed for SCPsolver. Consider adding support for pure Java implementations, such as

• https://www.ojalgo.org/code-examples/
• https://advancedweb.hu/running-lp-and-ip-optimisation-from-java/

[dyrpsf]

Hi all,

I’ve implemented a pure Java LP solver backend based on ojAlgo, so constraint-based modeling can run without relying on the native GLPK/LPSOLVE packs.

Changes are in PR #100 and include:

• Added org.ojalgo:ojalgo as a dependency in pom.xml.
• Introduced org.simulator.fba.OjAlgoLinearProgramSolver, which implements scpsolver.lpsolver.LinearProgramSolver and internally maps SCPSolver’s LinearProgram (objective, bounds, linear constraints, integrality) to ojAlgo’s ExpressionsBasedModel.
• Added a JUnit 5 test OjAlgoLinearProgramSolverTest (package org.sbscl.fba) that verifies the new solver on a small LP example.

Usage example:

import org.simulator.fba.FluxBalanceAnalysis;
import org.simulator.fba.OjAlgoLinearProgramSolver;
import org.sbml.jsbml.SBMLDocument;

// ...
SBMLDocument doc = ...;
FluxBalanceAnalysis fba = new FluxBalanceAnalysis(doc, new OjAlgoLinearProgramSolver());
boolean ok = fba.solve();
double objective = fba.getObjectiveValue();

All tests (mvn test) pass on my setup (Windows 11, JDK 24, Maven 3.9.x).
Existing SCPSolver + GLPK integration is unchanged; this just provides an additional pure Java backend for environments where JNI-based solvers are hard to deploy.

Happy to adjust naming, API, or tests if you’d like it structured differently.

[draeger]

This is highly interesting! Thank you for this valuable contribution, @dyrpsf! Do you think it could be possible to integrate this solver in the separate project https://github.com/draeger-lab/OptSolvX for linear optimization in Java? It is supposed to abstract from underlying solvers. We wanted to have a separate project so that SBSCL focuses on interpreting systems biology models and passing the resulting problem definitions to general solvers rather than implementing specific solvers for systems biology systems.

[dyrpsf]

Hi @draeger ,

Thanks a lot for the feedback and for pointing me to OptSolvX, that makes sense.

Yes, I’d be happy to look into integrating this ojAlgo-based solver into draeger-lab/OptSolvX so that SBSCL can stay focused on interpreting models and hand off the LP to a more general optimisation layer.

From a quick look it seems the right approach would be:

1. Add an ojAlgo-based solver implementation in OptSolvX that conforms to its solver abstraction.
2. (Possibly in a follow-up step) adapt SBSCL’s FBA code to use OptSolvX’s API instead of directly talking to SCPSolver.

Before I start on a PR for OptSolvX, I have two small questions:

• Is there already a preferred interface/class in OptSolvX that new solvers should implement, or should I propose one based on the current design?
• Are there any example models or test cases you’d like me to use when validating the ojAlgo integration there?

Once I have a first version for OptSolvX, I can link that PR here and then we can see how best to connect SBSCL’s FBA to it.

[draeger]

Thanks a lot, dear @dyrpsf! The library OptSolvX was primarily developed by @xts-Michi, who can better elaborate on the design and extendability, in particular, on how to add an additional solver. We designed OptSolvX during the last GSoC to more clearly separate tasks and improve code reusability and individual testing. There is an interface to SBSCL already.

[xts-Michi]

Thanks for the work and discussion here.

SBSCL is in the final stage of integrating OptSolvX as the LP abstraction layer (SBSCL PR #90). OptSolvX already provides an ojAlgo backend (OptSolvX PR #9), so we don’t need a separate ojAlgo extension in SBSCL.

Next week we have a meeting to align on the remaining steps and the merge of the OptSolvX integration in SBSCL. Once that integration is merged and SBSCL is using the OptSolvX interface, this issue can be closed. Until then, I’m marking it as in progress to indicate that the solver backend already exists in OptSolvX and there is no need to work on this issue anymore.

Currently it’s a bit confusing to tell which issues still need work and which are simply waiting for an upcoming change. After the OptSolvX integration is merged, I’ll go through the issue tracker and flag items that are ready for contributions versus issues that are open but already have a solution in progress. This should make it easier for new contributors to identify where help is needed.

[dyrpsf]

Thanks a lot for the detailed explanation and the pointers to the existing work (SBSCL PR #90 and OptSolvX PR #9).

I wasn’t aware that an ojAlgo backend already exists in OptSolvX and that its integration into SBSCL is already in progress. Given that, it absolutely makes sense to avoid duplicating the solver implementation here, and I’m completely fine with this PR being closed.

I’ll have a look at the current OptSolvX ojAlgo backend and the SBSCL–OptSolvX interface. If I notice any gaps or improvements compared to the implementation I prototyped, I’ll open an issue or PR on OptSolvX instead of adding another backend directly in SBSCL.

In the meantime, I’d be happy to help with any follow‑up tasks once the solver-backend integration has settled and you have clearer, non‑overlapping items. Please feel free to @‑mention me on future issues where contributions are welcome.

[draeger]

My suggestion to move forward with this issue is to focus on reviewing @xts-Michi's pull requests first. Next, I'd like to check with @dyrpsf and @xts-Michi what parts of #100 are still current. We'll need a second review for the PRs. It would be great if @matthiaskoenig could take a look as well.