Unable to Implement Workflow Class due to functions lacking attribute '_run_types'

[Jake-Ankrum]

Nanopyx Team,

Thank you for your thorough documentation and expansive library of high quality code. I have been testing several features of the library and ran into an issue with the Workflow class. When I try to wrap different functions, including their args and kwargs, from the Methods folder within the Workflow instance, I run into an attribute error stating that the 'function' object has no attribute '_run_types'. Perhaps, I am using functions incompatible with the Workflow class.

Below is the block of code raising the issue and the traceback:

I was hoping to use a Workflow instance to streamline my multi-step analysis (drift correction -> parameter sweep -> eSRRF), and would appreciate any pointers on implementation.

At the same time, the agent appears to chose random run types (often landing on threaded_guided despite significantly longer run times) for parameter sweep and drift correction functions, so I was hoping there might be a method to globally force a run type if the Workflow Class is incompatible with the Methods functions I am using. Any clarification/guidance would be much appreciate!

Thank you for your time,

Jake

[brunomsaraiva]

Hi @Jake-Ankrum,

Thank you for reaching out.

At the moment, the Workflow class expects its steps to be instances of classes that inherit from the Liquid Engine. The run_parameter_sweep function is not a Liquid Engine instance, which causes the Workflow class to look for the _run_types attribute. This attribute is specific to Liquid Engine classes and is what enables automatic selection between different run types. Since run_parameter_sweep does not define _run_types, the workflow fails at that point.

If this would be useful, we can consider extending the Workflow class in a future release to support non-Liquid Engine instances or direct function calls.

For your proposed multi-step analysis, it may be simpler and more flexible to encapsulate the workflow in a high-level function instead. For example:

import nanopyx as npx
from nanopyx.methods.drift_alignment import DriftEstimator


def drift_sweep_esrrf(
    image,
    drift_params=None,
    magnification=5,
    sensitivities=(1, 2),
    radii=(1, 1.5),
    temporal_correlation="AVG",
    force_run_type=None,
):
    drift_params = {} if drift_params is None else drift_params.copy()
    drift_params["apply"] = True

    # 1. Drift correction
    drift_corrected = DriftEstimator().estimate(image, **drift_params)

    # 2. Parameter sweep
    sensitivity, radius = npx.run_esrrf_parameter_sweep(
        drift_corrected,
        magnification=magnification,
        sensitivities=list(sensitivities),
        radii=list(radii),
        temporal_correlation=temporal_correlation,
        plot_sweep=False,
        return_qnr=False,
    )

    # 3. eSRRF with selected parameters
    sr_image = npx.eSRRF(
        drift_corrected,
        magnification=magnification,
        sensitivity=sensitivity,
        radius=radius,
        temporal_correlation=temporal_correlation,
        _force_run_type=force_run_type,
    )

    return sr_image, {
        "drift_corrected": drift_corrected,
        "sensitivity": sensitivity,
        "radius": radius,
    }

Regarding automatic run_type selection: until there are at least three benchmarked values on your machine, the Liquid Engine will rely on the default benchmarks that we ship with the package. Those defaults may not be optimal for your specific setup.

You have two options:

1. Select the run_type manually using the _force_run_type argument. Please note that this is not currently implemented across the full parameter sweep.
2. Benchmark the eSRRF function on your machine, which should provide the best automatic selection for your setup.

For example:

import numpy as np
from nanopyx.core.transform import eSRRF_ST

# Synthetic test stack: frames, height, width
image = np.random.random((50, 128, 128)).astype(np.float32)

# eSRRF parameters
params = {
    "magnification": 5,
    "radius": 1.5,
    "sensitivity": 1,
    "doIntensityWeighting": True,
    "pad_edges": False,
}

esrrf = eSRRF_ST(verbose=True)

# Run Liquid Engine benchmarking for the available run types.
# Running this three times ensures these results superseed the default benchmarks.
for i in range(3):
    esrrf.benchmark(image, **params)

Running the benchmark three times for that parameter combination should ensure that Liquid Engine selects the most optimized available run type for your setup.

Let me know if this helps, or if there is anything else we can clarify.

[Jake-Ankrum]

Thank you for the quick reply Bruno,

It would make sense to implement a high level wrapper function in this regard. Thank you for taking the time to develop the framework of this approach, as I will likely implement something very similar.

I think that allowing the Workflow class to handle non-Liquid engine instances would extend its use-cases. Perhaps a try/except clause could handle the missing attribute. I would be happy to tweak the source code and submit a pull request. As a student, I am always looking to improve my computational skills by contributing to active repositories.

On another note, I have benchmarked the Liquid Engine for the eSRRF workflow and the agent will consistently chose opencl with a many fold faster than all of the threaded techniques. However, I noticed that with the run_esrrf_parameter_sweep function, the agent will only remember to run eSRRF_ST with opencl when ran consecutively in interactive mode using the ipykernel with VScode. If I execute the script in the terminal, the agent will restart its sweep of run types, sometimes taking many attempts to land on opencl. I am not sure how the agent stores run time information, but is it possible that this data is not being properly cached for the parameter sweep across terminal-based executions? Or maybe this was not the design intention and I apologize for raising a non-issue! Nevertheless, thank you for your help!