Detour to continue a multi-task firework

FireWorks
#1

Hello,

I am facing the following problem: I am in a configuration with a multi-task firework. From a task in this firework I would like to create a detour of the current firework so that it will only execute the remaining tasks in the new firework. The structure of the firework is not strictly fixed and it would be basically impossible to have a different function to handle each different case.

As a potential solution, the full list of tasks in the firework can be taken from the _tasks attribute in the fw_spec, so the problem is to figure out the task being executed in this list. After giving some though I concluded that a clean way could be to have access directly to the index of the task: for example having a new reserved keyword in fw_spec (e.g. _task_index) that will be set by the rocket runner with the index of the current task in the firework.

Since I am not sure if this would be an acceptable update, I wanted to check if somebody else already had a similar problem and came up with smarter solution. Or otherwise if I can proceed to implement this in fireworks.

Alternative solutions I have thought about include:

  • identifying the task being executed based on the class of the task itself: may not work as more than one task with the same class could be present. One could further inspect the task and try to distinguish them based on some attribute, but this could become tricky

  • adding an index to each task myself: this would work but it seems much more difficult to maintain compared to having this index directly from fireworks.

Thanks.

Guido

#2

Hi Guido,

If I understand correctly, you are looking to find out which tasks were executed already in a Firework that is running.

There is some code in rocket.py that creates a checkpoint as the tasks in a Firework run:

checkpoint = {’_task_n’: t_counter,

‘_all_stored_data’: all_stored_data,

‘_all_update_spec’: all_update_spec,

‘_all_mod_spec’: all_mod_spec}

Rocket.update_checkpoint(lp, launch_dir, launch_id, checkpoint)

This updates the “state_history” attribute of a launch with information about the task number.

Currently, this code is used for task-level reruns. For example, if a Firework FIZZLES at task #4 within the Firework, this checkpoint information can be used to rerun the Firework only at task #4 if desired.

It’s possible this same feature could be used for what you are trying to accomplish?

···

On Monday, April 8, 2019 at 6:42:26 AM UTC-7, Guido Petretto wrote:

Hello,

I am facing the following problem: I am in a configuration with a multi-task firework. From a task in this firework I would like to create a detour of the current firework so that it will only execute the remaining tasks in the new firework. The structure of the firework is not strictly fixed and it would be basically impossible to have a different function to handle each different case.

As a potential solution, the full list of tasks in the firework can be taken from the _tasks attribute in the fw_spec, so the problem is to figure out the task being executed in this list. After giving some though I concluded that a clean way could be to have access directly to the index of the task: for example having a new reserved keyword in fw_spec (e.g. _task_index) that will be set by the rocket runner with the index of the current task in the firework.

Since I am not sure if this would be an acceptable update, I wanted to check if somebody else already had a similar problem and came up with smarter solution. Or otherwise if I can proceed to implement this in fireworks.

Alternative solutions I have thought about include:

  • identifying the task being executed based on the class of the task itself: may not work as more than one task with the same class could be present. One could further inspect the task and try to distinguish them based on some attribute, but this could become tricky
  • adding an index to each task myself: this would work but it seems much more difficult to maintain compared to having this index directly from fireworks.

Thanks.

Guido

#3

(note that you might need to use the “_add_launchpad_and_fw_id” option in the spec to be able to look up the Launch object and corresponding “task_n”

···

On Friday, April 12, 2019 at 11:58:07 AM UTC-7, Anubhav Jain wrote:

Hi Guido,

If I understand correctly, you are looking to find out which tasks were executed already in a Firework that is running.

There is some code in rocket.py that creates a checkpoint as the tasks in a Firework run:

checkpoint = {’_task_n’: t_counter,

‘_all_stored_data’: all_stored_data,

‘_all_update_spec’: all_update_spec,

‘_all_mod_spec’: all_mod_spec}

Rocket.update_checkpoint(lp, launch_dir, launch_id, checkpoint)

This updates the “state_history” attribute of a launch with information about the task number.

Currently, this code is used for task-level reruns. For example, if a Firework FIZZLES at task #4 within the Firework, this checkpoint information can be used to rerun the Firework only at task #4 if desired.

It’s possible this same feature could be used for what you are trying to accomplish?

On Monday, April 8, 2019 at 6:42:26 AM UTC-7, Guido Petretto wrote:

Hello,

I am facing the following problem: I am in a configuration with a multi-task firework. From a task in this firework I would like to create a detour of the current firework so that it will only execute the remaining tasks in the new firework. The structure of the firework is not strictly fixed and it would be basically impossible to have a different function to handle each different case.

As a potential solution, the full list of tasks in the firework can be taken from the _tasks attribute in the fw_spec, so the problem is to figure out the task being executed in this list. After giving some though I concluded that a clean way could be to have access directly to the index of the task: for example having a new reserved keyword in fw_spec (e.g. _task_index) that will be set by the rocket runner with the index of the current task in the firework.

Since I am not sure if this would be an acceptable update, I wanted to check if somebody else already had a similar problem and came up with smarter solution. Or otherwise if I can proceed to implement this in fireworks.

Alternative solutions I have thought about include:

  • identifying the task being executed based on the class of the task itself: may not work as more than one task with the same class could be present. One could further inspect the task and try to distinguish them based on some attribute, but this could become tricky
  • adding an index to each task myself: this would work but it seems much more difficult to maintain compared to having this index directly from fireworks.

Thanks.

Guido

#4

Hi Anubhav,

thanks for the tip. I was aware of the presence of the checkpoint, but I did not think of using it in this case. I can definitely use it to solve the problem in my workflow.

As a side note, it seems a bit of a waste passing through the database to get access to a value that is available locally. Thanks to your suggestion I already have a solution, but if you think that it could be beneficial I am available to add this value to the spec or as an attribute of the task.

Thanks,

Guido

···

Il giorno venerdì 12 aprile 2019 20:59:53 UTC+2, Anubhav Jain ha scritto:

(note that you might need to use the “_add_launchpad_and_fw_id” option in the spec to be able to look up the Launch object and corresponding “task_n”

On Friday, April 12, 2019 at 11:58:07 AM UTC-7, Anubhav Jain wrote:

Hi Guido,

If I understand correctly, you are looking to find out which tasks were executed already in a Firework that is running.

There is some code in rocket.py that creates a checkpoint as the tasks in a Firework run:

checkpoint = {’_task_n’: t_counter,

‘_all_stored_data’: all_stored_data,

‘_all_update_spec’: all_update_spec,

‘_all_mod_spec’: all_mod_spec}

Rocket.update_checkpoint(lp, launch_dir, launch_id, checkpoint)

This updates the “state_history” attribute of a launch with information about the task number.

Currently, this code is used for task-level reruns. For example, if a Firework FIZZLES at task #4 within the Firework, this checkpoint information can be used to rerun the Firework only at task #4 if desired.

It’s possible this same feature could be used for what you are trying to accomplish?

On Monday, April 8, 2019 at 6:42:26 AM UTC-7, Guido Petretto wrote:

Hello,

I am facing the following problem: I am in a configuration with a multi-task firework. From a task in this firework I would like to create a detour of the current firework so that it will only execute the remaining tasks in the new firework. The structure of the firework is not strictly fixed and it would be basically impossible to have a different function to handle each different case.

As a potential solution, the full list of tasks in the firework can be taken from the _tasks attribute in the fw_spec, so the problem is to figure out the task being executed in this list. After giving some though I concluded that a clean way could be to have access directly to the index of the task: for example having a new reserved keyword in fw_spec (e.g. _task_index) that will be set by the rocket runner with the index of the current task in the firework.

Since I am not sure if this would be an acceptable update, I wanted to check if somebody else already had a similar problem and came up with smarter solution. Or otherwise if I can proceed to implement this in fireworks.

Alternative solutions I have thought about include:

  • identifying the task being executed based on the class of the task itself: may not work as more than one task with the same class could be present. One could further inspect the task and try to distinguish them based on some attribute, but this could become tricky
  • adding an index to each task myself: this would work but it seems much more difficult to maintain compared to having this index directly from fireworks.

Thanks.

Guido

#5

Hi Guido

For the way FireWorks is currently set up, the task that is currently executing is a property of the launch and not of the FireWork itself. The goal of the FireWork is supposed to be all the information needed to bootstrap a job. Thus there is a separation between the “blueprint for running a job” (in FW spec) and “information about a particular job execution” (in launch object).

I don’t think I would mind however having a file called Launch.json (like FW.json) that contains a serialization of the current launch data. Then any code could read the task number locally as well as any other launch-related things (like error message, etc).

Note that there is some effort from people at LBNL to restructure the FireWorks codebase so that Launch and Firework are unified. If this were the case, then the task number could naturally become a part of the Firework itself.

···

On Fri, Apr 12, 2019 at 12:52 PM Guido Petretto [email protected] wrote:

Hi Anubhav,

thanks for the tip. I was aware of the presence of the checkpoint, but I did not think of using it in this case. I can definitely use it to solve the problem in my workflow.

As a side note, it seems a bit of a waste passing through the database to get access to a value that is available locally. Thanks to your suggestion I already have a solution, but if you think that it could be beneficial I am available to add this value to the spec or as an attribute of the task.

Thanks,

Guido

Il giorno venerdì 12 aprile 2019 20:59:53 UTC+2, Anubhav Jain ha scritto:

(note that you might need to use the “_add_launchpad_and_fw_id” option in the spec to be able to look up the Launch object and corresponding “task_n”

On Friday, April 12, 2019 at 11:58:07 AM UTC-7, Anubhav Jain wrote:

Hi Guido,

If I understand correctly, you are looking to find out which tasks were executed already in a Firework that is running.

There is some code in rocket.py that creates a checkpoint as the tasks in a Firework run:

checkpoint = {’_task_n’: t_counter,

‘_all_stored_data’: all_stored_data,

‘_all_update_spec’: all_update_spec,

‘_all_mod_spec’: all_mod_spec}

Rocket.update_checkpoint(lp, launch_dir, launch_id, checkpoint)

This updates the “state_history” attribute of a launch with information about the task number.

Currently, this code is used for task-level reruns. For example, if a Firework FIZZLES at task #4 within the Firework, this checkpoint information can be used to rerun the Firework only at task #4 if desired.

It’s possible this same feature could be used for what you are trying to accomplish?

On Monday, April 8, 2019 at 6:42:26 AM UTC-7, Guido Petretto wrote:

Hello,

I am facing the following problem: I am in a configuration with a multi-task firework. From a task in this firework I would like to create a detour of the current firework so that it will only execute the remaining tasks in the new firework. The structure of the firework is not strictly fixed and it would be basically impossible to have a different function to handle each different case.

As a potential solution, the full list of tasks in the firework can be taken from the _tasks attribute in the fw_spec, so the problem is to figure out the task being executed in this list. After giving some though I concluded that a clean way could be to have access directly to the index of the task: for example having a new reserved keyword in fw_spec (e.g. _task_index) that will be set by the rocket runner with the index of the current task in the firework.

Since I am not sure if this would be an acceptable update, I wanted to check if somebody else already had a similar problem and came up with smarter solution. Or otherwise if I can proceed to implement this in fireworks.

Alternative solutions I have thought about include:

  • identifying the task being executed based on the class of the task itself: may not work as more than one task with the same class could be present. One could further inspect the task and try to distinguish them based on some attribute, but this could become tricky
  • adding an index to each task myself: this would work but it seems much more difficult to maintain compared to having this index directly from fireworks.

Thanks.

Guido

–

You received this message because you are subscribed to the Google Groups “fireworkflows” group.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

To post to this group, send email to [email protected].

Visit this group at https://groups.google.com/group/fireworkflows.

For more options, visit https://groups.google.com/d/optout.

–
Best,
Anubhav