Together we are more than the sum of our cells.

Introduction | Where to start? | Project Status | Network's Structure | Contacts | Website

TODO: Simple Image Describing The Core Features


We provide an open source ecosystem centered around optimization and operations research.

The main project is the Generic Allocator. It is a Java framework providing modeling, analytic and solving capabilities regarding optimization problems. A detailed introduction and documentation can be found here.

An overview of the projects can be found here. Some of them are not strictly related to optimization and can be used in other contexts as well. OS State Interface is the main example of such.

Where to start?

πŸš€ Model and optimize problems.

πŸ—οΈ Deploy the software.

πŸ”¬ Analyze and organize your operations and prepare schedules.

🀝 Collaborate large decision-making networks.

πŸ—žοΈοΈ Get an insight into our thoughts via our blog (also on Gemini) and programming progress via our changelog.

πŸ¦‰ Get an bird's-eye view.

πŸ”­ Research optimization.

πŸ“š Get structured documentation.

✍ Contribute to projects.

πŸ’° Support contributors.

πŸ“£ Spread the word!


TODO: Short And Compact Feature Description

Project Status

Continuous Integration Gitlab Continuous Integration status Total alerts Language grade: Java Language grade: Python Language grade: JavaScript FOSSA Status FOSSA Status

API Compatibility

There is no guarantee of backwards compatibility.

All API changes are located and categorized in the Changelog. Breaking changes are tried to be omitted, but there is no guarantee for that. The author of the software use this project as a dependency for their own private code. So there is at least an interest, to keep breaking changes to a minimum. On the other hand, the API is not polished, so there will be breaking changes to the API.

Absolute backward compatibility creates a maintenance burden and if any kind of backward compatibility is required it may be best to just contact this project. We do not break backward compatibility just for fun and would like to support efforts to minimize breaking changes.

You can try to decrease the likelihood of breaking a certain feature, by contributing an appropriate test case/suite for this feature. Regardless of that, keep in mind, that there is no guarantee of backwards compatibility.


Network's Structure

This project is meant to be part of a cluster, with a certain filesystem structure in mind. The cluster's filesystem consists of a folder containing repositories:

Project Cluster
β”‚   └── projects
β”‚       β”œβ”€β”€ net.splitcells.dem
β”‚       β”œβ”€β”€ net.splitcells.gel
β”‚       β”œβ”€β”€ net.splitcells.os.state.interface
β”‚       β”œβ”€β”€ net.splitcells.system
β”‚       └── ...
β”œβ”€β”€ net.splitcells.os.state.interface.lib.gpl.2
β”œβ”€β”€ net.splitcells.os.state.interface.lib.gpl.3
└── ...

This image illustrates the networks structure by showing relevant parts of the filesystem.

  • This repository integrates all projects, repositories and hosting services, that are part of the network.
    • dem: Provides a standardized fundament for Java projects.
    • gel: This framework delivers optimization capabilities.
    • os.state.interface: The projects helps the user to organize and execute commands in the terminal via dependency injection.
    • system: Manages all integrated subprojects of the network. In particular, it can be used to build all integrated projects.
  • Related projects/repositories: Related projects are located in repositories, which are at the same folder as the project. These projects are not inside this repository and are managed more independently. They may be managed by users with OS state interface. It is recommended to not nest repositories.

Social Contacts