Ugstructures

[Victor_ 0]

Приветствую, кто работает в UGStructures.

Я столкнулся с проблемой построения сетки на модели, представляющей большую (260 элементов) трубчатую ферму. Работаю в W2K, имею 2 GB, 3 GHz. Программа строит сетку, потребляя примерно 1 GB физической памяти, и не пользуется свопом. Когда остается еще примерно 750 MB физпамяти, UG либо повисает, либо вылетает, с сообщением Out of memory in Storage Manager, при ппытке сохранить модель - детель корраптед, вам лучше пререшрузить UG. Если же ячейку взять покрупнее, построение сетки завершается (но много ошибок в ячейках, и расчет не проходит), но физ память не возвращается, так что для следующего построения нужно перегружать UG. Почнему UG не пользуется свопом, чем занята физпамять, кто в курсе?

Ошибок в Операционной системе не обнаружено.

[nut888 3]

Приветствую, кто работает в UGStructures.

Я столкнулся с проблемой построения сетки на модели, представляющей большую (260 элементов) трубчатую ферму. Работаю в W2K, имею 2 GB, 3 GHz. Программа строит сетку, потребляя примерно 1 GB физической памяти, и не пользуется свопом. Когда остается еще примерно 750 MB физпамяти, UG либо повисает, либо вылетает, с сообщением Out of memory in Storage Manager, при ппытке сохранить модель - детель корраптед, вам лучше пререшрузить UG. Если же ячейку взять покрупнее, построение сетки завершается (но много ошибок в ячейках, и расчет не проходит), но физ память не возвращается, так что для следующего построения нужно перегружать UG. Почнему UG не пользуется свопом, чем занята физпамять, кто в курсе?

Ошибок в Операционной системе не обнаружено.

<{POST_SNAPBACK}>

Я думаю что свопом она пользуется

Просто как мне кажется программа так написана что использует при работе

с памятью либо realloc либо std::vector<>

Что приводит к тому что при увеличении требуемой памяти

может понадобится минимум ее удвоенное количество

1) Захватили память

2) Скопировали туда то что было

3) Освободили

Заметьте что на этапе 1-2 памяти нужно как минимум в 2 раза

больше чем реально требуется

Предлагаю использовать для решения этой проблемы XP

с ключом 3GB

[6a6a KJIABA [u3 gepeBHu] 0]

to nut888

Почему объём распределённой памяти должен быть как

минимум в 2 раза большим? Из 1 Гб занятой памяти примерно

половина это ядро UG и сама модель (260 труб). Вторая

половина расчетная. Сливать первую половину нельзя.

Если Виктор пишет, что до момента ошибки еще 750 метров

свободных, значит своп не востребован. Объем свопа по

умолчанию = 1.5 х физ.память, поэтому проблем с нехваткой

памяти быть не может. Скорее всего, проблема либо с самим

модулем, либо с корректностью модели. Поэтому необходимо

для начала определить источник ошибки (попробовать

достоверные модели), потом думать как решить вопрос.

Однозначно переход на XP с любой подкачкой проблему

не решит.

[Victor_ 0]

[to 6a6a KJIABA [u3 gepeBHu­],

На модели меньшего объема (до 200 элементов) сетка строится успешно, и решение получаю, хотя с дефектами - почему-то у отдельных элементов (2-3 шт) один конец отклеивается от модели и деформируется самостоятельно, - один конец болтается в воздухе. При этом заметных дефектов в модели не обнаруживаю - все поверхности соединяются без дефектов.

Однако в модели довльно много "узких" мест, которые требуют меньших размеров сетки. Удовлетворяя этим требованиям, увеличиваем вес сетки, и памяти как бы не хватает для завершения.

Кто имеет опыт в Structures, помогите.

Изменено 16 января 2006 пользователем Victor_

[nut888 3]

to nut888

Почему объём распределённой памяти должен быть как

минимум в 2 раза большим? Из 1 Гб занятой памяти примерно

половина это ядро UG и сама модель (260 труб). Вторая

половина расчетная. Сливать первую половину нельзя.

Если Виктор пишет, что до момента ошибки еще 750 метров

свободных, значит своп не востребован.

<{POST_SNAPBACK}>

Это не так

Если У операционки свободно только 750

А приложение у нее попросит например 800

То она соответственно ответит ему что памяти нет

Переставим себе что свободно 750

И есть например кусок непрерывной памяти 500

который мы хотим увеличить до 800

Если память не фрагментирована и операционка способна

просто увеличить существующий размер на 300 то проблемы нет

Если размер увеличить не получается то операционка

попробует выделить 800 и инициализировать 500 из нее

На этом этапе и наступит крах системы

Простейший пример

main()

{ std::vector<double> arr;

for(;;) arr.push_back(0);

}

Так вот

Данная программа будет работать до тех пор пока

arr не превысит 1гб хотя доступно 2

[6a6a KJIABA [u3 gepeBHu] 0]

Попробовал модель от Victor_ у себя (XP SP2, 1Гб памяти, 1.5Гб своп),

на отметке 1.2Гб тот же out of storage manager (своп использован).

Видно, что примерно то же место (2000 - 750 = 1250). Проблема не

связана с памятью.

[nut888 3]

,Jan 17 2006, 11:48]Попробовал модель от Victor_ у себя (XP SP2, 1Гб памяти, 1.5Гб своп),

на отметке 1.2Гб тот же out of storage manager (своп использован).

Видно, что примерно то же место (2000 - 750 = 1250). Проблема не

связана с памятью.

<{POST_SNAPBACK}>

Это только на данной модели такой результат

или его можно воспроизвести и на кубике?

То есть подобрать для кубика определенного размера

размер элемента таким чтобы он так же грохнулся при разбиении

при похожем отношении недоиспользованной памяти

Просто тест на то касается ли проявляющийся эффект

конкретной модели или он характерен для любых моделей UG

[6a6a KJIABA [u3 gepeBHu] 0]

Это только на данной модели такой результат

или его можно воспроизвести и на кубике?

Не ясен вопрос.

[Victor_ 0]

Это только на данной модели такой результат

или его можно воспроизвести и на кубике?

Вчера попытался провести апдейт W2k на XP, но не очень удачно. Придется сегодня заново ставить ХР, после чего посмотрим.

Спасибо за участие.

[Victor_ 0]

To nut888

"Предлагаю использовать для решения этой проблемы XP

с ключом 3GB"

Поставил W2003 с ключом 3GB, и проблема с памятью исчезла. Сейчас появилась возможность разбираться с моделью внимательнее.

Тем не менее странно, что UG не освобождает память после расчета сетки, время от времени надо перегружать UG для освобождения памяти. Но, благо что в пределах 2-3 пересчетов о памяти можно не беспокоиться.

Браво, Орешек, вы были правы.

[nut888 3]

To nut888

"Предлагаю использовать для решения этой проблемы XP

с ключом 3GB"

Поставил W2003 с ключом 3GB, и проблема с памятью исчезла. Сейчас появилась возможность разбираться с моделью внимательнее.

Тем не менее странно, что UG не освобождает память после расчета сетки, время от времени надо перегружать UG для освобождения памяти. Но, благо что в пределах 2-3 пересчетов о памяти можно не беспокоиться.

Браво, Орешек, вы были правы.

<{POST_SNAPBACK}>

Можно попробовать вместо перегрузки UG

использовать команду File->...Part Cleanup

Есть некоторая вероятность что память будет освобождена

По поводу освобождения памяти UG

совсем не обязательно она должна ее освобождать для операционки

(У нее свой менеджер памяти)

Важно чтобы она захваченную память повторно использовала

Тут средствами операционки вряд ли можно что-то проконтролировать

[Victor_ 0]

Можно попробовать вместо перегрузки UG

использовать команду File->...Part Cleanup

Есть некоторая вероятность что память будет освобождена

По поводу освобождения памяти UG

совсем не обязательно она должна ее освобождать для операционки

(У нее свой менеджер памяти)

Важно чтобы она захваченную память повторно использовала

К сожалению, Part Cleanup просит указать, что убирать, и про память - ни слова. Память не освобождает.

И также не использует память повторно. После каждого просчета вазрастает размер виртуального куска, наконец (после двух - трех просчетов большой структуры) приходится перегружать UG.

Решатель Structures PE что-то выдает ошибки (то проблема с Memory allocation, то что-то неладно с матрицей жесткости), а использовать ANSYS не удается - он решает практически до конца, до файла Results, но тут ему нужен большой кусок диска в HOME directory (Documents and Settings, etc.), а там свободно только 1.8 GB, и ему не хватает. Пытался переназначить свою HOME dirctory на другой диск, но это не помогает. Короче, копаюсь.

Учусь работать с большой структурой.

Изменено 25 января 2006 пользователем Victor_

[digger 0]

ключ /3GB - не самое лучшее решение. Сама MS говорит, что устойчивость системы сильно падает, есть и др. последствия. Если проц. поддерживает x64 - поставьте WXP x64 Prof. Хотя NX3 и в 32-бит кодах, памяти ему станет доступно в 2 раза больше, т.е. реально поставить 4 ГБ и почувствовать разницу :-)

PS: сегодня официально вышел NX4 для WXP x64 - закупайте память :-)

Изменено 26 января 2006 пользователем digger

[Victor_ 0]

Такое впечатление, что в Structures скверная диагностика: Finite Element Model Check говорит, что у вас все в порядке, в сетке ошибок нет, однако решение не проходит, в Analysis Job Information сообщение:

SYS_ERROR_COMPUTE A compute error has occurred

Matrix relative singular, iflag= 66

vfs_SysMatrixFactor: ierr= 7

SYS_ERROR_COMPUTE A compute error has occurred

Factorization error

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

Кто-нибудь знает, как эти сообщения можно использовать? О чем они говорят?

Впрочем, не так безнадежно. Чуть ниже в Analysis Job Information указывается адрес проблемного узла, можно его задать в Identify Node и увидеть на сетке, и проблема становится понятнее. Работать надо осторожно. Малейшая неуклюжесть, и расчет застревает.

Удалось просчитать ферму из тонкостенных труб количеством более 100 шт. Красиво.

Изменено 13 февраля 2006 пользователем Victor_