Add pure Java LP solver backend using ojAlgo (issue #70)

[dyrpsf]

This PR addresses #70 by providing a pure Java linear programming solver backend based on ojAlgo.

Changes:

• Add org.ojalgo:ojalgo as a dependency in pom.xml.
• Introduce OjAlgoLinearProgramSolver implementing scpsolver.lpsolver.LinearProgramSolver using ojAlgo's ExpressionsBasedModel.
• Add OjAlgoLinearProgramSolverTest to verify that the new solver can solve a simple LP problem.

Usage:

SBMLDocument doc = ...;
FluxBalanceAnalysis fba = new FluxBalanceAnalysis(doc, new OjAlgoLinearProgramSolver());
boolean ok = fba.solve();

This enables running FBA on platforms where native GLPK/JNI is not available.

[draeger]

Can this solver be merged into OptSolvX?

[dyrpsf]

Yes, that would work for me. I’m happy to move this ojAlgo-based implementation over to OptSolvX and expose it there as a solver backend.

My understanding is that the long‑term idea is:

• SBSCL focuses on interpreting systems biology models and building the LP,
• OptSolvX provides the abstraction over concrete LP solvers (including ojAlgo).

I’ve also replied on issue #70 with a couple of questions about OptSolvX (which interface/class you’d like a new solver to implement and any preferred test cases). Once that is clarified, I can:

1. Open a PR on draeger-lab/OptSolvX adding the ojAlgo solver implementation, and
2. Then adapt/close this PR depending on how you’d like SBSCL to depend on OptSolvX.

Let me know if that plan matches what you have in mind or if you’d prefer a different integration.

[draeger]

Thank you for this effort! While I see the value of this contribution and honor it, I believe it should be better integrated into OptSolvX and would therefore prefer to reject this pull request here – however, not the work itself! @xts-Michi: Please comment on this.

[xts-Michi]

Thanks a lot for the contribution and for your willingness to help with this project.

This PR overlaps with work that is already in place. Since SBSCL now uses OptSolvX as the LP abstraction layer (see PR #90), and OptSolvX already provides an ojAlgo backend (see OptSolvX PR #9), the functionality in this PR is already available through the existing integration. To avoid maintaining duplicate implementations, we’ll close this PR here.

I agree with @draeger that solver implementations belong in OptSolvX, and SBSCL should only depend on OptSolvX. (See my comment in the closed PR #99). If you believe your implementation adds something not covered by the current OptSolvX ojAlgo backend, please point out the delta and we can incorporate it there.

For contributions to SBSCL, we’re currently aligning solver-backend integration and that area is changing quickly. I’ll post an update with concrete, non-overlapping tasks after the next sync.

[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.