KSergP

благодарю.

ДА, КЛАВУ КЛИНОНУЛО....ЗАВТРА ОБЯЗУЮСЬ ПЕРЕСТАТЬ ТАК ПИСАТЬ!

СОБСТВЕННО ИЗ НАЗВАНИЯ ВСЕ ПОНЯТНО.

я всегда думал что расстояние до абсорбирующих границ определяется основываясь на длине волне\частоте. в моем случает вибратор находится внутри корпуса, а учитывая что частота не изменяется, то и границы должны оставаться на прежнем месте. такое ощещение что FIT разбил анализируемый объем на ячейки и ему все равно что в них. раньше был воздух или вакуум, а потом стал металл. но я раньше думал что и FDTD поступает таким же образом... :unsure: тем и хороши эти объемные методы, по сравнению с тем же методом моментов. а тут получается что EMPIRE поступила почти также как МоМ-солвер....

т.е. подводя итог получаем, что FIT-TD эквивалентен FDTD в декартовых координатах. собственно другой вопрос. моделировала один и тоже пример (корпус, возбуждаемый вибратором) в EMPIRE,основанной на FDTD и во временном солвере CST. менял длину вибратора и смотрел как изменялось количество ячеек меша. при изменении длины CST выдовало одно и тоже количество, а в EMPIRE оно увеличивалось...что приводило к увеличению времени вычислений. так вот если методы эквивалентны, то почему же так происходит? на элементарные объемы Results -> View Logfiles -> Solver Logfile

я где встречал, что в декартовых координатах метод FIT эквивалентен методу FDTD. кто-нибудь может это подтвердить?

похоже и это в моем случае не поможет. в общем, я хочу попробовать использовать гибрид MoM-FEM... чтобы мом разбивал поверхности, а фем объемы, но как я убедился но это происходит только когда объем заполнен чем-то кроме Free Space. создаю блок, у него на верхней стороне должны быть щели. создал воздух, с теме же параметрами что и у free space.... но после того как пытаюсь вырежать щели вылетает ошибка, что данная операция не может быть применеа поскольку получается разница в физических свойствах. :cranky:

хочу заменить внутренне пространство с Free space на воздух, но объект входит в union и поэтому напрямую этого сделать нельзя. Поэтому как можно "разбить" union?

посчитал пример, получил log file, в котором указано сколько затрачено физической и виртуальной памяти. отключил использование файлов подкачки, НО использование как виртуальной, так и физической не изменилось. так и должно быть?

значит я правильно сделал, спасибо.

подскажите как получить значение напряженности поля не на плоскости, а в определенной точке при возбуждении плоской волной?

дык Alex Z и писал, что "забил" на MLFMM и считал стандартным MOM. меня вот больше другое удивляет, почему на одну итерацию тратится уйма времени. из выходного файла видно, что оперативки для хранения матриц хватает. 2Alex Z: а в "основной" задаче сколько памяти затрачивается? и вообще вы писали что у вас 4ГБ ОЗУ....а винда 32битная разве позволяет ее полностью использовать? такое ощущение, что памяти не хватает и прога на винт ачинает сохранять....тогда точно долго считаться будет.

как ни странно, но я бы посоветовал задать значение level-of-fill больше 12 (12 у вас прога задавала по умолчанию)...около 30 (может больше). время итерации должно вырасти (скорее всего не значительно, поскольку в матрице из которой делается preconditioner очень много нулей), но это должно улучшить качество preconditioner, что должно привести к сокращению итераций и тем самым сокращению общего времени решения. ну и второе, что можно посоветовать...попробуйте SPAI preconditioner.иногда он тоже неплохо считает.

посмотрел....вы точно уверены что на одну итерацию затрачивается 15минут???

а если выбираете MLFMM то порядок матрицы (MLFMM) какой? по идее она должна быть меньше. я что-то не особо могу представить какая у вас матрица получается, поэтому сложно предположить какой лучше level-of-fill (в случае ILU precoditioner) посоветовать, но обычно этот параметр не больше 5. SPAI тоже можно попробовать, но предварительно тоже полезно было бы узнать сколько нулевых или не нулевых элементов в исходной матрице. прикрепите выходной файл....тогда может еще чего посоветую.