При расчете на CadFeko 5.4 появилось сообщение :
ERROR 34013: Not enough memory available for dynamic allocation
и рассчет прекратился.В хэлпе нашел о динамической памяти,
но где это использовать не понял.
Если кто-нибудь знает подскажите плиз.
Уменьшить сегментацию не могу ,и так уже на пределе.

Alex Z.

Не думаю, что какие-либо сеттинги могут помочь в случае нехватки памяти. Расскажите сколько памяти есть, сколько требуется (или сколько неизвестных), версия 32-битная или 64-битная? И что за задачка, если не секрет?

Версия 32- битная . Памяти 4 Гб,сегментов 25000,eges 5000.Проект -
элипсоидная вырезка параболоида вращения размером 10х4 метра,
облучаемая рупором .Отражатель в виде горизонтальных wire сегментов.

Alex Z.

Вы не написали какой метод используете для расчета.. MLFMM требует значительно меньше памяти чем обычный MM
Ещё можете попробовать задействовать несколько компьютеров и использовать параллельные вычисления через mpi. При этом требования к памяти на каждый процесс уменьшаются пропорционально количеству используемых процессоров.
А ещё для зеркальных антенн есть специализированный софт - Ticra GRASP - он требует минимальное количество памяти для расчета и вообще быстро и довольно точно считает считает такие задачи.

Вначале использовал MLFMM,но рассчет очень медленно сходится ,ждать более 9часов не могу,
рабочий день кончается ,при этом неизвестно сойдется ли он (не более 500 итерраций).
Пробовал mpi ,хотя накаждый процесс требуется меньше памяти ,то в общем на 2 процесса
(2Core) необходимо больше.Перешел на MM ,тише едешь дальше будешь.Проблема
с временем.Очевидно нужна 64 битная версия и больше ОЗУ.
Alex Z.

я имел ввиду распараллеливание расчета на несколько компьютеров по сети через mpi. тогда в общее количество памяти будет равно сумме памяти всех задействованных компьютеров а лимит 32bit ни на одном из них превзойден не будет. ну или действительно переходите на 64bit.
и с MLFMM поэкспериментируйте. иногда сходимость можно улучшить с помощью настроек сетки.

там и без сетки есть с чем поэкспериментировать.
например, с парметрами precondition.
если их выбрать небольшими, то можно очень много итераций получить....

2 Alex Z:
а размер матрицы в данном примере какой?

и что вы этими словами
" при этом неизвестно сойдется ли он (не более 500 итерраций)."
подразумевали, а то я что-то не понял.

Спасибо за подсказу.Учить матчасть надо.Я обычно использовал в precondition - default.
А количество иттераций куда уж увеличиваь,если на одну итеррацию требуется 15 минут.
Просчитал 6 часов , а residuum достиг не менее 0.01.А под сойдется я имел ввиду
достижения residuum как default уровня 0.03.

Alex Z.

матчасть)) residual-невязка...
если хотите ДН посмотреть...то невязка 0.03 еще както приемлема, а если токи то ее по меньше советовал бы брать.
"если на одну итеррацию требуется 15 минут."
а тип предобусловливателя (precondition) какой и его параметры какие выбираете?
и размер матрицы можете сказать?

а то действительно 15 минут уж слижком много.

Насчет матчасти я имел ввиду себя.Если вы о матрице из *.out то она
(МОМ) 38128 х 38120 . А precoditioner брал default.
Alex Z.

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


SPAI тоже можно попробовать, но предварительно тоже полезно было бы узнать сколько нулевых или не нулевых элементов в исходной матрице.

прикрепите выходной файл....тогда может еще чего посоветую.

Прикрепил *.out.
Alex Z.

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

В этом расчете 5 минут.Здесь я рупор возбуждал wire.
А до этого пробовал возбуждать волноводным портом и
тогда действительно итеррация длилась 15 минут.
Alex Z.

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


ну и второе, что можно посоветовать...попробуйте SPAI preconditioner.иногда он тоже неплохо считает.

Задача вроде не особо большая. Вы уверены, что без FMM не обойтись? Интересно было-бы посчитать напрямую, если бы была доступна сама модель.

дык Alex Z и писал, что "забил" на MLFMM и считал стандартным MOM.

меня вот больше другое удивляет, почему на одну итерацию тратится уйма времени.
из выходного файла видно, что оперативки для хранения матриц хватает.

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

ОС 32 -битная, а памяти извиняюсь 3 Гига (при загрузке комп показывает около 3.2 Гига) комп Р3000.

Прога на винт может по-разному сохранять - бывает что просто система дает возможность аллокировать больше памяти чем есть и уходит в swapping. Программа работает как-будто с нормальной памятью, а на самом деле с винтом. Тогда все реально очень тормозит. В другом случае использаются специальные солверы ориентированные на out-of-core решение - сами аккуратно записывают что надо на винт и работают только с реальной памятью. В ЕМС Studiо это просто переключается автоматически (или если очень надо вручную), а в ФЕКО как я помню можно указать лимит памяти в pre файле через переменную #maxallocm = 1024 или сколько нужно (может сейчас уже есть и интерфесная поддержка). Нормальная производительность достигается - вполне терпимая. Начиная с версии 5.3 ФЕКО может аллокировать как 32-битная программа около 1.8 Гб, предыдущие версии - не более ~1.4 Gb.