[Yuri Potapoff 0]

Господа Anga и havuho!

 

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

[Anga 0]

Задача на собственные значения (eigenmode) - это задача о нахождении собственных мод резонатора (не волновода).

 

По моему вы пытаетесь пойти по второму или третьему кругу. Еще раз: это утверждение НЕПРАВИЛЬНО. Оно ни на чем не основано и является вашим заблуждением, о чем я вам толкую уже 10 постов. Для тех кто в танке: открою вам страшную тайну: анализ конечного объема с периодическими граничными условиями с помощью eigenmode-солвера - это есть анализ собственных волн бесконечного волновода, вообще говоря периодического. Для этого периодические гранусловия и придуманы.

 

Собственные моды - суть стоячие волны (не рассматривая случаи с циркуляцией энергии).

 

Т.е. если рассматривать только те решения в резонаторах, которые являются стоячими волнамии, то это будут стоячие волны. Глубокая мысль, надо запомнить! :)

 

Периодические гран. условия - они не являются стандартными (равенство нулю полей или их производных) для eigenmode солвера.

 

Чтто такое стандартные и что нет - это определяется предпочтениями пользователя. Я например всю жизнь пользуюсь в основном периодическими условиями и для меня они стандартные. Зачем попусту сотрясать воздух бессмысленными утверждениями.

 

Решение находится через разложение по стоячим волнам.

 

В CST Studio это не так - там решение находится вариантом конечно-разностного метода с использованием FIT. Что касается теории, то я знаю примерно 10 разных способов получения численного решения задачи на собственные значения. Вы выпячиваете какой-то из них, что не имеет ни малейшего отношения к делу.

 

То есть, я утверждаю, что бегущая волна не есть прямое численное решение для продольно-периодических структур в eigenmode постановке.

 

Наворочено много ограничений. Надо ли это понимать так, что бегущая волна - это кривое численное решение... или что она является собственным решением для волноводов но не "в eigenmode постановке" или еще какую-то глупость. Мне кажется , мы уже выяснили, что

 

а) бегущая волна является собственным решением периодического волновода

 

б) оно может быть найдено eigenmode-анализом соответствующего конечного объема с периодическими гранусловиями.

 

Все остальные приводимые вами факты электродинамики и ваши трактовки их не имеют отношения к возникшему вопросу.

 

Это и есть ключевой момент, почему вы используете для решения Eigenmode солвер, а не TD или FD. Поля стоячих волн в определенные моменты времени совпадают с мгновенным распределением поля бегущей волны. А зная эти два "слепка" поля и набег фаз, можно полностью реконструировать искомую бегущую волну. Вы же видите только конечный результат расчета, не вдаваясь в подробности.

Какие два слепка?! Это все ваши домыслы. В приведенной вами ранее ссылке с разложением по симметричным и антисимметричным стоячим волнам рассматриваются ТОЛЬКО симметричные относительно вертикальной плоскости системы. В общем случае (и в рассмотренном мной) это разложение не проходит. Даже если бы оно проходило, то решение можно было бы разложить, но только в некоторые моменты времени, а что делать в другие? Короче это разложение притянуто в нашу дискуссию за уши, чтобы хоть как-то обозначить в ней стоячие волны. Солвер честно считает конечно-разностную задачу с периодическими условиями. Да даже и это не важно. Важен результат - решением является бегущая волна - как в теории, так и в солвере.

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

Касательно того почему в CST результаты разные для потока мощности от Z, то это скорее всего результат отсутствия механизма subgridding для eigenmode солверов.

Поэтому всякие циллиндрические тонкостенные конструкции (щели, спирали) очень плохо описываются прямоугольной сеткой.

А ничего другого eigenmode солверы в CST не поддерживают. Я проверил этот пример в HFSS - результаты потоков мощности совпадают до третьего знака при любом положении плоскости интегрирования по Z. Попробуйте увеличить число узлов в сетке, должно помочь. Присутствует еще странный провал вектора Пойнтинга в начале координат, похоже это просто баг, поскольку E и H поля выглядят нормально.

Это очень ценные замечания. Я вовремя не сообразил. Обязательно попробую и сетку увеличить и HFSS.

 

 

 

Господа Anga и havuho!

 

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

 

Да, конечно. Хотя по сути здесь идет речь не о технической поддержке, а об обнаруженном баге в программе. Может вы что посоветуете?

[navuho 0]

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

С этим я и не спорю.

 

Что такое стандартные и что нет - это определяется предпочтениями пользователя. Я например всю жизнь пользуюсь в основном периодическими условиями и для меня они стандартные.

Извините, выразился неудачно. Стандартные - в том плане, что гран. условия выполняются для единственной фунции - собственной моды резонатора. Периодические условия связывают (теоремой Флоке) две такие функции - вещественую и мнимую части бегущей волны. И решение ищется относительно этой пары.

 

В CST Studio это не так - там решение находится вариантом конечно-разностного метода с использованием FIT.

FIT - лишь метод дискретизации уравнений Максвелла, а собственно солверы это AKS и JD для eigenmode случая.

 

Что касается теории, то я знаю примерно 10 разных способов получения численного решения задачи на собственные значения.

И что это меняет ? Вы можете 10-ю способами решить систему линейных уравненей относительно двух неизвестных функций U и V.

 

Вы выпячиваете какой-то из них, что не имеет ни малейшего отношения к делу.

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

Хочется еще и что-то полезное вынести.

 

Какие два слепка?! Это все ваши домыслы.

Возьмите полый волновод и проверьте. Стоячие волны с гр. условия на торцах EE и HH - будут копировать мгновенное распределение поля бегущей волны с интервалом pi/2.

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

Естественно такую геометрию считать накладно, поэтому фиксируют разность pi/2 (по времени) с одной стороны периода (E & H стенки) и записывают условия для сдвига фаз на ячейку для другой. Получают решения для действительной и мнимой части искомой бегущей волны, а по физической сути - это комбинация двух стоячих волн на N ячейках с гр. условиями EE и HH.

В приведенной вами ранее ссылке с разложением по симметричным и антисимметричным стоячим волнам рассматриваются ТОЛЬКО симметричные относительно вертикальной плоскости системы. В общем случае (и в рассмотренном мной) это разложение не проходит.

Ну почему же, добавятся условия, связывающие U и V для левой части (z=-L/2), а не в плоскости симметрии. См. выше

 

Даже если бы оно проходило, то решение можно было бы разложить, но только в некоторые моменты времени, а что делать в другие?

А другие и не нужны. Два решения однозначно определяют бегущую волну с заданным набегом фаз.

Я уже приводил выше формулы.

 

Важен результат - решением является бегущая волна - как в теории, так и в солвере.

Ага. Глубокая мысль, надо запомнить! (с)

Важно понимать физическую суть процесса решения, а не формальный его результат.

Не претендую на истину в последней инстанции, поэтому внимательно выслушаю про другие способы решений,

желательно со ссылкой на источник.

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

Вроде никто не протестует (?) Хорошо, давайте прекратим.

Не согласен насчет бессмысленности. :08:

[Yuri Potapoff 0]

Да, конечно. Хотя по сути здесь идет речь не о технической поддержке, а об обнаруженном баге в программе. Может вы что посоветуете?

 

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

[Anga 0]

(navuho @ Aug 11 2008, 19:15) Задача на собственные значения (eigenmode) - это задача о нахождении собственных мод резонатора (не волновода).

 

QUOTE(Anga @ Aug 12 2008, 23:00) Анализ конечного объема с периодическими граничными условиями с помощью eigenmode-солвера - это есть анализ собственных волн бесконечного волновода, вообще говоря периодического.

С этим я и не спорю.

За два дня вы сменили свое мнение на противоположное :05: .

[navuho 0]

За два дня вы сменили свое мнение на противоположное :05: .

Ничего я не менял. Там далее по по тексту цитаты понятно, что речь идет о eigenmode задаче с непериодическими гр. условиями.

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

Когда пишешь быстро, не всегда получается четко изложить все, что подразумеваешь по умолчанию.

[andybor 0]

К сожалению ветка "Вопросы по хфсс" пала жертвой сторонников Клана Шепчущей Галереи , посему беру смелость обратиться напрямую к специалистам альтернативного софта :)

Недавно я решил проверить полученные в ХФСС11.01 результаты моделирования обычной нерезонансной микрополосковой структуры, при помощи последней версии СиЭсТи2008sp6 и был сильно удручен, или озадачен... Несмотря на 5-ти процентное совпадение результатов по S-параметрам, наблюдалось сильное расхождение в оценке пиковой амплитуды Е-поля модели. Расчетное значение амплитуды, при использовании Монитора, для TD-солвера превысило хфсс-ное на порядок, а для FD-солвера разница составила два порядка!!! Хотя настройка FD-солвера позволила получить примерно одинаковые граничные условия с "образцовой". Сомнений в разности единиц измерения быть не может - обе программы меряют в V/m, так что вопрос "Кто прав и кто виноват?" висит в воздухе

Так как никто не откликнулся на "призыв о помощи", я выкроил пару часов и лично свершил "дело спасения утопающего"

Короче! После многократных изменений размеров обычного прямоугольной формы плоскости Waveguide-порта в модели программы от СиЭсТи-студии, при использовании FD-солвера, мне удалось получить примерное, 25%-ое, совпадение результатов с моделью от ХФСС и более-менее похожее на реальное значение пиковой амплитуды Е-поля модели :tort:

Для TD-солвера, к сожалению, ситуация нисколько не улучшилась. Результат только немножко сдвинулся в сторону правильного, после усиленного ручного меширования области с максимальной плотностью Е-поля, но недостаток времени, и отсутствие многокластерной системы суперкомпьютеров с несколькими сотнями гигабайт ОЗУ, не позволили получить столь ожидаемое количество вольт на метр

Не знаю, может всех лицензированных владельцев СиЭсТИ интересуют только S-параметры. Или они любители самобичевания, но что-то нет больше никакого желания провоцировать себя на использование софта, где приходится бОльшую часть времени тратить на подгонку модели. Я бы на месте Юры Потапова "переквалифицировался в управдомы" или подался в менеджеры Ансофта

[navuho 0]

Для TD-солвера, к сожалению, ситуация нисколько не улучшилась.

А можно взглянуть на модель ? У меня были ранее проблемы с полями в CST (особенно при расчетах с потерями), но после выхода v2006 , вроде все более менее устаканилось.

Правда считал я модели с замкнутым объемом, модели с открытой границей не пробовал.

В CST действительно много тонкостей связано с заданием "правильной" сетки.

[nadie 0]

To andybor

 

HFSS and CST имеют разное представление результатов расчета полей относительно мощности приложенной к порту. У HFSS это rms у CST peak value. Difference sqrt(2) для полей и 2 для величин размерности Ватт, поэтому всегда нужно очень вдумчиво сравнивать абсолютные значение полей между двумя прогами.

[andybor 0]

To andybor

 

HFSS and CST имеют разное представление результатов расчета полей относительно мощности приложенной к порту. У HFSS это rms у CST peak value. Difference sqrt(2) для полей и 2 для величин размерности Ватт, поэтому всегда нужно очень вдумчиво сравнивать абсолютные значение полей между двумя прогами.

Всё было сделано в соответствии с хелпом - соотношение мощностей на порту возбуждения в СиЭсТи и ХФСС-модели было установлено на уровне 0.5. Насчет "sqrt(2) для полей" ничего не знаю, для расчета пиковой амплитуды Е-поля в Ансофте использовался Calculator, а в СиЭсТи - филдмонитор, на одной частоте.

[Yuri Potapoff 0]

Я бы на месте Юры Потапова "переквалифицировался в управдомы" или подался в менеджеры Ансофта

 

Надо не отгадывать правильный ответ, а задавать вопрос на фирму.

 

Уже был один пользователь, который развел полемику, что в CST невозможно задавать ро в омах на квадрат. Оказалось можно.

 

И еще: сейчас нельзя быть менеджером ансофта, так как нет такой фирмы. Это просто торговая марка, принадлежащая ансису.

[nadie 0]

пиковой амплитуды Е-поля в Ансофте использовался Calculator, а в СиЭсТи - филдмонитор, на одной частоте

 

Если вы установили соотношение мощностей 0,5 то тогда поля должны быть одинаковыми по величине. Difference sqrt(2) возникает в случае одинаковых значений (цифр) при задании мощности портов.

Но если вы пытаетесь сравнить пиковые ампитуды, то тут возникают дополнительные заморочки. По заявлению Ансофта (это в явном виде написано и в хелпе), Calculator считает не пик от трех компонентного вектора, а сумму пиков каждой компоненты. Посмотрите в топике по HFSS уже была моя дискуссия с navuho по этому вопросу. Насколько корректно считает CST peak value сказать сложно, так как саппорт не выдает формулу, которая используется (ее нет в хелпе). Поэтому в большинстве случаев пытаются сравнивать между CST и HFSS результаты от величин, которые не являются 3Д комплексными величинами.

[andybor 0]

А можно взглянуть на модель ? У меня были ранее проблемы с полями в CST (особенно при расчетах с потерями), но после выхода v2006 , вроде все более менее устаканилось.

Правда считал я модели с замкнутым объемом, модели с открытой границей не пробовал.

В CST действительно много тонкостей связано с заданием "правильной" сетки.

Не буду морочить вам голову своей моделью. Вот, посмотрите обычный кусок микрострипа.

Разница показаний в E-field (peak) для TD и FD - 2 раза!!!

Обе модели запитаны одним ваттом, усиленно мешировались вручную в области стрипа и подвергались автомешу по дельта-S=0.01.

В принципе ничего нового нет: FD-солвер позиционируется фирмой, как наиболее подходящий для резонансных структур, именно там требуется бОльшая точность для расчета мест с высокой плотностью поля.

 

 

 

Если вы установили соотношение мощностей 0,5 то тогда поля должны быть одинаковыми по величине. Difference sqrt(2) возникает в случае одинаковых значений (цифр) при задании мощности портов.

Но если вы пытаетесь сравнить пиковые ампитуды, то тут возникают дополнительные заморочки. По заявлению Ансофта (это в явном виде написано и в хелпе), Calculator считает не пик от трех компонентного вектора, а сумму пиков каждой компоненты. Посмотрите в топике по HFSS уже была моя дискуссия с navuho по этому вопросу. Насколько корректно считает CST peak value сказать сложно, так как саппорт не выдает формулу, которая используется (ее нет в хелпе). Поэтому в большинстве случаев пытаются сравнивать между CST и HFSS результаты от величин, которые не являются 3Д комплексными величинами.

А разве параметр Abs Maximum-3d для E-field в CST не означает "сумму пиков каждой компоненты"?

Ну да ладно, черт с ней - с разностью значений пика в разных программах. Больше беспокоит, что разные солверы в одной программе дают сильно-отличающийся результат по полям, при одинаковой мощности на портах, хотя S-параметры одинаковые.

 

 

Надо не отгадывать правильный ответ, а задавать вопрос на фирму.

 

Уже был один пользователь, который развел полемику, что в CST невозможно задавать ро в омах на квадрат. Оказалось можно........

...........................................................

Что это за софт, если из-за каждой ерунды надо "задавать вопрос на фирму"?

Когда-же работать? Это всеравно, что купить машину, и по каждой мелочевке, типа: куда залить бензин, как включить поворотник и т.д., обращаться к сервис :cranky:

Почему-то за пять лет работы с ансофтоским, или как-там теперь - ансисовским, продуктом, ни разу не появилась потребность в вопросе на фирму.

Кстати! А где находится "рукоятка регулировки мощности" на порту для FD-солвера?

Боюсь разработчики про неё просто забыли:(

Откройте, Юрий, "тайну золотого ключика". Буду премного благодарен

[Yuri Potapoff 0]

Что это за софт, если из-за каждой ерунды надо "задавать вопрос на фирму"?

Когда-же работать? Это всеравно, что купить машину, и по каждой мелочевке, типа: куда залить бензин, как включить поворотник и т.д., обращаться к сервис :cranky:

 

Будьте проще.

 

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

 

А как включить поворотник написано в доке.

 

И объясните мне, какова моя мотивация в раскрытии вам "тайны золотого ключика?".

[andybor 0]

.....А как включить поворотник написано в доке.

С этого момента, Юрий, поподробней! Раздел, страница, пароль, явки.... Или этот док только для вип-клиентов? :)

 

.......

И объясните мне, какова моя мотивация в раскрытии вам "тайны золотого ключика?"

Ну вот, настоящая деловая хватка! А ещё говорят, что: "лучшие менеджеры - американцы". Врут!!!

Настоящие акулы капитализма живут и правят миром из Железнодорожного