[Freesom 15]

11 hours ago, Ferz said:

теперь бы посчитать каждый порт по отдельности, сто лет пройдёт )может в данном случае (крупная решетка) всё-таки быстрее будет изменять каждый раз PAA_FA_SCANTHETA вручную и считать через совместное возбуждение.

CST прекрасно распараллеливает даже последовательное возбуждение с разных портов - запасайтесь 32-х ядерным процом - будет считать пачками по 32 порта за раз, памяти бы только хватило))) Есть конечно зависимость от того, чего больше - портов или интересующих направлений луча, иногда проще одновременной запиткой пройти по списку. Ну и ещё плюс постпроцессинга в том, что всегда можно быстро досчитать новых направлений или с другим амплитудным распределением. Если портов сотни, то проект ещё и начинает жрать много места на диске - для каждого порта надо сохранить полную матрицу полей всей структуры. Хорошо хоть в 20-й версии комбинирование распараллеливается на все ядра - теперь даже кофе не успевает остыть, а уже всё готово, ещё немного и по скорости обгонят Beamforming в SystemVue)))

[Pir0texnik 0]

On 10/22/2020 at 12:17 AM, Ferz said:

Ну как я и подозревал, физику не обманешь ) теперь бы посчитать каждый порт по отдельности, сто лет пройдёт )может в данном случае (крупная решетка) всё-таки быстрее будет изменять каждый раз PAA_FA_SCANTHETA вручную и считать через совместное возбуждение.

 В очередной раз, спасибо Вам огромное за развернутый ответ, товарищ! Будем пробовать !

там ничего не надо считать...

уже должна быть посчитано КАКОЕ-ТО дальнее поле: хоть в свободном пространстве, хоть в периодический решетке - пофигу. Раз у вас там решетка - логично посчитать поле единичного элемента.

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

Забавный факт любознательным, вот изменение этих переменных с зеленым кубиком... не всегда НЕ вызывает пересчета геометрии... попробуйте поизметять их из того мерзкого бейсика, приятно удивитесь, что оно будет требовать перестроить геометрию.

[Pir0texnik 0]

On 10/22/2020 at 11:35 AM, Freesom said:

для каждого порта надо сохранить полную матрицу полей всей структуры.

зачем?.. для ДН это какбе не надо...

Там в недрах есть много всякого тупняка вроде - всякое ненужное говно  промежуточные данные сохранять, которые нафиг пользователю не уперлись, но которые способны засрать место на диске. 
Например, на протяжении десятилетия, бонусом к дальнему полю они сохраняли и ближнее. Теперь они там галочку придумали в FF мониторе.
Еще подождать лет 10 и они научатся тереть из папки резалтс папки вида "HEX000, HEX001, HEX002", в которых ничего кроме мусора нет, но которые могут съесть гиг другой места.
Я боюсь предположить сколько там еще тупняка под капотом, который живет с первой версии и который все принимают как данность...

[Ferz 0]

2 часа назад, Pir0texnik сказал:

там ничего не надо считать...

уже должна быть посчитано КАКОЕ-ТО дальнее поле: хоть в свободном пространстве, хоть в периодический решетке - пофигу. Раз у вас там решетка - логично посчитать поле единичного элемента.

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

Забавный факт любознательным, вот изменение этих переменных с зеленым кубиком... не всегда НЕ вызывает пересчета геометрии... попробуйте поизметять их из того мерзкого бейсика, приятно удивитесь, что оно будет требовать перестроить геометрию.

Здравствуйте !спасибо за отзывчивость . Меня интересует именно полная решетка , так как учитываются все краевые эффекты и тп. поэтому множитель решётки мне не совсем подходит.

Речь идёт именно об отклонении луча . Да и Unit cell может дать понять лишь приближенно все эффекты(хотя и в достаточно хорошем приближении) 

[Freesom 15]

12 hours ago, Pir0texnik said:

там ничего не надо считать...

уже должна быть посчитано КАКОЕ-ТО дальнее поле: хоть в свободном пространстве, хоть в периодический решетке - пофигу. Раз у вас там решетка - логично посчитать поле единичного элемента.

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

Познания в антенных решетках уровня "правила перемножения диаграмм" М.А. Бонч-Бруевича от 1924 года - это очень сильно, только правило это годится в основном в образовательных целях, чтоб аналитически показать к чему приводит то или иное амплитудное или фазовое искажение, как диграмма зависит от расстояния между элементами и т.д. На практике сойдёт и как первое приближение для сельской местности. Если вас и вашего заказчика устроит результат такого уровня, то почему бы и нет, главное ничему не удивляться при измерении характеристик получившегося изделия.

12 hours ago, Pir0texnik said:

зачем?.. для ДН это какбе не надо...

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

12 hours ago, Pir0texnik said:

Там в недрах есть много всякого тупняка вроде - всякое ненужное говно  промежуточные данные сохранять, которые нафиг пользователю не уперлись, но которые способны засрать место на диске. 
Например, на протяжении десятилетия, бонусом к дальнему полю они сохраняли и ближнее. Теперь они там галочку придумали в FF мониторе.

Та галочка в FF мониторе по сути мало что меняет, лишь лишает сам монитор некоторой гибкости в постпроцессинге. В реальности отключение сохранения 3D полей для FF монитора с целью экономии места на диске существует в CST уже много бородатых лет, но находится в другом месте

[Pir0texnik 0]

On 10/26/2020 at 11:00 AM, Freesom said:

Познания в антенных решетках уровня "правила перемножения диаграмм" М.А. Бонч-Бруевича от 1924 года - это очень сильно, только правило это годится в основном в образовательных целях, чтоб аналитически показать к чему приводит то или иное амплитудное или фазовое искажение, как диграмма зависит от расстояния между элементами и т.д. На практике сойдёт и как первое приближение для сельской местности. Если вас и вашего заказчика устроит результат такого уровня, то почему бы и нет, главное ничему не удивляться при измерении характеристик получившегося изделия.

Дык, кто ж ему виноват, что эти Бонч и Бруевич такие умные чуваки были. Годица токо в путь. Особенно если у тебя все парциальные диаграммы есть. Более того на относительно даже не сильно больших решетках оно вполне годно. Во всяком случае если ты слелал хорошую решётку в приближении, то реальная решётка тоже будет очень годная. Останется только чуть подрихтовать краевые эффекты ну или если не дай боже какой злой резонанс на апертуре, но это довольно очевидные вторичные вещи. Главное, что если решётка плохая в приближении, то ничего не поможет. И конешно для заказчика любимого антенну целиком засимулировать совсем не жалко.

On 10/26/2020 at 11:00 AM, Freesom said:

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

Ну я и говорю, редко иногда, когда реальная решётка фиг его знает почему на идеальную совсем не похожа.

В общем-то, в какой-то мере вся борьба ведётся, чтобы реальная решётка была такая же хорошая, как и идеальная.

 

Я говорил про Т-солвер. Ф-солвер при живом-то хфсс...

Там в т-солвере и монитор поля чуть другой. И раньше он тупо все ближние поля сохранял. Много-много лет. В тихую. 

 

On 10/25/2020 at 11:54 PM, Ferz said:

Здравствуйте !спасибо за отзывчивость . Меня интересует именно полная решетка , так как учитываются все краевые эффекты и тп. поэтому множитель решётки мне не совсем подходит.

Речь идёт именно об отклонении луча . Да и Unit cell может дать понять лишь приближенно все эффекты(хотя и в достаточно хорошем приближении) 

А, так это в настройках солвера ставите возбуждение всеми портами и сразу. И там же можно задать амплитудное распредение. Даже параметрами. А фазовое делать там же соответствующими временными задержками. В принципе как и жизно оно почти.

[Pir0texnik 0]

Каюсь, кстати, на счет ф-солвера. Чего-то он мне стал нравиться внезапно все больше и больше. Даже при живом хфсс.

[Turgenev 1]

Подскажите, можно ли включить аппаратное ускорение для CST MW? Версия CST 2017 крякнутая, в настройках солвера выставил все, драйвера обновил, но при расчете пишет что не видит ничего. Прикладываю скрины того, что получается.

 

Скрытый текст

Изменено 1 ноября, 2020 пользователем Turgenev

[TitovVN1974 0]

Turgenev

Если у Вас есть официально поддерживаемые CST 2017 карты, то они и только они должны работать с CST 2017 {ИМХО}. 

[Turgenev 1]

15 минут назад, TitovVN1974 сказал:

Если у Вас есть официально поддерживаемые CST 2017 карты, то они и только они должны работать с CST 2017 {ИМХО}. 

Согласен. А можно ли как-нибудь убедиться что в пределах одного компьютера CST использует все ресурсы этого компьютера?

[TitovVN1974 0]

Turgenev

С достаточно большим проектом на процессоре с гипертреадингом загрузка CPU ~ 60%

Соответственно, использование GPU во вкладке CUDA диспетчера задач ~ 90% 

В Messages - будет указано, что GPU - используется.

Потребление памяти GPU в диспетчере - кажется мне не очень надежным индикатором загрузки (ИМХО). 

Когда памяти GPU перестанет хватать - будет ошибка с соответствующим сообщением.

[Turgenev 1]

16 минут назад, TitovVN1974 сказал:

Turgenev

С достаточно большим проектом на процессоре с гипертреадингом загрузка CPU ~ 60%

Соответственно, использование GPU во вкладке CUDA диспетчера задач ~ 90% 

В Messages - будет указано, что GPU - используется.

Потребление памяти GPU в диспетчере - кажется мне не очень надежным индикатором загрузки (ИМХО). 

Когда памяти GPU перестанет хватать - будет ошибка с соответствующим сообщением.

Понимаю, что ничего не понимаю. Есть ли аппноут или гайд по настройкам ускорения? Или все про что вы написали по дефолту выставлено в солвере? 

[TitovVN1974 0]

Turgenev

Solver Setup -> Acceleration ->

CPU Acceleration и {Hardware Acceleration - при наличии опции в солвере}  - выставить

количество процессоров и потоков, а также GPU - ускорителей.

Для использования официально неподдерживающихся GPU требуется >~ 2019 версия,

следуя http://updates.cst.com/downloads/GPU_Computing_Guide_2020.pdf - выставить переменные окружения

{На примере Windows 10 RU: система -> свойства системы -> переменные среды}

CST_HWACC_ALLOW_UNVERIFIED_HARDWARE c значением 1

при наличии нескольких GPU и при желании использовать не все - настроить переменную CUDA_VISIBLE_DEVICES

- - - - 

GPU_Computing_Guide_2020:

*Unsupported NVIDIA Hardware
If you have an NVIDIA GPU card which is not supported (please see the list of supported
cards in the previous section), but fulfills the requirements below, you may enable it for simulations by following these instructions. Note that using unsupported and untested hardware
is not recommended. CST will not provide any support for any problems resulting from using
unsupported GPU cards and CST will not run any tests on these GPUs.
The NVIDIA GPUs that fulfill the following requirements may be enabled for simulations:
• capable of running CUDA 9.2 code
• at least 4 GB of free memory
To enable such GPUs, set the environment variable CST_HWACC_ALLOW_UNVERIFIED_HARDWARE
= 1. Then all eligible installed and visible NVIDIA GPUs will be considered for computation.
You can limit the visible devices by using the environment variable CUDA_VISIBLE_DEVICES.

 

 

[Turgenev 1]

01.11.2020 в 19:46, TitovVN1974 сказал:

Turgenev

Solver Setup -> Acceleration ->...

Огромное тебе спасибо. Прям для ленивых расписал, очень четко!!!

[Pir0texnik 0]

Дорогие симулянты!

Хочется узнать у чисто реального коммунити один вопрос, т.к. мне чего-то кажется, что либо CST кладет на юзеров, либо их-то десятки тыщ, но это какие эльфы с венеры...

Я недавно имел долгую беседу с гражданами из CST. И на мою очередную жалобу, что ихняя хистори - это во-1 капец какая убогая хрень, во-2, что она безумно медленная (по сравнению c HFSS). Мне сказали буквально следующее:  "Зато она очень нравится нашим пользователям."
Так вот мне стало любопытно, а так ли это?

Хистори - это священная корова CST. Они повесятся скорее, чем что-то там начнут менять, но, в тоже время, это один из самых отвратительных и тормознутых костылей в ней, которой существует с самого-самого начала. У меня всегда было подозрение, что они в тогда в 199х хотели сделать "undo" функционал, по быстрому, а потом оно как-то так прижилось и осталось. И теперь оно там так глубоко, что его хрен выковыряешь, ибо на каждом шагу легаси.

 

Почему хистори это уродство в том виде в каком она сейчас:

1. Затея с undo - НЕ работает. Я не знаю ни одного человека, который бы активно этим пользовался. Это НЕ удобно и тормознуто. (undo/redo в hfss незаменимая штука)
2. Хистори подобна редактору кода, который сохраняет не конечный файл текстовый, а историю всех телодвижений юзера, когда он набивал текст этого файла. При загрузке файла загружается не текст, а воспроизводится история набора этого текста. В результате получается текст, но его, например, нельзя скопировать, т.к нужно копировать всю историю его создания!
3. Хистори переполнена мусором - если ты работаешь чисто в моделере и никогда не правишь хистори руками (править хистори официально НЕ рекомендуется CST), то она будет чуть более чем полностью состоять из мусора, т.к, например, когда объект удаляется, то он НЕ удалится из хистори, он там и будет жить только добавится где-то ближе к концу команда его удаления.
4. В хистори бардак - команды, которые отвечают за геометрию, за солвер, за оптимизатор, за все на света тупо находятся в одном сплошном списке, который если не чистить руками в конечном итоге превращается в дикий бардак.
5. По причинам выше - НЕТ нормальной команды копирования объектов
6. Хитори тормозит. Очень тормозит. HFSS обновляет геометрию в реальном времени в отличие от.

Наверняка этот список не полный и его можно продолжать...

Сейчас проект все время надо допиливать в редакторе истории, чистить мусор, сортировать и группировать команды, это долго, утомительно и достает делать из г* конфету, т.к. все знают, что может быть... как в HFSS. Дерево и никаких тормозов. (CST мне ответило: "Зато у нас есть ... хистори (поэтому так тормознуто)." )

Может быть я как-то неправильно употребляю CST?.. Я правда не понимаю ЧЕМ же хистори так прекрасно по сравнению с деревом HFSS.

 

Расскажите, насколько вы любите или нет хистори? Правда ли, что "Она очень нравится нашим пользователям" ?