DmitryHF 0 1 июня, 2016 Опубликовано 1 июня, 2016 (изменено) · Жалоба Помогите еще пожалуйста с выводом плотности тока 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 1 июня, 2016 Опубликовано 1 июня, 2016 · Жалоба Мне кажется, что "увидеть скин слой" нагляднее на плоскости, а не в объеме. Создайте плоскость или поверхность и выводите на нее ваш ток. Скорее всего Вам нужен ComplexMag_Jvol. Вы правильно заметили разницу в величинах ComplexMag_Jvol и Mag_Jvol. При анализе гармонических процессов используют комплексные векторы Е и Н. Зная Е, по известному уравнению находиться J. ComplexMag_Jvol это модуль Jvol, а Mag_Jvol модуль Jvol в зависимости от фазы. Да, эту фазу можно менять в Edit Sources или выбрать в свойствах графика при отображении поля. Еще раз спасибо за помощь. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Stefan1 0 3 июня, 2016 Опубликовано 3 июня, 2016 (изменено) · Жалоба Добрый день. С визуализацией скин слоя кубика вроде бы разобрался. Затем вывел график Re(Z11) с целью получить активное сопротивление скин слоя кубика - вроде бы похоже на правду. Теперь хотелось бы оценить на сколько точен расчет исходя из Z-параметров. Понятно, что влияют граничные условия и сетка, но эти погрешности, по-видимому, можно оценить в расчете просто перебирая различные варианты. А вот погрешности, заложенные в методику расчета - не понятны. И вообще, интересен вопрос о целесообразности усложнения исследуемой конструкции: к примеру, мне надо будет добавить плоский конденсатор на его верхней грани и, таким образом, получается уже последовательная RC цепочка на землю. Понятно, что скин слой будет уже другим у этого кубика. Но при этом появится отраженная волна от емкости, и погрешность расчета видимо возрастет. Может кто-нибудь сталкивался с оценкой аналогичных погрешностей, сравнивал с экспериментом? Изменено 3 июня, 2016 пользователем Stefan1 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Halo_Gen 0 3 июня, 2016 Опубликовано 3 июня, 2016 · Жалоба LumpedPort нельзя задать на изогнутых поверхностях, LumpedRLC вероятно тоже (не уверен). Создайте прямоугольник внутри, между выводами. Хорошо бы, с измерениями сравнить. LumpedRLC можно и на изогнутых задать. Вопрос только в том как это сделать правильно и правильно ли задавать на изогнутой. В литературе показаны способы только при подключении к полоскам. А вот как в волноводе я пока не нашел. :-( Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Madao 0 8 июля, 2016 Опубликовано 8 июля, 2016 · Жалоба Подскажите как правильно определять фазу и в раскрыве. Я провожу линию в центре раскрыва от края до края, назначаю на нее ближнюю зону и строю график зависимости NearEY от расстояния. Получается какая-то рваная картина. Может кто знает есть ли возможность сгладить график или усреднить как-нибудь? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Pir0texnik 0 10 июля, 2016 Опубликовано 10 июля, 2016 · Жалоба Опять я про оптимизатор... Новость кажется совсем плохая, он умер (я говорю про 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 11 июля, 2016 Опубликовано 11 июля, 2016 (изменено) · Жалоба другой формат мантиссы? заморочки компилятора с внешними вызовами при переходе 32/64бита? Очень печально, вообще... То же что и с Ориджином ранее случилось; считаю одно, пишу другое Изменено 11 июля, 2016 пользователем Hale Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Pir0texnik 0 11 июля, 2016 Опубликовано 11 июля, 2016 · Жалоба Там вроде всё вин64 и mex, и матлаб, и hfss. Вчера проверил - глюк тоже наблюдается в 2016.0. Квази ньютон и паттерн серч - работают нормально. Но, в предыдущем проекте было все нормально, косты совпадали, в новом проекте я поменял порядок целей в сетапе, и добавил новую одну... Скорее всего корень глюка в этом. Надо разбираться, чтобы не наступить на этот подводный камень. Это, кстати, значит, что у ансиса кост считается 2 раза и один из методов расчета с ошибкой... Дяденька ансис почини блин наконец оптиметрикс... это ж край уже. в общем, после долгой борьбы поборол... Проблема была в цели в которой вычислялся угол cang_deg (оно же cang_rad, hfss их не различает...). Решилось созданием нового сетапа и пересозданием целей.... тупо скопировал из предыдущего сетала текстовые строки. Т.е. внутри одного проекта 2 идентичных сетапа, но с разной последовательностью целей (но проблемная в обоих стоит первой, а остальные всегда гарантированно удовлетворены!) - один считает правильно, другой глючит, а я фигею... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Hale 1 12 июля, 2016 Опубликовано 12 июля, 2016 (изменено) · Жалоба а я уже с 10 версии не фигею... он как путал +dB с -dB, так и путает. я забил брал абсолютные значения, руками считал дБ, снова брал абсолютные значения и вместо максимизации делал минимизацию. пошел он на*** со своими подстройками под криворукого программиста. Вообще, у меня чуйство, что электромагнитная часть, сделанная докторами физики, встала где-то на 10 версии и с тех дней ее пасут чисто манки-кодеры по интерфейсу и ПК-перформансу, вемя от времени добавляя интеграцию с перекупленным софтом. Причем, если в скрипт-проекте до 14 версии еще можно было разобраться и пофиксить в нотепаде(часто имеет значение порядок объявлений, который записывается по мере доделывания проекта и не изменяется пока не скопипастишь в другой проект в новом порядке), то в е-десктопе уже так просто не получится. Изменено 12 июля, 2016 пользователем Hale Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
HFSS 0 12 июля, 2016 Опубликовано 12 июля, 2016 · Жалоба а я уже с 10 версии не фигею... он как путал +dB с -dB, так и путает. ..... Както с одним проектом очень долго воевал и было подозрение что оптиметрикс перепутал +- , но на свежую голову оказалось что запутался я. С тех пор ни разу не сталкивался с подобными проблемами. Использую метод нелинейного программирования и метод Ньютона и патерн сёч. Как то так. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Hale 1 12 июля, 2016 Опубликовано 12 июля, 2016 · Жалоба напрямую не путает, но если использовать в вычислениях... поэтому лучше dB в оптимайзере не использовать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Pir0texnik 0 12 июля, 2016 Опубликовано 12 июля, 2016 · Жалоба кстати, у меня тоже никогда не путал, но было, например, когда все цели гарантированно удовлетворены, а кост не 0. И начинается... По наблюдения он ооочень часто глючит с фазой и углами вообще, т.е. рисуешь график целевой ф-ции, вроде все ок, а кост - от фонаря(или новая версия глюка описанная выше). Скорее всего путаются граусы и радианы. Так же может глючить с полевыми решениями, т.е., например, построенный график коэф. эллиптичности и тот, что в целевой ф-ции тоже разные. Совсем печально, что выходит, что у них в недрах функции, которые считают формулы в репортах и в опт. сетапе - разные... Такое впечатление, что там коллектив 1000 человек делает hfss и они не договорятся друг с другом. Лечилось пересозданием опт сетапов, фар филдов, комбинированием порядка целей и просто принесением жертв духам ансиса... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Hale 1 13 июля, 2016 Опубликовано 13 июля, 2016 · Жалоба я оптимизируя фазу и согласование в ферритовых железках часто вынужден был брать среднее от |S21|+|S12| и |S11|+|S22| ну и функции от фазы. сталкивался с тем, что когда ищешь максимум децибелл, он улетал куда-то за край, явно в поисках максимума модуля децибелл. Как только я вместо dB(S21) подставлял логарифмы, а еще лучше, брал модули с минусом (откуда в пассивном устройстве взяться плюсу), то все исправлялось. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Pir0texnik 0 13 июля, 2016 Опубликовано 13 июля, 2016 · Жалоба Это в смысле максимизировали (минимизировали) какую-то ф-цию? Никогда такого не делал, обычно задаю "сделай больше (меньше) чем x дБ". Как-то эти методы ... не внушают, хз, люблю чисто канретно. Кстати, оптимизатор hfss вполне уважает границы, в отличие от, например, некоторых методов томлаба, где надо явно указывать, чтобы он их уважал, иначе выползет за границу только так. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Hale 1 14 июля, 2016 Опубликовано 14 июля, 2016 · Жалоба я стараюсь чтобы веса функции имели какие-то наглядные, легкодифференциируемые на глаз значения. чтобы в процессе оптимизации поглядывая остановить где надо и досчитать очевидную оптимальную точку руками. Тем более что в невзаимных устройствах с потерями оптимального согласования часто нет и приходится руководствоваться абстрактным понятием меньшего зла. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться