How projectEureka™ is put together

How a flow runs

New flow, Import, and Examples create or copy a saved flow. Save keeps it. Submit runs it once, and a second Submit keeps the first run's files.

Anyone on the project can run a flow that is already there and can stop a run they started. An owner or editor can create and edit a flow. The owner can delete the flow and can stop any run. A reader uses what is already saved.

Steps run in list order. A bar along the left runs those steps together, and the step under the bar waits for all of them. Each step has a checkbox, off by default, that can stop the whole flow when that step fails.

Project switches show or hide flow steps. They do not grant cloud permissions.

CPU job

A script on a CPU machine. The machine type starts blank. Enter a duration to see an approximate price. The usual run is one script on one machine. The same step can become a small Slurm job when the script needs several machines or a job array.

GPU job

The same kind of script on a GPU machine. The GPU count comes from the machine type. The machine type starts blank.

Container

A setting on a CPU or GPU step. The list is images already downloaded onto this environment. An owner or editor downloads an image first. A reader can run a flow that already points at an image that is there.

Flow containers live on the same catalog: OpenFOAM, GROMACS, BLAST, PyTorch, TensorFlow, WRF, and others. Download the container, then choose it on the step. Sample flows on that site import into the project. A flow container stays on the step. Create an app when the container is meant to open in the browser.

File copy

Each row is one source and one destination: project files, home, a project bucket, or a machine. A copy attached to a CPU or GPU job runs with that job. A copy as its own step stands alone. This moves the bytes. The shared files are how one step hands a result to the next.

Language model

One call to the model enabled on this environment. The default is the inexpensive model, and the saved flow holds no cloud model id and no API key. The Edit tab is the instructions. Files from earlier steps are extra reading. The step writes a reply for the next step.

Language-model loop

The same call, repeated until the reply passes every check, or until the turn limit. The limit starts at 5 and stays between 1 and 20. The usual checks are that the reply is one JSON object and that its confidence is high enough. Only the latest reply goes to the next step. The loop stays inside this step, and the next step is still the next box.

Quantum

One circuit, then a count of the measured results for the next step. It starts on the simulator. The quantum processor stays off until an administrator allows it, and those shots cost money. The shot count starts at 100. The short examples use 32 or 64. If an earlier step wrote the circuit file, that file is the circuit for this run.

ML job

One managed training job. The step waits and writes a status file. A data location is optional. The short example has no dataset: it starts a real job, writes a small result, and exits. On Google Cloud the default asks for a TPU; an administrator can keep that example on CPU. On AWS the training machine is a small general-purpose type. The project needs a bucket.

Examples

A small CPU step can write a few result lines, and a loop can read them and stop when the reply names the top hit. A simulator can write counts, and a loop can say whether those counts look even. Ten CPU steps can sit under one bar, with one language-model step under the bar reading all ten. The same program on ten inputs can also be one CPU step that writes ten result files.

After Submit

The monitor shows each step as waiting, running, or done, with a duration. The files worth keeping are the script output, the model reply, the quantum counts, and the training status.