Edge to cloud simulation

prepare→analyze→summarizeedge · cloud · edge

This is a complete, deterministic SimGrid tutorial. It runs prepare → analyze → summarize: the 12-second analysis runs on a cloud VM that is four times faster than the edge device, then its result returns to the edge. The placement gains compute time and pays for two network flows and cloud use.

Use it when you want a small workflow whose planned and observed values can be inspected end to end. Do not use the checked-in manual plan to compare schedulers: generate a planning session instead when the goal is to compare PRISM and HEFT candidates.

What the simulation models

Item	Value in this example	Why it matters
Edge resource	2 cores, speedup 1, no per-second price	Runs prepare and summarize.
Cloud resource	8 cores, speedup 4, $0.001 per second	Runs analyze faster, with boot and container overhead.
Link	Bidirectional, 100 Mbit/s, 50 ms latency	Carries the 100 MB input to cloud and the 20 MB result back.
Activity durations	4 s, 12 s, 2 s before resource speedup	These are per-activity simulation profiles, not one shared default.

The diagram and the workflow YAML show the same topology: prepare produces dataset.bin (100,000,000 bytes), and analyze produces result.bin (20,000,000 bytes). Because the manual assignment places adjacent activities on different resources, the completed run must report two transfers totaling 120,000,000 bytes.

Download the inputs

Environment YAML ↓Execution scope YAML ↓Network topology YAML ↓Workflow YAML ↓Manual plan envelope ↓Execution envelope ↓

AkôFlow Desktop

Run with AkôFlow Desktop

1. Open Infrastructure → Environments and create a simulation environment matching environment.yaml. Add the SimGrid runtime, then bind it to the edge and cloud resources. Set cores, speedup, price, boot, and container values before planning.
2. Open Infrastructure → Execution scopes and create the scope from scope.yaml. Attach a topology matching topology.yaml: it must include both directions of the 100 Mbit/s link. A scope without this link cannot predict the cross-resource transfers in this example.
3. Open Workflows → Definitions and import workflow.yaml. Open the imported workflow and check the Definition graph: it must contain three activities and the two arrows prepare → analyze → summarize. Select an activity to confirm that it is simulatable and has its own duration profile.
4. To reproduce the documented placement, choose Generate plan, select Create manually, choose the simulation scope, then place prepare and summarize on the edge and analyze on cloud. The portable plan-request.yaml is the API equivalent of this choice.
5. To compare algorithms instead, choose Generate plans, select the same scope, and run the desired candidates. Expand a candidate to inspect its Gantt chart before selecting it.
6. Start the selected simulation. On the completed run, use Data for the two data flows and Plan vs execution for predicted versus observed makespan and cost.

API

Run through the API

Run this in a fresh AkôFlow instance, or change every ID in the six YAML files first. The API treats these identifiers as persistent objects and rejects duplicate IDs. From the repository root, set the daemon address and token, then submit the complete bundle:

export AKOFLOW_API_URL="http://127.0.0.1:8080/akoflow-api"
export AKOFLOW_API_TOKEN="<token>"

post_yaml() {
curl --fail-with-body \
  -H "Authorization: Bearer $AKOFLOW_API_TOKEN" \
  -H 'Content-Type: application/yaml' \
  --data-binary "@$2" "$AKOFLOW_API_URL/$1/"
}

post_yaml environments examples/simulation/environment.yaml
post_yaml execution-scopes examples/simulation/scope.yaml
post_yaml network-topologies examples/simulation/topology.yaml
post_yaml workflow-definitions examples/simulation/workflow.yaml
post_yaml schedule-plans examples/simulation/plan-request.yaml
post_yaml execution-runs examples/simulation/execution-request.yaml

Submitting execution-runs acknowledges the request; it does not mean the execution has completed. Poll the immutable run projection until status is completed:

curl -H "Authorization: Bearer $AKOFLOW_API_TOKEN" \
"$AKOFLOW_API_URL/execution-runs/simulation-example-run-v1/"

The imported definition before planning. Verify the three nodes and their two dependency arrows; use Generate plan only after this graph reflects the workflow YAML.

The planning screen uses one frozen workflow, scope, and topology for every candidate. Choose Simulation for this Showcase, then use manual placement for reproduction or generated candidates for an algorithm comparison.

Verify the result

The bundle was exercised against the current API on 2026-09-11. Its run projection, simulation-example-run-v1, reached completed with three settled activities, two transfers, and 120000000 transferred bytes. The observed makespan was 21.593 s; its accumulated execution time was 9 s, and its accumulated transfer time was 11.693 s.

Those stage values are accumulated across activities; they are evidence components, not additional wall-clock makespan. The completed run also stores the selected assignments, predicted values, observed cost, and the SimGrid trace under the daemon's configured simulation workspace.

If any of these checks fails, recover in this order:

1. Confirm that all three activities retained their individual simulation.durationSeconds values after import.
2. Confirm the resource runtime bindings enable simgrid for both resources.
3. Confirm the scope points to simulation-example-v1 and the topology is attached to that scope.
4. Confirm that the activity IDs in the manual plan are the imported IDs: simulation-example-workflow-prepare, simulation-example-workflow-analyze, and simulation-example-workflow-summarize.

For a shorter first execution, use Run your first simulated workflow. For the semantics behind resources, scopes, and data dependencies, see Core concepts.