self-bootstrapping-model-service (SBMS)

A parallelizable framework designed for the execution of complex geographical model services on a single backend machine. SBMS leverages implicit and self-organizing relationships, avoiding the need for a pre-defined global DAG, by dynamically coordinating model execution through local node dependencies and state-driven control.

To bridge the model using requests，the model scheduling and the calculated resource, a core class named Model Case Reference (MCR) is designed and applied. The instance of this class can transfer a model using request and its related runtime-dependent parameters (usually found in the request body) from the web-server layer to a specific model case folder. Consequently, any requests using the same model with the same parameters can be directed to the same model running case.

graph LR

        subgraph BMSAPIS[<b>APIS</b>]
            API0>API 0]
            API1>API 1]
            APIN>API...]
        end

        subgraph Models[<b>Models</b>]
            Model0[Model 0]
            Model1[Model 1]
            ModelN[Model...]
        end

        subgraph ModelRequests[<b>Model Using Requests</b>]
            Request0([Model Request 0])
            Request1([Model Request 1])
            Request2([Model Request 2])
            RequestN([Model Request...])
        end

        CaseID0(((<b>Case ID</b>)))

        subgraph ModelCaseReferences[<b>Model Case References</b>]
            MCR0((MCR 0))
            MCR1((MCR 1))
            MCRN((MCR...))
        end
        
        subgraph CaseContent[<b>Model Case Content In Disk</b>]
            Identity[identity.json]
            Response[response.json]
            subgraph Result[<b>Result</b>]
                File0[File 0]
                File1[File 1]
                FileN[File...]
            end
            subgraph Status[<b>Status</b>]
                StatusFile[StatusFile]
            end
        end

        subgraph Resource[<b>Resource</b>]
            subgraph DEMFiles[e.g. DEM Resource]
                DEM0[DEM Resource 0]
                DEM1[DEM Resource 1]
                DEMN[DEM Resource...]
            end
            
        end

    API0-->Request0
    Request0-.-|SAME API and REQUEST BODY|Request2
    API0-->Request2


    MCR0--o|PARSE REQUEST and USE|Model0

    MCR0--o|PARSE REQUEST and INPUT|DEM0
    MCR0--o|PARSE REQUEST and INPUT|DEM1
    MCR0-->|OUTPUT|Result
    MCR0-->|SERIALIZE|Identity
    MCR0-->|GENERATE after MODEL RUNNING COMPLETE|Response

    Request0-->|GENERATE from URL and REQUEST BODY|CaseID0
    Request2-->|GENERATE from URL and REQUEST BODY|CaseID0
    CaseID0-->MCR0
    MCR0==x|POINT TO|CaseContent
    MCR0-->|REFLECT MODEL RUNNING STATUS|Status

    style BMSAPIS fill:none
    style Models fill:none
    style ModelRequests fill:none
    style ModelCaseReferences fill:none
    style CaseContent fill:none
    style Resource fill:none
    style Result fill:none
    style Status fill:none
    style DEMFiles fill:none

Loading

NOTE

The basic condition for MCR to be EFFECTIVE is that when the model and parameters have not changed, the results of multiple runs are COMPLETELY CONSISTENT.

Launch server

• Dependencies:

    FastAPI
    Portalocker

• Run:

    python "run.py"