search

terranexum / OpenQGO

A generalized, open-source version of our Quantum Global Optimizer platform to solve the problem of getting anything where it needs to go.
MIT License
3 stars 2 forks source link

Define Public Interface #10

Closed jimmcgaw closed 10 months ago

jimmcgaw commented 10 months ago

Using this to start a discussion.

I have a general set of questions, so I have some idea of where we might go next. I'm not necessarily suggesting that we do either of these things, but I'm trying to understand how end users would consume this, so as to develop a sense of how to make this intuitive.

  1. I imagine that we could bundle this up so that pip install openqgo would allow people to use this as a pip package in their own code.

As a thought experiment, when someone does this:

from openqgo import ?

what class are they importing? What parameters should it take in? What kind of data does it return?

  1. Similar to 1: we could also expose this somewhere, via an API that could be called, for example a REST interface, so that a UI could send information to it and get back a result it could use. What would the inputs to this endpoint be, and what would it return?

What I'm asking after is the most general use case that would serve the most people right now, in terms of: Inputs -> OpenQGO -> Outputs

@dahlwinters @AwesomeMarker100

dahlwinters commented 10 months ago

Great questions @jimmcgaw and an excellent thought to have openqgo as a library.

Some background: I am imagining a UI with a data input form. Three GeoJSONs need selecting for the three node types (source, intermediary, and sink). Validation must then be performed prior to uploading for processing or validation after pointing to a public URL, then uploading for processing. Each node type should have in its GeoJSON data at least one user-selectable numeric value using the same dimensional units, whatever it might be that the user wishes to optimize over. Ideally these would be visualized on a map on the same UI.

As an example, if we wish to ensure the max flow of energy from source to sink and we want to find where renewable energy could be sited at intermediary nodes to serve energy needs at the sinks that are now supplied by non-renewable source nodes, all three values selected from the three GeoJSON files should be numbers with units of energy. The user then hits Submit, the optimization runs from OpenQGO, and an output GeoJSON is produced containing the edges and their flow values which get returned to the UI for visualization. The user should then be able to export their results.

As a standalone library or API, OpenQGO should have interfaces for receiving data_in, setting up the problem (in OpenQGO.py when QGOProblem is imported from QGONexum.py (a utilities file, we might rename it QGOUtils.py for clarity) ), running the optimization (also in OpenQGO.py), and writing the solution to data_out (handled in QGOOut.py).

Where the OpenQGO code would fit in the MVP UI - I was going to set up an event-based pipeline so that upon data storage in S3 and an auto-generated data setup file with instructions on the S3 data location and the fields the user wished to use, this would kick off a Lambda function to get the optimization above done and provide the result to S3. When ready, the user would be notified and would be able to view the output on the UI.