Components Wear Examples

Components Wear Examples

Файлы: examples/components_wear/example.py, example_objects_simulate.py, example_objects_simulate_ray.py. Данные: examples/components_wear/data/graph.json (граф из двух узлов A/B, по 4 компонента в каждом, с одной зависимостью B→A) и data/object.json (конкретный объект: компонент A2 с износом 22000 и B1 с износом 63000).

example_objects_simulate_ray.py — единственный пример во всём репозитории, явно включённый в run.sh (все остальные строки там закомментированы).

example.py — ⚠️ падает с ошибкой

graph = ComponentsGraph(graph_test)
component_object = ComponentsObject(component_object_test)

print(component_object())                              # OK
print(component_object.get_probabilities(graph))         # OK
print(graph.simulate_objects_bn())                        # OK

component_object.update_wear(graph, 10000)                # ❌ AttributeError

Строка component_object.update_wear(graph, 10000) воспроизводит известный баг фреймворка: ComponentsObject.update_wear() вызывает несуществующий метод _get_wear_dict() (опечатка, в классе определён _get__dict()). Скрипт падает именно на этом месте — последующие строки (predict_fix, повторный get_probabilities) не выполняются. Подробности и обходной путь — на странице Components Wear в книге «Документация MLumina», раздел «Известная поломка update_wear и predict_fix».

Первые три вызова в скрипте — рабочий, самодостаточный пример использования ComponentsGraph/ComponentsObject.get_probabilities/simulate_objects_bn.

example_objects_simulate.py — рабочий пример, без Ray

graph = ComponentsGraph(graph_test)
brakes = graph.simulate_objects(n_objects=10000, total_wearout=10000000, step=1000, seed=42, fix_coeff=1.0)

print(f"Broken parts: {len(brakes)}")
print(brakes.head())

Симулирует 10 000 независимых объектов на графе из graph.json, каждый "проезжает" 10 000 000 условных единиц износа с шагом 1000. Возвращает pandas.DataFrame со всеми зафиксированными отказами (колонки failed_node, wear, all_parts). Объект, загруженный из object.json (component_object_test), в этом скрипте создаётся, но не используется — вся работа идёт через graph.simulate_objects(...), который сам генерирует случайные объекты внутри себя (см. страницу Components Wear в «Документация MLumina»: simulate_objects не принимает готовый ComponentsObject, а строит собственные случайные объекты на каждой итерации).

При таком объёме (10 000 объектов × 10 000 шагов) выполнение может занимать заметное время на одном процессе — отсюда мотивация для следующего примера.

example_objects_simulate_ray.py — тот же сценарий через Ray

ray.init("ray://localhost:10001")
...
brakes = graph.simulate_objects_ray(n_objects=10000, total_wearout=10000000, step=1000, seed=42, fix_coeff=1.0)

Идентичные параметры симуляции, но каждый из 10 000 объектов считается в отдельной Ray-задаче (@ray.remote) — распараллеливается на все воркеры кластера. Подключается напрямую к Ray Client Server (ray://localhost:10001 — порт HEADNODEPORT из .env, при запуске не из Docker-сети нужно, чтобы этот порт был проброшен на хост, что и происходит в docker-compose.yml).

Как запустить

# без Ray (медленнее, но не требует кластера)
python examples/components_wear/example_objects_simulate.py

# с Ray (нужен поднятый кластер, порт HEADNODEPORT=10001 должен быть доступен)
python examples/components_wear/example_objects_simulate_ray.py

example.py можно запускать только чтобы увидеть первые три рабочих вызова — на update_wear он предсказуемо упадёт, пока баг не исправлен в коде.