Jump to content

    

DmitryHF

Участник
  • Content Count

    155
  • Joined

  • Last visited

Community Reputation

0 Обычный

About DmitryHF

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

Recent Profile Visitors

2501 profile views
  1. На мой взгляд, если хотите увеличить производительность, то в любом случае придётся уходить от использования обычных 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 будет избыточно, хотя возможно у Вас кластер.
  2. Да, параметрический расчет займет много времени, но возможно и меньше чем создание скрипта)). Почему просто не хотите использовать оптимизацию в HFSS? Оптимизация поддерживает Derivatives, и с их включением в случае большого числа параметров мне кажется будет эффективнее чем параметрический расчет. Параметрический расчет сам по себе с Derivatives не скрестить, Derivatives считаться то будут, но доставать их данные придется видимо через скрипт. Вам для этого yurik82 и написал, что сначала лучше оптимизировать геометрию по КНД на максимально упрощенной модели в HFSS или в NEC. Получить основные размеры, а потом уже наилучшие варианты моделировать с большей детализацией. КНД при увеличении детализации уже сильно не измениться. Мне почему-то кажется, что в случае волнового канала все уже изобретено "до нас". И основные размеры для получения максимального КНД известны.
  3. Готового решения, по моему нет, но можно попробовать через скрипт сделать. Перебирать переменные используя oModule.SetTuningOffsets() и экспортировать. Скрипт будет оправдан если это Вам часто требуется делать. Если редко, то на мой взгляд проще через параметрический анализ.
  4. В первом посте Вы написали, следующее: Вы обратились к неопределенному числу лиц, с Вашими сомненьями. Мой ответ сводился к тому, что Вам это - показалось. Документ Ансиса приложен для развеивания сомнений. Вам это возможно уже стало понятно из просмотра логов, если нет, выкладывайте разберем в месте. Я допускаю, что возможно придумать такую задачу где виртуальные ядра не сильно проиграют. Это будет видимо когда время расчета задачи сильно меньше времени на ее подготовку, создание сетки и т.п., но основное назначение HFSS именно расчет, не пост обработка и построение сетки. Не нужно вводить читателей форума в заблуждение о полезности виртуальных ядер, для HFSS. Если хотите доказать обратное, придумайте такой проект и выложите. Думаю люди прошедшие аспирантуры знают, что надо делать когда "кажется" и могут представить что-нибудь помимо слов. ПС. Savant получал прирост от использования НТ, сейчас он превратился в SBR+ Solver и для него они может и полезны, не проверял.
  5. Вместо этой "простыни" которую Вы написали, не понимаю правда с какой целью, лучше выложите логи решения HFSS c использованием виртуальных ядер и без них (и проект для проверки). И тогда можно будет подискутировать. И да, задача лучше чтоб была по размерам ближе к реальной, на несколько Гб (несколько десятков тысяч тетраэдров). А потом продолжим открывать секреты)))
  6. Не тратьте время на переустановку, результат получите тот же. Я в качестве примера выкладывал проект с изменением радиуса, но таким же образом можно было поступить и с высотой и с чем угодно. Вам видимо самым удобным будет вариант каждый раз меняя магнит удалять в HFSS дизайне MagBias > сохранять проект > затем заново назначать MagBias. Или с глобальной переменной для размера магнита тоже может получиться.
  7. Еще раз, заново, запустил весь проект который выложил. В нем изменяется диаметр магнита, переменная RadOffset. Все работает, разные S параметры в зависимости от размера.
  8. Опять двадцать пять, "кастрированное" ядро никогда не станет нормальным. Не равна его производительность нормальному,и если для каких-либо простых задач (браузер, ворд и т.п) и достаточно возможностей "кастрированного" ядра, то для полноценного расчета в HFSS нет. Конечно для каких-то этапов расчета, возможно построение сетки или может пост-обработка и будет небольшое ускорение, но в целом оно либо не значительно, либо его нет вовсе или станет медленнее. И если сравнить стоимость НРС лицензии (для лицензии все равно какое ядро) с получаемым от использования HT ядер приростом производительности, то ответ будет очевиден. В принципе Вы можете и не отключать HT, главное на них не считать и задавать в параметрах расчета число физических ядер.Современные ОС различают физические ядра и виртуальные, и отправляют расчет в первую очередь на физические. R17 Hardware Recommendation.pdf
  9. Уверен, что причина в другом. У меня работает.Изменял радиус магнита. Проект во вложении. Ferrite_Circulator2020R1.aedtz
  10. C версии 17.2 есть.
  11. Можно Не понятно, поясните. Во вложении пример Coax_Step_Opt_2019R3.aedtz
  12. В circuit дизайне это делается одной кнопкой в Smith tool.
  13. Практически то же самое, что и Вы хотите, реализовано в HFSS через Derivatives. Эта вкладка есть в настройках решения. Отмечаете на этой вкладке соответствующие переменные дизайна. Для отмеченных переменных, после решения можно изменять значения (через Report Tuning) в реальном времени (в небольших пределах) и наблюдать соответствующие изменения S-параметров или поля в дальней зоне ДН, усиление. В этом случае расчет займет немного больше времени, т.к. HFSS для выбранных переменных будет искать решение связанное с их изменением. Точность такого расчета будет тем меньше чем, больше значение переменной отличается от номинала. В общем случае, при изменение не более 5-10% от номинала получается довольно точно. В любом случае, можно сразу понять в какую сторону надо изменять параметр. Более подробно см. в справке про Derivatives. Посмотрите встроенный пример tune_coax_fed_patch, из него можно понять как это делается.
  14. Эта возможность появилась когда Designer и HFSS в один GUI объединили, с 2015 года и видимо по 2019. Сейчас в 2020 правда не актуально стало, лицензия optimetrics входит в состав HFSS. Подключенный hfss дизайн считается со своими НРС настройками, т.е. не на одном ядре. Оптимизация одна, т.е. в этом случае parametric последовательно будет считаться, а в параллель таким способом не уверен, что можно запустить. Вариант именно с параллельным parametric я не пробовал, может и будет работать.
  15. В данный момент проверить не могу, но раньше работал "альтернативный" способ запуска оптимизации без лицензии optimetrics. Может Вам пригодиться. Для этого нужно подключить hfss дизайн в схемный дизайн (т.н. Dynamic Link). Переменные hfss дизайна видны в схемном. Далее создаете оптимизацию в схемном дизайне и запускаете. Все работает, так как оптимизация в схемном дизайне работает без лицензии optimetrics. Ansys это конечно особо не афишировал)))