Refactored core #70
Refactored core #70
Conversation
serialization, mp4 visualization, GA & SEPA2 on new core. Now fitness evaluates only for changed structures.
…eGA. Update requirements (polygenerator)
* add ci flake config
cases/breakwaters/main_arctic.py
Outdated
| border = shape(border_dict['features'][0]['geometry']) | ||
| water = [i for i in res_list['features'] if i['properties']['type'] =='water'] | ||
| water_coord =[p['geometry']['coordinates'] for p in water] | ||
| cargo_piers = [i for i in res_list['features'] if i['properties']['type'] =='cargo_pier'] | ||
| passenger_pier = [i for i in res_list['features'] if i['properties']['type'] =='passenger_pier'] | ||
| piers = [i for i in res_list['features'] if (i['properties']['type']=='passenger_pier') or (i['properties']['type'] =='cargo_pier')] | ||
| piers_coords = [x[0] for x in [i['geometry']['coordinates'] for i in piers]] | ||
| piers_line = [max(p,key=lambda i: i[1]) for p in piers_coords] | ||
| unique_types = np.unique([i['properties']['type'] for i in res_list['features']]) | ||
| allow_water = [i for i in water_coord[0][0] if (i[0]>74.8) and (i[1]<67.942) and (i[1]>67.915)] | ||
| ########### | ||
| allow_area = [[74.80,67.92],[74.80,67.94]]+allow_water +[[74.80,67.92]] | ||
| grid_resolution_x = 17 # Number of points on x-axis | ||
| grid_resolution_y = 31 # Number of points on y-axis | ||
| coord_Y = np.linspace(min([p[1] for p in allow_area])*500, max([p[1] for p in allow_area])*500, grid_resolution_y + 1) # X coordinate for spatial grid | ||
| coord_X = np.linspace(min([p[0] for p in allow_area])*500, max([p[0] for p in allow_area])*500, grid_resolution_x + 1) | ||
| grid = [grid_resolution_x, grid_resolution_y] # points grid | ||
| fixed_area = None | ||
| targets = [[14,10],[16,10],[18,10]] |
There was a problem hiding this comment.
Тут напрашивается заварачивание в какую-то функцию, парсящую geojson
There was a problem hiding this comment.
Тут напрашивается заварачивание в какую-то функцию, парсящую geojson
Завернул в функцию. Теперь этот main находится в cases/breakwaters/arctic_config/acrtic_config.py.
А функция находится cases/breakwaters/utils.
| from loguru import logger | ||
|
|
||
|
|
||
| class BaseParallelDispatcher: |
There was a problem hiding this comment.
А это из GOLEM-а не взять?
There was a problem hiding this comment.
В GOLEM есть класс для параллельных вычислений, но он предназначен только для objective. Тогда как прочие операции вычисляются не параллельно, мутации например.
BaseParallelDispatcher же является утилитой "общего назначения", то есть ее можно применить почти к любой функции. Что собственно и реализовано в CrossoverStrategy и MutationStrategy. Отсюда следует очевидное преимущество в скорости вычислений. На примере multi objective синтетик кейса с кружками: вычисления занимают для GOLEM ≈54 секунды, для GEFEST ≈12 секунд.
Следующий момент - параллельное вычисление objective с физ. симулятором. В большинстве случаев на уровне кода библиотеки это оказывается бессмысленно или даже деструктивно. В частности, COMSOL и SWAN умеют использовать параллельные вычисления и сами, таким образом если сделать это еще и в коде, то не будет никакого прироста производительности. Клеточный симулятор звуковых волн же плохо поддается распараллеливанию в принципе, поскольку он хранит состояние и вычисляется итеративно. Таким образом как есть он не заработает параллельно, а если его подать в GOLEM оптимизатор и задать более 1 ядра, то вычисления и вовсе упадут.
There was a problem hiding this comment.
Тогда как прочие операции вычисляются не параллельно, мутации [например]
(https://github.com/aimclub/GOLEM/blob/main/golem/core/optimisers/genetic/operators/mutation.py#L84C69-L84C113).
А вот этот - не то что нужно aimclub/GOLEM#199? Пока ещё не в мастере.
There was a problem hiding this comment.
Эта штука явно сделает вычисления GOELM быстрее, но ей будет сложно и менее эффективно заменить BaseParallelDispatcher.
Для начала предлагаемый в aimclub/GOLEM#199 ReproduceWorker это параллелизм на уровне всего пайплайна репродукции, что на мой взгляд ограничивает гибкость и возможность расширения, и возможно будет работать медленнее чем параллелизм на уровне операций/функций.
Далее, одна из основных проблем совместимости GEFEST и GOLEM кроется в постпроцессинге, для которого в пайплайне оптимизации GOLEM нет отдельного шага, поэтому приходится прицеплять его к операциям мутации, кроссовера, и т.д. Теряется опция, например, не запускать постпроцессинг, если полученный индивид уже валиден, или удалось его исправить за меньшее число попыток, чем максимальное. В каждом случае параллельный запуск будет ждать самого долгого воркера. Замечу, что это пожалуй в значительной степени компенсируется за счет того, что сейчас в принципе редко порождаются невалидные индивиды, однако не факт что не появится такой кейс в будущем.
Ну и что касается интеграции ReproduceWorker в GEFEST, то речь пойдет именно об интеграции целиком шага репродукции, что имеет мало смысла, поскольку это тащит за собой все описанные выше недостатки, а так же требует по сути дублировать логику, реализованную в том же EvoGraphOptimizer.
Если рассмотреть проблему интеграции с GOLEM с точки зрения реализации новых алгоритмов, то если я правильно понимаю, их ключевую логику можно вынести в оператор селекции (речь про moead, nsga2, nsga3 и пр.), как это сделано в GOLEM для spea2. Тогда имеет смысл создать feature request на возможность добавлять пользовательские селекторы и просто реализовать нужные операции в GEFEST. Ну или даже контрибутить их сразу в GOLEM.
Таким образом полностью переехать на GOLEM в качестве бекенда эволюционной оптимизации мешает:
- Скорость вычислений
- Отсутствие постпроцессинга в пайплайне (сейчас решено последовательными вызовами)
- Невозможность добавить пользовательские функции селекции
Возможно что-то забыл, но это ключевые пункты.
There was a problem hiding this comment.
Ок.
Пока тогда пусть остается так, но создай в GOLEM-е issue по тому, чего не хватает.
There was a problem hiding this comment.
Сейчас в aimclub/GOLEM#199 реализован параллелизм на уровне операций.
Также планируется в этот же PR добавить функционал, который позволит составить свою схему подготовки поколения из любых операций, которые будут применяться параллельно в любом порядке и любое количество раз.
Плюсом к тому, решены некоторые важные для голема проблемы с распараллеливанием операций.
There was a problem hiding this comment.
Сейчас в aimclub/GOLEM#199 реализован параллелизм на уровне операций.
Не нашел в aimclub/GOLEM@main...parallel-population-processing параллельных вызовов кроме как в кроссовере и в репродукции, для ReproduceWorker, который объединяет собственно все шаги репродукции. Поправьте, если я что-то пропустил.
Также планируется в этот же PR добавить функционал, который позволит составить свою схему подготовки поколения из любых операций, которые будут применяться параллельно в любом порядке и любое количество раз.
Звучит круто. Интерфейсы этой утилиты будут привязаны к интерфейсам GOLEM? Можно будет применить ее для параллельного выполнения кастомных операций на кастомных типах данных?
Небольшое пожелание по конфигурированию: очень хотелось бы иметь возможность раздельно выбрать число потоков, хотя бы для вычисления обжективов и всего остального.
There was a problem hiding this comment.
Не нашел в aimclub/GOLEM@main...parallel-population-processing параллельных вызовов
Сделано за один вызов.
Интерфейсы этой утилиты будут привязаны к интерфейсам GOLEM?
Да.
Можно будет применить ее для параллельного выполнения кастомных операций на кастомных типах данных?
Да.
возможность раздельно выбрать число потоков, хотя бы для вычисления обжективов и всего остального.
Если нужно последовательно выполнить несколько операций в многопоток, а потом одну в однопоток - это можно.
… from existing polygon. Add example for noise_sampler.py and example lightning shaped figure.
New features:
Minor changes: