LabVIEW调用Python程序时scipy.optimize.differential_evolution方法报错问题求助

Let's break down what's happening here and how to fix it:

Root Cause #

The error occurs because you're using workers=2 in differential_evolution, which triggers multiprocessing to parallelize the optimization. On Windows (your environment), Python's multiprocessing uses the spawn start method by default. When spawning a new process, it tries to access sys.argv to replicate the parent process's launch context—but LabVIEW's Python Node doesn't initialize sys.argv when starting the Python interpreter (since it's not launching Python via a command line with arguments). This missing attribute causes the AttributeError in the child process.

Your observation that disabling the method (or removing multiprocessing by setting workers=1) fixes the error confirms this is the core issue.

Solutions #

1. Disable Multiprocessing (Quickest Fix)

If parallelization isn't strictly necessary for your use case, simply set workers=1 to run the optimization in a single process. This avoids the multiprocessing sys.argv issue entirely:

result = sp_opt.differential_evolution(
    func=myClass.deviation,
    bounds=optimization_bounds,
    args=[[empiric_set, funcs, False]],
    strategy='best1bin',
    maxiter=10,
    tol=0.0001,
    popsize=30,
    mutation=0.35,
    recombination=0.7,
    workers=1  # Disable multiprocessing here
)

2. Manually Initialize sys.argv (Keep Parallelization)

If you need the performance boost from parallel processing, add a small snippet at the very top of your Python script to ensure sys.argv exists before any multiprocessing is triggered:

import sys

# Ensure sys.argv exists even when launched from LabVIEW
if not hasattr(sys, 'argv'):
    sys.argv = ['']  # Dummy argument list to satisfy multiprocessing

This gives the multiprocessing module a valid sys.argv to work with when spawning child processes, eliminating the attribute error.

Why This Works #

LabVIEW's Python Node embeds the Python interpreter directly rather than launching it via a command prompt, so sys.argv (which normally holds command-line arguments) is never initialized. The multiprocessing module relies on this attribute to set up child processes correctly on Windows—adding a dummy sys.argv bypasses this requirement.

内容的提问来源于stack exchange，提问作者Leo