[DmitryHF 0]

Помогите еще пожалуйста с выводом плотности тока Jvol: каким образом нужно вывести Jvol для того, чтобы увидеть скин слой в проводнике? Не понятен смысл "ComplexMag_Jvol" и "Mag_Jvol". Не могу никак найти в helpe формулы для их вывода, а текстовое описание не совсем понятно.

Ниже в качестве примера привожу вид поля ComplexMag_Jvol и Mag_Jvol, видно, что плотность тока разная, при чем Mag_Jvol почему-то еще и зависит от фазы!

Здесь фаза от которой зависит Mag_Jvol - имеется ввиду фаза сигнала, идущего от порта?

 

Мне кажется, что "увидеть скин слой" нагляднее на плоскости, а не в объеме. Создайте плоскость или поверхность и выводите на нее ваш ток. Скорее всего Вам нужен ComplexMag_Jvol.

Вы правильно заметили разницу в величинах ComplexMag_Jvol и Mag_Jvol. При анализе гармонических процессов используют комплексные векторы Е и Н. Зная Е, по известному уравнению находиться J. ComplexMag_Jvol это модуль Jvol, а Mag_Jvol модуль Jvol в зависимости от фазы. Да, эту фазу можно менять в Edit Sources или выбрать в свойствах графика при отображении поля.

Изменено 1 июня, 2016 пользователем DmitryHF

[Stefan1 0]

Мне кажется, что "увидеть скин слой" нагляднее на плоскости, а не в объеме. Создайте плоскость или поверхность и выводите на нее ваш ток. Скорее всего Вам нужен ComplexMag_Jvol.

Вы правильно заметили разницу в величинах ComplexMag_Jvol и Mag_Jvol. При анализе гармонических процессов используют комплексные векторы Е и Н. Зная Е, по известному уравнению находиться J. ComplexMag_Jvol это модуль Jvol, а Mag_Jvol модуль Jvol в зависимости от фазы. Да, эту фазу можно менять в Edit Sources или выбрать в свойствах графика при отображении поля.

Еще раз спасибо за помощь.

[Stefan1 0]

Добрый день.

С визуализацией скин слоя кубика вроде бы разобрался. Затем вывел график Re(Z11) с целью получить активное сопротивление скин слоя кубика - вроде бы похоже на правду. Теперь хотелось бы оценить на сколько точен расчет исходя из Z-параметров. Понятно, что влияют граничные условия и сетка, но эти погрешности, по-видимому, можно оценить в расчете просто перебирая различные варианты. А вот погрешности, заложенные в методику расчета - не понятны.

И вообще, интересен вопрос о целесообразности усложнения исследуемой конструкции: к примеру, мне надо будет добавить плоский конденсатор на его верхней грани и, таким образом, получается уже последовательная RC цепочка на землю. Понятно, что скин слой будет уже другим у этого кубика. Но при этом появится отраженная волна от емкости, и погрешность расчета видимо возрастет.

Может кто-нибудь сталкивался с оценкой аналогичных погрешностей, сравнивал с экспериментом?

Изменено 3 июня, 2016 пользователем Stefan1

[Halo_Gen 0]

LumpedPort нельзя задать на изогнутых поверхностях, LumpedRLC вероятно тоже (не уверен). Создайте прямоугольник внутри, между выводами.

Хорошо бы, с измерениями сравнить.

LumpedRLC можно и на изогнутых задать. Вопрос только в том как это сделать правильно и правильно ли задавать на изогнутой. В литературе показаны способы только при подключении к полоскам.

А вот как в волноводе я пока не нашел. :-(

 

 

[Madao 0]

Подскажите как правильно определять фазу и в раскрыве. Я провожу линию в центре раскрыва от края до края, назначаю на нее ближнюю зону и строю график зависимости NearEY от расстояния.

Получается какая-то рваная картина.

Может кто знает есть ли возможность сгладить график или усреднить как-нибудь?

[Pir0texnik 0]

Опять я про оптимизатор... Новость кажется совсем плохая, он умер (я говорю про 2016.1, вроде пока новее нету).

По крайней мере интерфейс матлаба. Но мне кажется, что подобная шняга также в нонлинеаре оптимизаторе... кажется. Pattern search вроде ok.

Оптимизирую нечто, вот, что пишет лог самодельного оптимизатора из матлаба:

 

Inside Ansoft Mex Function, command: eval

Cost is 72648.242588811816

Cost is 70856.386518967556

Cost is 104061.15776013421

Cost is 252157.21865344199

Cost is 127357.25342167106

Cost is 204294.70034645300

Cost is 87416.448393114042

Cost is 177553.73904330994

Cost is 96161.682534433538

Cost is 125273.28302496811

Cost is 41980.665121377751

Cost is 73138.518597556118

Cost is 68040.598125533463

 

Total number of function evaluations: 13;

Best feasible function value in this trial: 41980.665121

 

 

Короче говоря, после первых 13 вариаций минимальныйн кост = 41980.665121.

Это цифру посчитал HFSS и передал ее матлабу! Я на нее никак не влиял.

 

А вот, что рисует сам HFSS в окошке оптиметрикс_сетап -> показать результаты анализа (я опускаю значения переменных, только косты):

 

Evaluation, Cost

1, 2.8112

2, 36.873

3, 1.3301e+05

4, 2.5049e+05

5, 14513

6, 3.322e+05

7, 2578.7

8, 14177

9, 222.13

10, 31483

11, 15138

12, 182.88

13, 210.76

 

Короче, разница на лице... Но правильные данные именно последние. Что за бред оно теперь сгружается в матлаб - хз. спасибо ансису за это.

[Hale 1]

другой формат мантиссы? заморочки компилятора с внешними вызовами при переходе 32/64бита? Очень печально, вообще... То же что и с Ориджином ранее случилось; считаю одно, пишу другое

Изменено 11 июля, 2016 пользователем Hale

[Pir0texnik 0]

Там вроде всё вин64 и mex, и матлаб, и hfss.

Вчера проверил - глюк тоже наблюдается в 2016.0.

Квази ньютон и паттерн серч - работают нормально.

 

Но, в предыдущем проекте было все нормально, косты совпадали, в новом проекте я поменял порядок целей в сетапе, и добавил новую одну...

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

Это, кстати, значит, что у ансиса кост считается 2 раза и один из методов расчета с ошибкой...

 

Дяденька ансис почини блин наконец оптиметрикс... это ж край уже.

 

в общем, после долгой борьбы поборол...

Проблема была в цели в которой вычислялся угол cang_deg (оно же cang_rad, hfss их не различает...). Решилось созданием нового сетапа и пересозданием целей.... тупо скопировал из предыдущего сетала текстовые строки.

Т.е. внутри одного проекта 2 идентичных сетапа, но с разной последовательностью целей (но проблемная в обоих стоит первой, а остальные всегда гарантированно удовлетворены!) - один считает правильно, другой глючит, а я фигею...

 

[Hale 1]

а я уже с 10 версии не фигею... он как путал +dB с -dB, так и путает. я забил брал абсолютные значения, руками считал дБ, снова брал абсолютные значения и вместо максимизации делал минимизацию. пошел он на*** со своими подстройками под криворукого программиста. Вообще, у меня чуйство, что электромагнитная часть, сделанная докторами физики, встала где-то на 10 версии и с тех дней ее пасут чисто манки-кодеры по интерфейсу и ПК-перформансу, вемя от времени добавляя интеграцию с перекупленным софтом. Причем, если в скрипт-проекте до 14 версии еще можно было разобраться и пофиксить в нотепаде(часто имеет значение порядок объявлений, который записывается по мере доделывания проекта и не изменяется пока не скопипастишь в другой проект в новом порядке), то в е-десктопе уже так просто не получится.

Изменено 12 июля, 2016 пользователем Hale

[HFSS 0]

а я уже с 10 версии не фигею... он как путал +dB с -dB, так и путает. .....

 

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

С тех пор ни разу не сталкивался с подобными проблемами. Использую метод нелинейного программирования и метод Ньютона и патерн сёч. Как то так.

[Hale 1]

напрямую не путает, но если использовать в вычислениях... поэтому лучше dB в оптимайзере не использовать.

[Pir0texnik 0]

кстати, у меня тоже никогда не путал, но было, например, когда все цели гарантированно удовлетворены, а кост не 0. И начинается...

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

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

Совсем печально, что выходит, что у них в недрах функции, которые считают формулы в репортах и в опт. сетапе - разные... Такое впечатление, что там коллектив 1000 человек делает hfss и они не договорятся друг с другом.

Лечилось пересозданием опт сетапов, фар филдов, комбинированием порядка целей и просто принесением жертв духам ансиса...

 

[Hale 1]

я оптимизируя фазу и согласование в ферритовых железках часто вынужден был брать среднее от |S21|+|S12| и |S11|+|S22| ну и функции от фазы.

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

[Pir0texnik 0]

Это в смысле максимизировали (минимизировали) какую-то ф-цию? Никогда такого не делал, обычно задаю "сделай больше (меньше) чем x дБ". Как-то эти методы ... не внушают, хз, люблю чисто канретно.

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

[Hale 1]

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