А потомучто весь проект - это одна большая круглая дура, выточенная из единого куска pec'а, на пимпочке у которой сидит порт.

Ну как бы да, но почему не работает то? Менее сложная конфигурация считается на ура. Дайте более развернутый комментарий, если не затруднит.

>setur
Port 1 does not have a solved inside material on either side = Порт 1 с обеих сторон не имеет материала, имеющего в свойствах "solved inside".
Т.е. объем, который вы через порт пытаетесь возбудить даже не имеет сетки. Вообще. Поскольку весь из pec'а. Измените материал на вакуум - получите полый резонатор, который, вероятно, вам и нужен.

cylinder1 embeded in cylinder4?? both PEC??

Чорт, точно, как же так, недоглядел)

А вообще насчет индуктивной петли я же не правильно делаю? Там надо как-то ток задать на поверхности петли видимо.

Ну уж это уж ваш "чемодан" .
Хотя, конечно, это колечко на палочке - вещь довольно сомнительная. Возможно, вам достаточно без всяких петель eigenmod'ом решать модные частоты/добротности. На чем гадать-то?...

Вы используете ГУ типа Symmetry (Perfect H), там коэфициентик нада изменить на 0,5

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

нет конечно чудо не случится, проек на мой взгляд вообще не рабочий, просто я решил добавить свою локу дёгтя



..пригодится для общего развития

Поставил рассчитываться проект со свипированием частоты. На каждой частоте прогресс доходит до этапа "solving matrix part 1 of 2", после чего прогресс-бар замирает и будто бы ничего не считается: активность проца низкая, оперативная память забита на 1,92 Гб (из 3 с чем-то) и уровень использования не меняется, процессы HFSS изредка обращаются к жесткому диску. Это при том, что на локальных дисках места предостаточно. Почему такая байда происходит? Проекты попроще считаются без таких "тормозов"
Думает он около часа. Каждый раз. Ппц.

Сообщение отредактировал zergo_am - Nov 21 2011, 04:43

Быстрая развертка требует самый большой объем памяти.
Если это не работает, вы можете попробовать дискретным или интерполяции.
Кроме того, попробуйте увеличить виртуальной памяти

Возможно, что программе все-таки не хватает для расчета оперативной памяти, вследствие чего для размещения элементов матрицы и ее решения она начинает использовать уже жесткий диск. В этом случае скорость расчетов как раз резко падает, а HFSS лишь периодически, изредка "грузит" процессор. Соответствующие "тормоза" связаны не с недостатком места на жестком диске, а с тем, что скорость работы с ним значительно меньше, чем с ОЗУ. Из личного опыта: соответствующие явления на ПК с доступным ОС ОЗУ около 3-3,5 Гб наступают при количестве тетраэдров где-то более 80 тыс.
Происходят ли у Вас подобные "тормоза" при расчете только одной частотной точки, т.е. без свипирования? Если так, то это уж точно не связано с самим свипированием.

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

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

Ага, так и происходит: как на одной частоте зависнет, жму abort, перезапускаю программу и повторяю анализ. Эту частоту обычно проскакивает, а вот дальше может опять зависнуть. В проекте 121 тыс. элементов.