Доброе время суток,уважаемые форумщики!
Собственно,минимальная конфигурация оборудования расписана для каждого программного пакета. Но меня интересуют несколько иные вопросы,ответы на которые я с ходу не смог найти. Надеясь на вашу помощь и поддержку,размещаю их в этой теме.
1. Могут ли программные пакеты эффективно использовать многоядерные (2-х, 4-х) процессоры?
2. Насколько эффективно софт использует оперативную память компа?
3. Нужно ли делать какие-либо настройки софта (не только САПР,но возможно,и ОС) для увеличения скорости расчетов?
Иными словами-как "выглядит" оптимальная система для СВЧ-софта.
Конкретно же меня интересуют MicroWave Office, Sonnet, CST MWStudio, Ansoft Designer, Zeland (платформа-Windows).
Может кто-то располагает данными по конкретному пакету (ссылки на форумы, статьи, личный опыт...). Буду благодарен за любую помощь в решении вышеперечисленных вопросов.

По настройке ОС сложно что-то сказать - никогда не возился. Когда можно спокойно поставить 3 Гига памяти, то бороться за лишние 10-20 Мб как-то нет особого смысла.

По CST недавно тестили на двухядерном на полностью одинаковых задачах 2006 и 2008 версию. Прирост в скорости от 40% и иногда более 100% (в этом случае 2008 ЦСТ увеличил величину шага по времени раза в 1.5, но результат расчета совпадает с 2006 версией и стабилен). 2006 версия не использовала 2 ядра, 2008 использует - так что выгода очевидна. Где-то тут же на форуме встречал заметку от 4-ядерной машине. Сами еще не прикупили такую, так что сказать о количестве ядер более 2 что-то конкретное сложно.

За ЦСТ еще замечено, что на момент расчета матриц он требует больше памяти, чем когда идет уже непосредственно Transient анализ.

Ну и при больших задачах наверное имеет смысл переходить на 64-разрядную ОС (более 3 Гб памяти).

По CST,двухядерный, изьезженная тема, много ссылок на форуме...

Используем MWO на 2-х ядерных и на 2-x процессорном железе. Время расчета EMStructure приблизительно одинаковое (два ядра по 50% загруженности против 4 по 25%). Сравнение чисто субъективное, т.к. машины отличаются как "самокат с машиной", но вывод напрашивается "зачем платить больше, если разницы никакой".

Спасибо за информацию. Думаю,что с CST вопрос решенный.


Не будьте слишком суровы я почитал эти темы и у меня уже сложилось определенное мнение. Но идея была в том,чтобы создать ветку,где бы обсуждался весь набор используемого софта.
Кстати,если у кого-то есть информация по пакетам,не вошедшим в начальный список, но реально использующихся при проектировании,то пишите. Думаю,что эта информация пригодится.

Если программа использует Intel MKL, то для активации мульти-ядерного использования достаточно заявить переменную окружения 'OMP_NUM_THREADS=<CPU Cores Number>'.
MKL предоставляет встроенный параллелизм на основе мульти-поточности.

Очень интересная информация,спасибо. Мы проводили подобные изыскания,но с Sonnet. Результат получился очень похожий-двухпроцессорный сервер с HT раскидывал примерно одинаково на все 4 (условно) ядра. А вот на двухядерной машине мы не тестили,т.к. их нет. Вот сейчас и думаем-какие машины брать... Кстати,тот же Sonnet но на 4-м пне, считал тестовую структуру ненамного больше (меньше минуты разница) чем на сервере. Вот и возник вопрос по поводу настроек ОС. Может,менять приоритет на "реального времени"?

поделюсь чисто соображениями, на примере, решения СЛАУ, без необходимости которого не может обойтись ни один ЭМ софт

насколько я знаю, в FEKO, EMC Studio да похоже и в Concept для решения СЛАУ используется библиотека LAPACK, а это уже ПОЧТИ однозначно говорит о том, что для решения СЛАУ используется много процессорность...

А как узнать использует она его или нет? Можно это где-то посмотреть?

При расчете на ФЕКО 100% загрузки я не вижу. Все колебается возле 50% (Ноутбук Centrino Duo). Стоит версия Feko 5.2. Может в 5.3 что-то и поменялось

Еще вопрос в тему.
Прошу высказать свои соображения относительно потери в производительности при работе памяти в одноканальном режиме относительно двухканального. Соответственно, для приложений из этого топика.

В MoM-солверах на основе MKL 100% загрузка будет только на стадии как-раз матрикс-солвинга (применяя LAPACK). Заполнение матрицы и расчет полей зависят от разработчика и требуют специальной параллелизации. Возможно поэтому при указанном OMP_NUM_THREADS загрузка всё-же скачет около 50%.

Zeland:
Использует точно - см. библ. mkl_def.dll (Intel® Math Kernel Library ver.7). Версия старая, в 14 не изменилась. Использует не один процессор (причем даже виртуальный HT) только во время решения матрицы, во время заполнения - нет. На форуме разработчики стыдливо отмалчиваются на подобные вопросы. Выигрыш от мультикора есть, зависит от соотношения fill/solve, на практике достаточно небольшой.
Sonnet:
In Release 11, the Sonnet EM Analysis Engine is a single-thread application; therefore, it will only use one core of one processor to run.
Однако: There is a way to use more of the cores on your dual-socket, quad-core workstation, however...
см. ветку форума (вернее, веточку )"Multicore CPU and Sonnet": http://www.sonnetlist.com/phpBB2/viewtopic.php?t=467

А разве сами программы, которые используют Intel MKL не задают количество процессоров, которые будут использоваться.

Во всяком случае Matlab, Ansoft, CST заведомо работающие на последних версиях Intel MKL задают количество процессоров внутри себя.
Если ваша идея работает, то тогда можно не покупать опции поддержки многопроцессорного счета (достаточно не дешевые) и просто включить 'OMP_NUM_THREADS=<CPU Cores Number>', но что-то сомнительно, что это работает.

полностью согласен....

вот как дело обстоит с софтом основанным на, например, FDTD или FEM я пока не разбирался....

но им по сути вообще переход к распараллеливанию должен оказаться очень простым, поскольку они как правило используют итерационные методы решения разреженных систем (sparse iterative methods)
данные методы широко развиваются (например, см. работы Y.Saad, H. van der Vorst) и существует достаточно много библиотек с их реализацией.

я вот чего то в описаниях не шибко находил упоминания какие итерационные методы испольуются в FDTD, TLM, FEM .....

вот, например, другой подход к ускорению
http://www.kraftway.ru/solutions/?SECTION_...p;PAGE_ID=93166

Выход в свет мощных GPU-акселераторов немедленно был использован разработчиками FDTD-программ. В январе 2007 года корпорация nVidia вложила 3 млн. кан. долларов в канадскую фирму Acceleware для развития программно-аппаратных решений на базе nVidia GPU 8-й серии, в частности для разработки GPU-ускорителей для FDTD-программ.
Ускорителями от Acceleware уже обзавелись такие компании – разработчики FDTD-пакетов, – как Agilent (AMDS), CST (Microwave Studio®), EMAG (EMLounge™), NLCSTR (Sim3D_Max™ FDTD Simulator), QWED (QuickWave), Remcom (XFdtd®), SPEAG (Semcad X) и Vector Fields (Concerto). Компания Optiwave в своем пакете OptiFDTD в качестве ускорителя также применяет GPU-ускоритель от EM Photonics c 16 Gb памяти на борту.
В зависимости от задачи ускорение расчетов достигает от 10 до 200x.
На сайте http://www.e...tonics.com/ размещена бесплатная демо-версия программа FastFDTD, считающая через любую графическую карту от nVidia, начиная с 6-й серии.
© http://www.nanometer.ru

У нас сейчас конструкторский отдел бьется над этой проблемой. Понятно,что переложить расчеты на GPU можно,но не совсем понятно как это сделать. Какие брать материнки, чтобы они поддерживали несколько графических плат,да еще потом софт корректно со всем этим работал... Вопросов слишком много.
Хотя статьи о подобных расчетах я читал еще года 2 назад причем в популярных компьтерных изданиях...


Я Вы не пробовали менять приоритет процесса? Не помогает? Иногда,изменив приоритет удается добиться того,чтобы загрузка увеличилась...Правда,до 100% не дотягивает Может,кто-то знает какие-то приемы,позволяющие "растормозить" процесс под Windows?

незнаю, может поможет ответить хоть на какие-то вопросы (см. прикрепленный файл)...

Не все просто с этими ускорителями. Для них компании адаптируют свой софт, поэтому далека не все фичу работают, если используется ускоритель. В случае CST нет subgridding, и что более печально работает только новая boundary, которая годиться далеко не для всех задач.