Jump to content

    
Pir0texnik

Вопросы по CST

Recommended Posts

12 hours ago, Pir0texnik said:

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

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

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

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

12 hours ago, Pir0texnik said:

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

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

12 hours ago, Pir0texnik said:

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

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

ff_3d.thumb.PNG.c38be332acb32fa20b88d702bc76b253.PNG

ff_3d2.thumb.PNG.5633a917d17adaea0c7ff71c932e7aac.PNG

Share this post


Link to post
Share on other sites
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 может дать понять лишь приближенно все эффекты(хотя и в достаточно хорошем приближении) 

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

Share this post


Link to post
Share on other sites

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

 

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

50010152_2.thumb.png.4a76c0ea1fd8aab2e490537abacaf796.png1852552170_.thumb.png.e9bd6f62e20b10b146d90fd08fc4a880.png1510462224_23.png.21b21b2d2ce31337f6ebb1aa35480801.png

Edited by Turgenev

Share this post


Link to post
Share on other sites
15 минут назад, TitovVN1974 сказал:

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

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

Share this post


Link to post
Share on other sites

Turgenev

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

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

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

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

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

Share this post


Link to post
Share on other sites
16 минут назад, TitovVN1974 сказал:

Turgenev

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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.

 

 

Share this post


Link to post
Share on other sites

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

Хочется узнать у чисто реального коммунити один вопрос, т.к. мне чего-то кажется, что либо 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.

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Ооо, я не один такой!!! Хистори в cst это ад!!! Отлично понимаю о чем писал Pir0texnik

Хочется выделить, что изменив что-либо в хистори, замучаешь корректировать и вспоминать все позиции, на которое это изменение влияет. Тупо жмешь апдейт, тебе показывают что вот тут то не получается, ты корректируешь (а в большинстве случаев просто удаляешь из-за нехватки времени) и так до тех пор, пока он апдейт не доползет до конца. Не представляю как иначе в сложном проекте (например полностью параметризуемый фильтр на резонаторах 6-8 порядка) что-то менять, ведь запомнить все просто не реально. 

А про тормознутость этой хистори... Если набить штук 50 "правильных" переходных (с максимальной правдоподобностью), то это уже под +500 действий к твоей хистори, что у меня в сумме с моей сотней действий заставляет при каждом апдейте ждать по 5-6 секунд. Да, зависит от компа и тд и тп, но по-моему не нормально при каждом действии прогонять всю втою неоптимизированную хистори. Такое ощущение, что надо не только моделировать, а еще и вылизывать хистори, удаляя тупиковые ветки. 

Share this post


Link to post
Share on other sites
22 hours ago, Freesom said:

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

Никто не против списка действий. Списка НЕОБХОДИМЫХ действий, а не вообще всех подряд в рандомном порядке. 3Д модель, особенно сложная, это несколько иная сущность чем конфиг роутера... Кроме того, гуи роутера не создаёт помойку в конфиге. Туда записывается только то, что надо. А не ВСЕ телодвижения в гуи! Я не знаю, другой программы, где еще бы додумались писать в историю ВСЁ. Это какой-то дикий мозговой вывих.

В 3д модели гораздо нагляднее смотреть на дерево её построения (которое прикручено в cst, но какое же оно убогое, они типа начали его ковырять, а до ума довести ниасилили). Ручной труд почетен, но он крадет овер дохрена человекочасов. Если у них 50 000 юзеров то они уже потратили времени эквивалентного времени жизни населения небольшой деревни...

Более того, как я писал уже, ковыряние в истории - это ОФИЦИАЛЬНО не рекомендуемый воркфлоу.

В том виде в каком истрия находится все эти 20 лет - это адъ и Израиль.

Share this post


Link to post
Share on other sites
13 hours ago, Turgenev said:

Если набить штук 50 "правильных" переходных (с максимальной правдоподобностью), то это уже под +500 действий к твоей хистори, что у меня в сумме с моей сотней действий заставляет при каждом апдейте ждать по 5-6 секунд. Да, зависит от компа и тд и тп, но по-моему не нормально при каждом действии прогонять всю втою неоптимизированную хистори

Что означает "правильных" переходных (с максимальной правдоподобностью)? О чём конкретно речь?

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.