Pymoo 并行化评估指南用 Starmap 与 Joblib 为 ElementwiseProblem 加速昂贵适应度计算【免费下载链接】scientific-agent-skillsTurn any AI agent into an AI Scientist. The #1 Agent Skills library for science, used by 190,000 scientists worldwide. 165 ready-to-use validated skills plus 100 scientific databases covering biology, chemistry, medicine, and drug discovery. Compatible with Cursor, Claude Code, Codex, Pi, Antigravity, and the open Agent Skills standard.项目地址: https://gitcode.com/GitHub_Trending/cl/scientific-agent-skillsPymoo 是当前仓库 pymoo 技能 主打的单目标与多目标优化框架当前稳定版本 0.6.1.6。当你的自定义问题以ElementwiseProblem形式定义、且单次_evaluate调用成本很高例如仿真、机器学习推理、外部求解器时Pymoo 默认一次只评估一个解整个进化算法的速度会被逐个评估串行拖垮。本指南基于技能库参考文档 references/parallelization.md 展开完整讲解elementwise_runner的两种注入方式——基于multiprocessing.Pool.starmap的StarmapParallelization线程池 / 进程池与基于 joblib 的JoblibParallelization并给出可复制运行的完整代码、选择依据与常见陷阱。读完后你可以在 10 分钟内把串行评估的自定义优化问题改造成并行版本直接用于真实工程场景。一、为什么需要并行化理解 ElementwiseProblem 的评估瓶颈1.1 三种问题定义风格中为什么是 ElementwiseProblemPymoo 支持三种问题定义风格见 SKILL.md 的 Core Concepts 小节风格评估方式适用场景Problem向量化——_evaluate一次性接收一批解的矩阵纯数值计算、可批量矢量化的目标函数ElementwiseProblem逐解评估——每次_evaluate只处理一个解自定义问题、需要并行化的昂贵评估FunctionalProblem用独立函数定义目标与约束无需继承类函数式定义的简单问题关键区别在于ElementwiseProblem的_evaluate(self, x, out, *args, **kwargs)中x是单个解一维数组而向量化Problem的_evaluate中X是整个批次二维矩阵。参考文档明确指出Pymoo evaluates one solution per_evaluatecall forElementwiseProblem; pass a runner to evaluate multiple solutions concurrently.也就是说进化算法每一代都需要评估整个种群而ElementwiseProblem会将这些评估逐个串行执行。当单次评估很昂贵时一次 CFD 仿真几秒钟、一次模型推理几百毫秒串行等待就是整个优化流程的最大瓶颈。并行化的目标正是把一次一个解变成一次并发多个解。仓库中的自定义问题示例 scripts/custom_problem_example.py 展示了ElementwiseProblem的标准写法——在__init__中声明n_var、n_obj、n_ieq_constr、xl/xu在_evaluate中填充out[F]目标值、out[G]不等式约束约定g(x) 0为可行与out[H]等式约束约定h(x) 0。1.2 何时该启用并行化参考文档给出的判断标准非常明确当_evaluate是瓶颈时。典型场景包括仿真模拟有限元、流体力学、分子动力学等单次运行耗时秒级到分钟级机器学习推理每次评估需要加载模型并对输入做一次前向传播外部求解器评估需要调用第三方求解器、命令行工具或远程服务。如果_evaluate只是(x ** 2).sum()这类纯算数运算如示例脚本 scripts/single_objective_example.py 中的 Sphere 函数并行化的线程调度、进程通信开销反而可能超过计算本身收益趋近于零甚至为负。二、启用并行化的三个硬性前提参考文档在 Requirements 一节给出了必须满足的三个条件缺一不可必须继承ElementwiseProblem而不是向量化的Problem。并行 runner 的契约是每个 worker 处理一个解只有逐解评估的问题定义才符合这个模型设置elementwise_evaluationTrue。这是ElementwiseProblem的默认值因此一般不需要显式写出——只要你继承的是ElementwiseProblem该选项自动生效把 runner 通过elementwise_runner参数传给问题构造函数。这是接入并行化的唯一入口。三、Starmap 接口一套代码线程池 / 进程池通吃StarmapParallelization位于pymoo.parallelization.starmap它复用的是 Python 标准库multiprocessing.Pool.starmap的函数签名——因此任何提供starmap(func, iterable)接口的池对象ThreadPool或Pool都可以直接注入。3.1 第一步定义一个可注入 runner 的自定义问题问题类需要把elementwise_runner透传给父类构造函数这是参考文档给出的标准骨架from pymoo.core.problem import ElementwiseProblem class MyProblem(ElementwiseProblem): def __init__(self, elementwise_runnerNone, **kwargs): super().__init__( n_var10, n_obj1, xl-5, xu5, elementwise_runnerelementwise_runner, **kwargs, ) def _evaluate(self, x, out, *args, **kwargs): out[F] (x ** 2).sum() # 替换为真正昂贵的评估逻辑这里的**kwargs透传很重要它允许 pymoo 内部在需要时注入其他问题级参数也让你不必在每次构造时重复声明维度信息。3.2 线程池方案适合 I/O 密集型评估当评估的瓶颈是等待外部资源网络请求、文件读取、数据库查询而非 CPU 计算时线程池即可获得良好并行度且线程共享进程内存无需序列化传递问题对象import multiprocessing from multiprocessing.pool import ThreadPool from pymoo.algorithms.soo.nonconvex.ga import GA from pymoo.core.problem import ElementwiseProblem from pymoo.optimize import minimize from pymoo.parallelization.starmap import StarmapParallelization # 线程池共享内存适合 I/O 密集型评估 n_threads 4 pool ThreadPool(n_threads) runner StarmapParallelization(pool.starmap) problem MyProblem(elementwise_runnerrunner) result minimize(problem, GA(), (n_gen, 50), seed1) pool.close()3.3 进程池方案适合 CPU 密集型评估当评估消耗大量 CPU数值仿真、模型推理的计算部分时线程受 GIL 限制无法充分利用多核应改用multiprocessing.Pool。每个进程拥有独立的内存空间可以真正并行执行 Python 代码# 进程池独立内存适合 CPU 密集型评估 n_processes 4 pool multiprocessing.Pool(n_processes) runner StarmapParallelization(pool.starmap) problem MyProblem(elementwise_runnerrunner) result minimize(problem, GA(), (n_gen, 50), seed1) pool.close()minimize()的其余部分与串行版本完全一致问题、算法这里使用单目标非凸 GA、终止条件(n_gen, 50)最多 50 代以及可复现随机种子seed1。关于minimize()的统一接口与result对象result.X决策变量、result.F目标值、result.G约束违反可参见 quick_start_workflows.md 的 Workflow 1/4。3.4 底层原理starmap 契约StarmapParallelization之所以叫 Starmap是因为它接受任意满足starmap(func, iterable)签名的池对象池会将迭代器中的每一组参数解包*args后调用func。在 pymoo 的并行评估流程中主进程把一批待评估的解分发给 runnerrunner 通过pool.starmap将它们并发地交给各 worker 执行_evaluate再把结果汇总回out字典。由于接口只依赖starmap这一个方法你甚至可以用任何实现了该接口的自定义调度器如基于 Dask 的 runner替换内置实现——这也是 quick_start_workflows.md 中 Workflow 8 提到threads, processes, or Dask的依据。四、Joblib 接口更灵活的备选方案JoblibParallelization位于pymoo.parallelization.joblib是参考文档给出的第二种并行注入方式。它的优势在于可以使用 joblib 的完整能力按任务自动选择loky/threading后端、内存映射mmap_mode共享大数组、以及更精细的任务批处理控制from joblib import Parallel, delayed from pymoo.parallelization.joblib import JoblibParallelization runner JoblibParallelization( lambda func, X: Parallel(n_jobs4)(delayed(func)(x) for x in X) ) problem MyProblem(elementwise_runnerrunner)这里的 lambda 定义了一个接收函数与解集合、返回并行结果列表的映射规则Parallel(n_jobs4)启动 4 个 workerdelayed(func)(x)把每个解x分派给func即 pymoo 内部包装的评估函数。调整n_jobs即可控制并行度。joblib 不在 pymoo 的默认依赖里需要单独安装SKILL.md 的 compatibility 字段也将 joblib 标注为可选依赖uv pip install joblib完整环境安装pymoo 本体同样通过 uv 完成可固定版本以获得可复现环境uv pip install pymoo uv pip install pymoo0.6.1.6五、线程池 vs 进程池如何选择维度线程池ThreadPool进程池multiprocessing.Pool内存模型共享进程内存每 worker 独立内存适用负载I/O 密集型等待外部资源CPU 密集型数值计算、仿真对象传递无需序列化问题定义必须可 picklePython 代码并行度受 GIL 限制真正的多核并行启动开销低较高进程 fork/spawn选择要点如果你的_evaluate大部分时间在等待网络、磁盘、外部服务线程池足够且更轻量如果它在高强度计算 Python 代码进程池才能榨干多核。两者的接入代码只有pool ThreadPool(...)与pool multiprocessing.Pool(...)一行之差切换成本极低建议针对实际负载做一次基准测试。六、关键注意事项与常见坑参考文档的 Notes 一节总结了四条必须遵守的规则结合源码实现可以进一步展开6.1 每次运行结束都要关闭池minimize()返回后池对象仍然持有 worker 资源必须显式调用pool.close()以及需要时pool.join()释放否则进程/线程会滞留在长流程或循环调用中积累成资源泄漏。参考文档与 Workflow 8 的所有示例都在minimize()之后立即关闭池。6.2 进程池要求问题定义可 picklemultiprocessing.Pool通过 pickle 序列化把问题对象发给各 worker 进程因此避免在类体内使用 lambda——lambda 无法被 pickle避免局部定义的类、闭包捕获不可序列化对象在 Linux 等使用 fork 启动的平台上进程池从父进程复制内存快照问题相对宽松但在 Windows 等 spawn 平台上模块顶层必须受if __name__ __main__:保护否则子进程会重复执行模块代码。参考文档的表述是Process pools require picklable problem definitions (avoid lambdas in class bodies)即问题是worker 需要看懂的对象务必保证它能被序列化往返一次。6.3 并行收益取决于评估成本与开销之比并行化不是免费的线程调度、任务分发、结果收集以及进程池的序列化都是固定开销。只有当单次_evaluate的成本显著高于这些开销时加速比才接近理想值受 Amdahl 定律约束并行部分占比越高、加速越明显。这也呼应了参考文档Use parallelization when_evaluateis the bottleneck的判断——把昂贵仿真与纯算术(x ** 2).sum()一视同仁地并行化是没有意义的。6.4 向量化问题不要用 runner直接在_evaluate内分批如果你的问题继承的是向量化Problem_evaluate接收整个批次的矩阵并行 runner 并不适用。参考文档明确指出这类情况应在_evaluate内部自行实现批处理batching——例如在单个函数内对矩阵行做for循环或利用 NumPy 广播让向量化与并行化各归其位。6.5 与整体优化流程的配合并行化只改变评估怎么执行不改变算法的搜索逻辑。你依然可以用seed1固定随机种子保证可复现性仓库测试 tests/pymoo/test_scripts.py 专门验证了同种子两次运行结果一致用(n_gen, 50)或get_termination(f_tol, tol0.001)控制终止条件为 GA 配置算子和种群参数例如 scripts/single_objective_example.py 中的GA(pop_size100, samplingFloatRandomSampling(), crossoverSBX(prob0.9, eta15), mutationPM(eta20), eliminate_duplicatesTrue)评估循环中每个候选解的_evaluate仍按out[F]、out[G]、out[H]返回目标与约束。七、在技能库中的定位Workflow 8 与配套资源并行化是 quick_start_workflows.md 九个可运行工作流中的 Workflow 8Parallel Evaluation它的适用条件、线程池示例与本文一致并明确指向本参考文档获取进程池、joblib 与 pickling 细节。本技能还提供五个可直接运行的可执行示例脚本python3 scripts/single_objective_example.py # 单目标优化GA Sphere python3 scripts/multi_objective_example.py # 多目标优化NSGA-II ZDT1 python3 scripts/many_objective_example.py # 多目标优化NSGA-III DTLZ2 python3 scripts/custom_problem_example.py # 自定义问题含约束 python3 scripts/decision_making_example.py # 多准则决策PseudoWeights这些脚本位于 skills/pymoo/scripts/ 目录仓库测试 tests/pymoo/test_scripts.py 会对它们逐一执行验证包括验证评估预算pop_size * n_gen、ZDT1 解析前沿f2 1 - sqrt(f1)、NSGA-II 结果集互不支配等性质。把并行化的elementwise_runner接入上述任一ElementwiseProblem场景如自定义问题示例 scripts/custom_problem_example.py 中的MyBiObjectiveProblem/ConstrainedProblem即可在保持优化语义不变的前提下获得并发评估能力。实践建议总结先确认评估确实昂贵这是前提再确认问题是ElementwiseProblem且没有显式关闭elementwise_evaluation然后按负载类型选择线程池或进程池通过StarmapParallelization或JoblibParallelization注入elementwise_runner最后别忘了在minimize()之后关闭池并保证进程池场景下问题对象可 pickle。按此流程改造即可为昂贵的仿真、推理与外部求解器类优化问题带来立竿见影的吞吐提升。【免费下载链接】scientific-agent-skillsTurn any AI agent into an AI Scientist. The #1 Agent Skills library for science, used by 190,000 scientists worldwide. 165 ready-to-use validated skills plus 100 scientific databases covering biology, chemistry, medicine, and drug discovery. Compatible with Cursor, Claude Code, Codex, Pi, Antigravity, and the open Agent Skills standard.项目地址: https://gitcode.com/GitHub_Trending/cl/scientific-agent-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Pymoo 并行化评估指南：用 Starmap 与 Joblib 为 ElementwiseProblem 加速昂贵适应度计算
Pymoo 并行化评估指南用 Starmap 与 Joblib 为 ElementwiseProblem 加速昂贵适应度计算【免费下载链接】scientific-agent-skillsTurn any AI agent into an AI Scientist. The #1 Agent Skills library for science, used by 190,000 scientists worldwide. 165 ready-to-use validated skills plus 100 scientific databases covering biology, chemistry, medicine, and drug discovery. Compatible with Cursor, Claude Code, Codex, Pi, Antigravity, and the open Agent Skills standard.项目地址: https://gitcode.com/GitHub_Trending/cl/scientific-agent-skillsPymoo 是当前仓库 pymoo 技能 主打的单目标与多目标优化框架当前稳定版本 0.6.1.6。当你的自定义问题以ElementwiseProblem形式定义、且单次_evaluate调用成本很高例如仿真、机器学习推理、外部求解器时Pymoo 默认一次只评估一个解整个进化算法的速度会被逐个评估串行拖垮。本指南基于技能库参考文档 references/parallelization.md 展开完整讲解elementwise_runner的两种注入方式——基于multiprocessing.Pool.starmap的StarmapParallelization线程池 / 进程池与基于 joblib 的JoblibParallelization并给出可复制运行的完整代码、选择依据与常见陷阱。读完后你可以在 10 分钟内把串行评估的自定义优化问题改造成并行版本直接用于真实工程场景。一、为什么需要并行化理解 ElementwiseProblem 的评估瓶颈1.1 三种问题定义风格中为什么是 ElementwiseProblemPymoo 支持三种问题定义风格见 SKILL.md 的 Core Concepts 小节风格评估方式适用场景Problem向量化——_evaluate一次性接收一批解的矩阵纯数值计算、可批量矢量化的目标函数ElementwiseProblem逐解评估——每次_evaluate只处理一个解自定义问题、需要并行化的昂贵评估FunctionalProblem用独立函数定义目标与约束无需继承类函数式定义的简单问题关键区别在于ElementwiseProblem的_evaluate(self, x, out, *args, **kwargs)中x是单个解一维数组而向量化Problem的_evaluate中X是整个批次二维矩阵。参考文档明确指出Pymoo evaluates one solution per_evaluatecall forElementwiseProblem; pass a runner to evaluate multiple solutions concurrently.也就是说进化算法每一代都需要评估整个种群而ElementwiseProblem会将这些评估逐个串行执行。当单次评估很昂贵时一次 CFD 仿真几秒钟、一次模型推理几百毫秒串行等待就是整个优化流程的最大瓶颈。并行化的目标正是把一次一个解变成一次并发多个解。仓库中的自定义问题示例 scripts/custom_problem_example.py 展示了ElementwiseProblem的标准写法——在__init__中声明n_var、n_obj、n_ieq_constr、xl/xu在_evaluate中填充out[F]目标值、out[G]不等式约束约定g(x) 0为可行与out[H]等式约束约定h(x) 0。1.2 何时该启用并行化参考文档给出的判断标准非常明确当_evaluate是瓶颈时。典型场景包括仿真模拟有限元、流体力学、分子动力学等单次运行耗时秒级到分钟级机器学习推理每次评估需要加载模型并对输入做一次前向传播外部求解器评估需要调用第三方求解器、命令行工具或远程服务。如果_evaluate只是(x ** 2).sum()这类纯算数运算如示例脚本 scripts/single_objective_example.py 中的 Sphere 函数并行化的线程调度、进程通信开销反而可能超过计算本身收益趋近于零甚至为负。二、启用并行化的三个硬性前提参考文档在 Requirements 一节给出了必须满足的三个条件缺一不可必须继承ElementwiseProblem而不是向量化的Problem。并行 runner 的契约是每个 worker 处理一个解只有逐解评估的问题定义才符合这个模型设置elementwise_evaluationTrue。这是ElementwiseProblem的默认值因此一般不需要显式写出——只要你继承的是ElementwiseProblem该选项自动生效把 runner 通过elementwise_runner参数传给问题构造函数。这是接入并行化的唯一入口。三、Starmap 接口一套代码线程池 / 进程池通吃StarmapParallelization位于pymoo.parallelization.starmap它复用的是 Python 标准库multiprocessing.Pool.starmap的函数签名——因此任何提供starmap(func, iterable)接口的池对象ThreadPool或Pool都可以直接注入。3.1 第一步定义一个可注入 runner 的自定义问题问题类需要把elementwise_runner透传给父类构造函数这是参考文档给出的标准骨架from pymoo.core.problem import ElementwiseProblem class MyProblem(ElementwiseProblem): def __init__(self, elementwise_runnerNone, **kwargs): super().__init__( n_var10, n_obj1, xl-5, xu5, elementwise_runnerelementwise_runner, **kwargs, ) def _evaluate(self, x, out, *args, **kwargs): out[F] (x ** 2).sum() # 替换为真正昂贵的评估逻辑这里的**kwargs透传很重要它允许 pymoo 内部在需要时注入其他问题级参数也让你不必在每次构造时重复声明维度信息。3.2 线程池方案适合 I/O 密集型评估当评估的瓶颈是等待外部资源网络请求、文件读取、数据库查询而非 CPU 计算时线程池即可获得良好并行度且线程共享进程内存无需序列化传递问题对象import multiprocessing from multiprocessing.pool import ThreadPool from pymoo.algorithms.soo.nonconvex.ga import GA from pymoo.core.problem import ElementwiseProblem from pymoo.optimize import minimize from pymoo.parallelization.starmap import StarmapParallelization # 线程池共享内存适合 I/O 密集型评估 n_threads 4 pool ThreadPool(n_threads) runner StarmapParallelization(pool.starmap) problem MyProblem(elementwise_runnerrunner) result minimize(problem, GA(), (n_gen, 50), seed1) pool.close()3.3 进程池方案适合 CPU 密集型评估当评估消耗大量 CPU数值仿真、模型推理的计算部分时线程受 GIL 限制无法充分利用多核应改用multiprocessing.Pool。每个进程拥有独立的内存空间可以真正并行执行 Python 代码# 进程池独立内存适合 CPU 密集型评估 n_processes 4 pool multiprocessing.Pool(n_processes) runner StarmapParallelization(pool.starmap) problem MyProblem(elementwise_runnerrunner) result minimize(problem, GA(), (n_gen, 50), seed1) pool.close()minimize()的其余部分与串行版本完全一致问题、算法这里使用单目标非凸 GA、终止条件(n_gen, 50)最多 50 代以及可复现随机种子seed1。关于minimize()的统一接口与result对象result.X决策变量、result.F目标值、result.G约束违反可参见 quick_start_workflows.md 的 Workflow 1/4。3.4 底层原理starmap 契约StarmapParallelization之所以叫 Starmap是因为它接受任意满足starmap(func, iterable)签名的池对象池会将迭代器中的每一组参数解包*args后调用func。在 pymoo 的并行评估流程中主进程把一批待评估的解分发给 runnerrunner 通过pool.starmap将它们并发地交给各 worker 执行_evaluate再把结果汇总回out字典。由于接口只依赖starmap这一个方法你甚至可以用任何实现了该接口的自定义调度器如基于 Dask 的 runner替换内置实现——这也是 quick_start_workflows.md 中 Workflow 8 提到threads, processes, or Dask的依据。四、Joblib 接口更灵活的备选方案JoblibParallelization位于pymoo.parallelization.joblib是参考文档给出的第二种并行注入方式。它的优势在于可以使用 joblib 的完整能力按任务自动选择loky/threading后端、内存映射mmap_mode共享大数组、以及更精细的任务批处理控制from joblib import Parallel, delayed from pymoo.parallelization.joblib import JoblibParallelization runner JoblibParallelization( lambda func, X: Parallel(n_jobs4)(delayed(func)(x) for x in X) ) problem MyProblem(elementwise_runnerrunner)这里的 lambda 定义了一个接收函数与解集合、返回并行结果列表的映射规则Parallel(n_jobs4)启动 4 个 workerdelayed(func)(x)把每个解x分派给func即 pymoo 内部包装的评估函数。调整n_jobs即可控制并行度。joblib 不在 pymoo 的默认依赖里需要单独安装SKILL.md 的 compatibility 字段也将 joblib 标注为可选依赖uv pip install joblib完整环境安装pymoo 本体同样通过 uv 完成可固定版本以获得可复现环境uv pip install pymoo uv pip install pymoo0.6.1.6五、线程池 vs 进程池如何选择维度线程池ThreadPool进程池multiprocessing.Pool内存模型共享进程内存每 worker 独立内存适用负载I/O 密集型等待外部资源CPU 密集型数值计算、仿真对象传递无需序列化问题定义必须可 picklePython 代码并行度受 GIL 限制真正的多核并行启动开销低较高进程 fork/spawn选择要点如果你的_evaluate大部分时间在等待网络、磁盘、外部服务线程池足够且更轻量如果它在高强度计算 Python 代码进程池才能榨干多核。两者的接入代码只有pool ThreadPool(...)与pool multiprocessing.Pool(...)一行之差切换成本极低建议针对实际负载做一次基准测试。六、关键注意事项与常见坑参考文档的 Notes 一节总结了四条必须遵守的规则结合源码实现可以进一步展开6.1 每次运行结束都要关闭池minimize()返回后池对象仍然持有 worker 资源必须显式调用pool.close()以及需要时pool.join()释放否则进程/线程会滞留在长流程或循环调用中积累成资源泄漏。参考文档与 Workflow 8 的所有示例都在minimize()之后立即关闭池。6.2 进程池要求问题定义可 picklemultiprocessing.Pool通过 pickle 序列化把问题对象发给各 worker 进程因此避免在类体内使用 lambda——lambda 无法被 pickle避免局部定义的类、闭包捕获不可序列化对象在 Linux 等使用 fork 启动的平台上进程池从父进程复制内存快照问题相对宽松但在 Windows 等 spawn 平台上模块顶层必须受if __name__ __main__:保护否则子进程会重复执行模块代码。参考文档的表述是Process pools require picklable problem definitions (avoid lambdas in class bodies)即问题是worker 需要看懂的对象务必保证它能被序列化往返一次。6.3 并行收益取决于评估成本与开销之比并行化不是免费的线程调度、任务分发、结果收集以及进程池的序列化都是固定开销。只有当单次_evaluate的成本显著高于这些开销时加速比才接近理想值受 Amdahl 定律约束并行部分占比越高、加速越明显。这也呼应了参考文档Use parallelization when_evaluateis the bottleneck的判断——把昂贵仿真与纯算术(x ** 2).sum()一视同仁地并行化是没有意义的。6.4 向量化问题不要用 runner直接在_evaluate内分批如果你的问题继承的是向量化Problem_evaluate接收整个批次的矩阵并行 runner 并不适用。参考文档明确指出这类情况应在_evaluate内部自行实现批处理batching——例如在单个函数内对矩阵行做for循环或利用 NumPy 广播让向量化与并行化各归其位。6.5 与整体优化流程的配合并行化只改变评估怎么执行不改变算法的搜索逻辑。你依然可以用seed1固定随机种子保证可复现性仓库测试 tests/pymoo/test_scripts.py 专门验证了同种子两次运行结果一致用(n_gen, 50)或get_termination(f_tol, tol0.001)控制终止条件为 GA 配置算子和种群参数例如 scripts/single_objective_example.py 中的GA(pop_size100, samplingFloatRandomSampling(), crossoverSBX(prob0.9, eta15), mutationPM(eta20), eliminate_duplicatesTrue)评估循环中每个候选解的_evaluate仍按out[F]、out[G]、out[H]返回目标与约束。七、在技能库中的定位Workflow 8 与配套资源并行化是 quick_start_workflows.md 九个可运行工作流中的 Workflow 8Parallel Evaluation它的适用条件、线程池示例与本文一致并明确指向本参考文档获取进程池、joblib 与 pickling 细节。本技能还提供五个可直接运行的可执行示例脚本python3 scripts/single_objective_example.py # 单目标优化GA Sphere python3 scripts/multi_objective_example.py # 多目标优化NSGA-II ZDT1 python3 scripts/many_objective_example.py # 多目标优化NSGA-III DTLZ2 python3 scripts/custom_problem_example.py # 自定义问题含约束 python3 scripts/decision_making_example.py # 多准则决策PseudoWeights这些脚本位于 skills/pymoo/scripts/ 目录仓库测试 tests/pymoo/test_scripts.py 会对它们逐一执行验证包括验证评估预算pop_size * n_gen、ZDT1 解析前沿f2 1 - sqrt(f1)、NSGA-II 结果集互不支配等性质。把并行化的elementwise_runner接入上述任一ElementwiseProblem场景如自定义问题示例 scripts/custom_problem_example.py 中的MyBiObjectiveProblem/ConstrainedProblem即可在保持优化语义不变的前提下获得并发评估能力。实践建议总结先确认评估确实昂贵这是前提再确认问题是ElementwiseProblem且没有显式关闭elementwise_evaluation然后按负载类型选择线程池或进程池通过StarmapParallelization或JoblibParallelization注入elementwise_runner最后别忘了在minimize()之后关闭池并保证进程池场景下问题对象可 pickle。按此流程改造即可为昂贵的仿真、推理与外部求解器类优化问题带来立竿见影的吞吐提升。【免费下载链接】scientific-agent-skillsTurn any AI agent into an AI Scientist. The #1 Agent Skills library for science, used by 190,000 scientists worldwide. 165 ready-to-use validated skills plus 100 scientific databases covering biology, chemistry, medicine, and drug discovery. Compatible with Cursor, Claude Code, Codex, Pi, Antigravity, and the open Agent Skills standard.项目地址: https://gitcode.com/GitHub_Trending/cl/scientific-agent-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
