Why is my (sub)lattice generating extra list indexing tasks?

[Andrew-S-Rosen]

I have been trying to better understand dynamic workflows (and, by extension, sublattices) and am running into some points of confusion. Below, you can find a sample workflow that I've tried to make reasonably simple. I used the example here as inspiration. Functionally, it's similar but slightly different (in ways I'm having difficulty putting into words...). Overall, the workflow should do: 1) Add one to the input number; 2) Turn this single number into a list of length three; 3) Add one to each number in that list; 4) Return this list.

@ct.electron
def add_one(val):
    return val + 1


@ct.electron # it works if I delete the decorator
def make_more(val):
    return [val] * 3


@ct.electron
@ct.lattice
def sub_lattice(val):
    vals = make_more(val) # it works if I do vals = [val] * 3
    return [add_one(val) for val in vals]


@ct.lattice
def workflow(val1):
    val2 = add_one(val1)
    return sub_lattice(val2)


# Dispatch the workflow
dispatch_id = ct.dispatch(workflow)(1)
result = ct.get_result(dispatch_id, wait=True)
print(result)

The error, as alluded to in the image below, is due to an excessive amount of list indexing tasks that are made in the sublattice, which then causes an IndexError: list index out of range. If I replace vals = make_more(val) in the sublattice with vals = [val] * 3, the workflow runs just fine. It also works fine if I drop the ct.electron decorator from the make_more function. So, my question is, why is calling the make_more() Electron from within the sublattice causing an issue? I don't think it's simply the fact that it's an Electron because otherwise add_one() would cause problems from within the sublattice, which it doesn't.

I feel like I'm super close to understanding this one...

[santoshkumarradha]

Hi @arosen93! You're doing a great job diving into dynamic workflows and sublattices. You're definitely on the right track, and I'm here to help clarify things for you.

The issue you're encountering is related to the iterable vals inside the sub_lattice function. When constructing lattices (including sublattices), for loops or while loops can produce random graphs if the iterable is not determined and is a future. In your case, vals in sub_lattice will not be known even when sub_lattice is compiled for the subgraph. Only val (the input of the sublattice) is known during its construction. To reproduce your error without using sublattice, you can try the following example:

import covalent as ct
@ct.electron
def f(x):
    return [x]*3

@ct.lattice
def workflow(x):
    return [i for i in f(x)]

ct.dispatch(workflow)(x=2)

Now let's look at how to create dynamic workflows in your case. The key pattern is to understand that a sublattice object will wait until its inputs are available before building the sub-graph. Here's an example that should work for the workflow you described:

Here is an example to let you do what you had asked

import covalent as ct
@ct.electron
def add_one(val):
    return val + 1

@ct.electron
def make_more(val):
    return [val] * 3

@ct.electron
@ct.lattice
def add_one_distributed(val):
    return [add_one(i) for i in range(len(val))]

@ct.lattice
def workflow(val1):
    val2 = add_one(val1)
    val3=make_more(val2)
    return add_one_distributed(val3)

ct.dispatch(workflow)(2)

In this example, the sublattice add_one_distributed is built during the workflow execution. To make the workflow even more dynamic, you can try the following:

import covalent as ct
@ct.electron
def add_one(val):
    return val + 1

@ct.electron
def make_more(val, num=3):
    return [val] * num

@ct.electron
def random_number():
    import random
    return random.randint(0, 20)


@ct.electron
@ct.lattice
def add_one_distributed(val):
    return [add_one(i) for i in range(len(val))]

@ct.lattice
def workflow(val1):
    val2 = add_one(val1)
    repeate=random_number()
    val3=make_more(val2,repeate)
    return add_one_distributed(val3)

ct.dispatch(workflow)(2)

Each time you run this, the sublattice add_one_distributed will have a dynamically different number of nodes based on the length of val3, which is computed only during the workflow execution.

I hope this helps clarify things for you. Please feel free to reach out if you have any more questions or concerns!

[Andrew-S-Rosen]

Oh wow! This is super useful, as always. Thank you so much. I'm going to let this one sink in, but I think I've got what you mean!!

[santoshkumarradha]

Not a problem, @arosen93! Please feel free to ask for additional examples or explanations if necessary. We should be prioritizing dynamic workflow documentation soon, if you have suggestions or even interesting applications do let us know, we can pipe it in to the docs !

[Andrew-S-Rosen]

That all sounds great! I have a tutorial idea that I think would work nicely for this. I'll get back to you with some details!

[Andrew-S-Rosen]

I opened a PR for a WIP tutorial! #1645