Covalent version 0.110.2 is now live 🚀

[santoshkumarradha]

Summary

The latest release of Covalent is now out and available for community use. It comes with new features, including the integration of Dask into Covalent as the default executor/compute backend for workflows. As part of this release, we have also updated the CLI to allow users the flexibility to choose the default compute backend Dask or Local. The default executor for electrons are then suitably chosen at runtime. We have also made it simpler for users to parse the logs generated by Covalent at runtime by introducing the covalent logs CLI command to display the logs. A summary of the feature releases is provided below:

• Covalent now uses Dask as the default compute backend for executing workflows;
• Covalent also supports the ability to switch beween Dask and Local execution;
• A convenient CLI has been introduced that uses the covalent logs command to parse the logs generated at runtime.

Check out the summary table below for the list of added features and read the corresponding subsections to find out more.

Feature	Summary
Dask is the default executor	Dask is now the default executor for workflows
Ability to switch between Dask and Local Execution	Users can switch to using Local Executor by specifying the --no-cluster flag
Improved visibility into Covalent logs	Information about an active workflow session can be queried using covalent logs

🔌 Dask is the default executor

With this release, running covalent start starts a process based Dask local cluster that is used as the default compute backend for all workflows. The number of Dask workers defaults to the number of CPU cores on the user's machine and memory per worker is assigned by Dask automatically. The default executor for the electrons is switched from Local to Dask which effectively submits them to the Dask cluster for execution. One of the benefits that Dask provides in Covalent is enabling better parallelism of task execution.

With these updates, users do not need to pre-install covalent-dask-plugin. Workflows can be constructed as usual and are executed using Dask by default.

@ct.lattice
def workflow(y,z)
  ....
  
dispatch_id = ct.dispatch(workflow)(y=a, z=b)
result = ct.get_result(dispatch_id)

⚠️ If you are coming from covalent==0.106.0 version, please do pip uninstall covalent-dask-plugin before upgrading to covalent==0.110.2 as covalent-dask-plugin is now shipped by default as executer

💻 Switching between Dask and Local Execution

To allow users to choose the compute backend, users can launch covalent without Dask by specfying the --no-cluster flag i.e covalent start --no-cluster will launch Covalent with the Local executor as the default. Workflow graphs and result objects remain consistent in both modes of execution and the UI automatically reflects the active compute backend, i.e., either Dask or Local.

UI reflecting Dask Execution

UI reflecting Local Execution

🗒️ Improved Logging

To simplify parsing logs generated via covalent, we have added covalent logs as a CLI command. Users can now simply execute covalent logs to print all logs generated by covalent to stdout.

🩹 Known issues

• covalent restart does not store the state of the active execution mode/compute backend. In essence, running covalent restart after covalent start or covalent start --no-cluster always defaults the compute backend to Dask.
• When the following commands are chained: covalent start && covalent stop && covalent start --no-cluster, Dask Execution is still activated, despite specifying the --no-cluster option. To prevent this behavior, users should run covalent purge in between covalent start and covalent start --no-cluster if they wish to switch between Dask Execution and Local Execution.
• After running covalent start in a jupyter notebook, then switching to covalent start --no-cluster and running the same cell, execution is still attempted to be made with Dask resulting in an error. To prevent this behavior, please run covalent start --no-cluster in a different cell or refresh the notebook.
• At times when there is a burst of workflow dispatches to the server, writing the final result object to the database gets skipped resulting in the UI not updating the workflow status properly.
• Executing !covalent start from a Jupyter notebook cell results in the server not starting properly. Instead run covalent start from a terminal.
• If covalent-dask-plugin is installed in the user's environment, execution of workflows fails as the Dask executor is unable to find the cluster's scheduler address. To prevent this behavior, please uninstall covalent-dask-plugin as it is no longer shipped as a separate package.
• When dispatching Leptons, the python wrapper code gets rendered to the UI instead of the Lepton's source.
• Due to Dask's default serialization protocol, using QAOA optimizer from Pennylane fails.
• stdout/stderr is not redirected properly when using the DaskExecutor. To work around this, either avoid using print statements in electrons or run any electrons with print statements using the local executor.
• Setting executor="local" for an electron when running Covalent with Dask does not result in local execution

Contributors

This release would not have been possible without the hard work of the team at Agnostiq and our contributors:
@AgnostiqHQ , @mshkanth, @Prasy12