Jump to content

    

DmitryHF

Участник
  • Content Count

    160
  • Joined

  • Last visited

Community Reputation

0 Обычный

About DmitryHF

  • Rank
    Частый гость

Recent Profile Visitors

2564 profile views
  1. Как вариант, если возможно, то поменять ориентацию в оригинальном CADе или в другом где есть такой функционал. Не уверен, что есть такая команда в HFSS, надо изучать (в SpaceClaim есть). Можно конечно повернуть нужные поверхности на 180 градусов через Rotate, но если их много это плохой вариант. А что мешает сделать Thicken sheet с опцией Both Sides и далее переместить на половину толщины, или у Вас поверхность не в одной плоскости? Или Thicken sheet с опцией Both Sides на удвоенную толщину и потом отсечь лишнее.
  2. Проблемы здесь нет, для 3Д редактора, сеточного модуля, решателя важно знать где какая сторона у листового тела. Поэтому если вы нарисуете в HFSS один прямоугольник слева-направо, а другой справа-налево, то в одном случае "лицевая сторона" будет снизу, а в другом сверху. И при использовании например Thicken sheet они будут вытянуты в разные стороны. Это тоже касается и ГУ, что важно например для Layered Impedance. Не знаю как в старых версиях а в 2020r2 если нарисовать так прямоугольники то они отображаются разными оттенками при одинаковом цвете, см. картинки. Возможно Вам поможет опция Both Sides
  3. Судя по результату операции, такой "забор" получается из-за того, что нормали этих поверхностей смотрят в разные стороны. Если отрезать плоскостью смещенной внутрь тела, то возможно у Вас получится одна поверхность вместо того что на рисунке. И эту поверхность потом получится вытягивать. Возможно этот способ и не подходит, т.к. видна не вся геометрия и ракурс не передает все особенности. Еще вариант - скопировать геометрию или ее часть, передвинуть и объединить с исходной. Придумать вариантов еще можно много, но какие Вам подойдут сказать сложно. При работе с сложными криволинейными поверхностями и телами частенько бывают проблемы.
  4. А пробовали сначала слегка подрезать сторону, чтобы убрать сегменты а потом уже делать Move или Sweep Face?
  5. Внутри структуры можно назначить типы портов - Wave, Lumped, Circuit. При использовании Wave, в этом случае, потребуется заглушка. Для моделирования диодов подойдут Lumped или Circuit. На один диод задаете два порта, для каждого вывода. Далее полученные s-параметры загружаете в MWO. Lumped назначается на 2д прямоугольник или плоскую поверхность 3д тела, для Circuit выберите два ребра и порт будет между ними. Во встроенных примерах достаточно проектов с Lumped портами. Справку посмотрите, разделы HFSS Help > Assigning Excitations for HFSS or HFSS-Transient > Assigning Circuit Ports HFSS Help > Assigning Excitations for HFSS or HFSS-Transient > Lumped Ports > Examples of Lumped Port Без примера проекта, сложно понять, на что и как у Вас ругается HFSS.
  6. На мой взгляд, если хотите увеличить производительность, то в любом случае придётся уходить от использования обычных HDD и для расчета, и для ОС. Если конечно у Вас обычный HDD. Даже простые SSD по скорости превосходят и High End HDD, и даже RAID из них. Насколько выиграет HFSS будет зависеть от задачи. Для расчета HFSS использует RAM, при более быстрых дисках ускорится обмен данными, постобработка. Если грубо оценить, то замена обычных HDD на SSD в среднем для расчетов, даст до 5-10% ускорения. Но есть нюансы, в зависимости от задач, если Вы много используете частотное свипирование, и у Вас много ядер (например от 8), это дает возможность считать несколько частот в параллель. В этом случае прирост от SSD будет больше (до 50%) т.к. при параллельном расчете обмен данными существенно вырастает. В использовании RAID 0 особых плюсов не вижу, у него выше только скорость чтения по сравнению с одним HDD диском. В Вашем случае просто отдельный HDD для расчетов даст примерно такой же результат. Для HFSS использовать RAID 0 из SSD будет избыточно, хотя возможно у Вас кластер.
  7. Да, параметрический расчет займет много времени, но возможно и меньше чем создание скрипта)). Почему просто не хотите использовать оптимизацию в HFSS? Оптимизация поддерживает Derivatives, и с их включением в случае большого числа параметров мне кажется будет эффективнее чем параметрический расчет. Параметрический расчет сам по себе с Derivatives не скрестить, Derivatives считаться то будут, но доставать их данные придется видимо через скрипт. Вам для этого yurik82 и написал, что сначала лучше оптимизировать геометрию по КНД на максимально упрощенной модели в HFSS или в NEC. Получить основные размеры, а потом уже наилучшие варианты моделировать с большей детализацией. КНД при увеличении детализации уже сильно не измениться. Мне почему-то кажется, что в случае волнового канала все уже изобретено "до нас". И основные размеры для получения максимального КНД известны.
  8. Готового решения, по моему нет, но можно попробовать через скрипт сделать. Перебирать переменные используя oModule.SetTuningOffsets() и экспортировать. Скрипт будет оправдан если это Вам часто требуется делать. Если редко, то на мой взгляд проще через параметрический анализ.
  9. В первом посте Вы написали, следующее: Вы обратились к неопределенному числу лиц, с Вашими сомненьями. Мой ответ сводился к тому, что Вам это - показалось. Документ Ансиса приложен для развеивания сомнений. Вам это возможно уже стало понятно из просмотра логов, если нет, выкладывайте разберем в месте. Я допускаю, что возможно придумать такую задачу где виртуальные ядра не сильно проиграют. Это будет видимо когда время расчета задачи сильно меньше времени на ее подготовку, создание сетки и т.п., но основное назначение HFSS именно расчет, не пост обработка и построение сетки. Не нужно вводить читателей форума в заблуждение о полезности виртуальных ядер, для HFSS. Если хотите доказать обратное, придумайте такой проект и выложите. Думаю люди прошедшие аспирантуры знают, что надо делать когда "кажется" и могут представить что-нибудь помимо слов. ПС. Savant получал прирост от использования НТ, сейчас он превратился в SBR+ Solver и для него они может и полезны, не проверял.
  10. Вместо этой "простыни" которую Вы написали, не понимаю правда с какой целью, лучше выложите логи решения HFSS c использованием виртуальных ядер и без них (и проект для проверки). И тогда можно будет подискутировать. И да, задача лучше чтоб была по размерам ближе к реальной, на несколько Гб (несколько десятков тысяч тетраэдров). А потом продолжим открывать секреты)))
  11. Не тратьте время на переустановку, результат получите тот же. Я в качестве примера выкладывал проект с изменением радиуса, но таким же образом можно было поступить и с высотой и с чем угодно. Вам видимо самым удобным будет вариант каждый раз меняя магнит удалять в HFSS дизайне MagBias > сохранять проект > затем заново назначать MagBias. Или с глобальной переменной для размера магнита тоже может получиться.
  12. Еще раз, заново, запустил весь проект который выложил. В нем изменяется диаметр магнита, переменная RadOffset. Все работает, разные S параметры в зависимости от размера.
  13. Опять двадцать пять, "кастрированное" ядро никогда не станет нормальным. Не равна его производительность нормальному,и если для каких-либо простых задач (браузер, ворд и т.п) и достаточно возможностей "кастрированного" ядра, то для полноценного расчета в HFSS нет. Конечно для каких-то этапов расчета, возможно построение сетки или может пост-обработка и будет небольшое ускорение, но в целом оно либо не значительно, либо его нет вовсе или станет медленнее. И если сравнить стоимость НРС лицензии (для лицензии все равно какое ядро) с получаемым от использования HT ядер приростом производительности, то ответ будет очевиден. В принципе Вы можете и не отключать HT, главное на них не считать и задавать в параметрах расчета число физических ядер.Современные ОС различают физические ядра и виртуальные, и отправляют расчет в первую очередь на физические. R17 Hardware Recommendation.pdf
  14. Уверен, что причина в другом. У меня работает.Изменял радиус магнита. Проект во вложении. Ferrite_Circulator2020R1.aedtz
  15. C версии 17.2 есть.