Перейти к публикации

ANSYS 13 - обсуждаем работу нового продукта здесь!


™•-=MASTER=-•™

Рекомендованные сообщения

забыл еще про один "нюанс" упомянуть:

вся модель разбита на "группы" (Named Selections)

создана сетка

но как только задаются "новые" граничные условия или создаются дополнительные "группы",

WorkBench начинает заново генерировать сетку....

какая связь между заданием граничных условий и\или созданием новых Named Selections - понять не смог!!!

т.е. такая же "ерунда", как и созданием "новых\дополнительных" контактных поверхностей - там то же самое:

= WorkBench начинает строить сетку заново!

Справедливости ради, надо заметить что WorkBench не всегда заново начинает генерацию сетки....

но все равно - получается лоторея - будет или не будет.....?!

Хорошо если генерация сетки выполняется за несколько десятков минут и такое "сюрприз" не критичен

а если сетка генерируется в течении нескольких десятков часов - т.е. нескольких суток непрерывной работы?

Изменено пользователем ValeryMoscow
Ссылка на сообщение
Поделиться на других сайтах


но как только задаются "новые" граничные условия или создаются дополнительные "группы",

WorkBench начинает заново генерировать сетку

очень странно, у меня такого ни разу не было. Обновление сетки требовалось иногда после suppress/unsuppress отдельных тел, что тоже непонятно почему.

Ссылка на сообщение
Поделиться на других сайтах

очень странно, у меня такого ни разу не было. Обновление сетки требовалось иногда после suppress/unsuppress отдельных тел, что тоже непонятно почему.

это как раз понятно - программа ставит "индекс" - старый или новый "объект" и ТУПО уже не проверяет - есть ли там сетка или нет?

это так же крайне не удобно, что при подавлении объекта - нужно заново делать сетку....

но эта ситуация хотя бы имеет более-менее правдоподобные "гипотезы"....

а вот создание сетки заново (причем не понятно при каких при "признаках" объекта) это будет делаться , а когда нет

- создает "дискомфортную ситуацию".....

Хочется еще раз отметить - как "лихо" WorkBench транжирит память!!!

16 оперативной + 42 виртуальной - во время генерации сетки!!!!

ЖУТЬ!!!

Изменено пользователем ValeryMoscow
Ссылка на сообщение
Поделиться на других сайтах

16 оперативной + 42 виртуальной - во время генерации сетки!!!!

нехило.... точно в ВБ-коде коряво динамические массивы используют.... если с ними небрежно работать, память замусоривается достаточно быстро..... я больше не вижу рациональных объяснений для занимания 58 Гб памяти при построении сетки ... )))

Ссылка на сообщение
Поделиться на других сайтах

на самом деле модель большая,

но все равно - расход памяти просто ЧУДОВИЩНЫЙ!!!

вот сейчас решаю задачу - примерно 1400 "объемов" (примерно 6,7 млн КЭ)

даже без счета - просто загруженная модель - резервирует (использует) 24,9 Гб памяти!!!!

*** 16 оперативной, остальное виртуальная память

самое печальное, что судя по всем признакам - во время счета WorkBench ничего не изменяет !!!

т.е. перераспределения памяти не происходит во время счета - WorkBench не "выгружает" на диск не нужную во время счета информацию!

Изменено пользователем ValeryMoscow
Ссылка на сообщение
Поделиться на других сайтах

вышеупомянутая задача только что "приказала долго жить"....

WorkBench выдал сообщение о "внутренней" ошибке и прекратил решение....

хорошо хоть не уничтожил саму базу, как это иногда случается

понять - по какой причине это произошло, не представляется возможным...

*** решается линейная задача - статика, правда контактных поверхностей много...

Изменено пользователем ValeryMoscow
Ссылка на сообщение
Поделиться на других сайтах

*** решается линейная задача - статика, правда контактных поверхностей много...

контакт это нелинейная задача. может в этом дело?
Ссылка на сообщение
Поделиться на других сайтах

решается линейная задача - статика, правда контактных поверхностей много...

Залача с контактными поверхностями - это нелинейная задача. :unsure:
Ссылка на сообщение
Поделиться на других сайтах

Не обязательно. Если область контакта известна, например в задаче о вдавливании штампа, то вполне линейная.

Такие проблемы с разбиением из-за экпоненциального роста проверок при разбиении. Когда домики считаю иногда такое возникает. Поэтому уже рефлекторно разбиваю сначала перекрытия, у них не сопряженные поверхности и проверка не происходит, а уж потом стенки, колонны. Тогда проблем обычно не возникает. Но это на apdl...

Ссылка на сообщение
Поделиться на других сайтах

Не обязательно. Если область контакта известна, например в задаче о вдавливании штампа, то вполне линейная.

Вот только заготовка не имеет форму штампа. Поэтому для зоготовки задача нелинейна.

Такие проблемы с разбиением из-за экпоненциального роста проверок при разбиении.

Не сгущайте краски Федор. Не все так безнадежно. Есть приемы, которые понижают данный рост и делают его линейным.

Но хотелось бы увидеть модель. А пока это беспредметный разговор.

Отсутствует предмет оьсуждения. :unsure:

Ссылка на сообщение
Поделиться на других сайтах

одна из наиболее часто появляющихся ошибок WorkBench:

An unexpected error (SIG$SERV) has occurred...

ANSYS internal data has been corrupted.

ANSYS is unable to recover and will terminate.

Ссылка на сообщение
Поделиться на других сайтах

An unexpected error (SIG$SERV) has occurred...

ANSYS internal data has been corrupted.

ANSYS is unable to recover and will terminate.

В Классике такое тоже часто встречается.
Ссылка на сообщение
Поделиться на других сайтах

В Классике такое тоже часто встречается.

в древнем АНСИС такие ошибки у меня были весьма редко за 26 лет!!!

в WorkBench - такие ошибки РЕГУЛЯРНЫ!!!

Кроме того WorkBench выдает и другие "сюрпризы" - иные ошибки, вплоть до полного разрушения базы!

сейчас посмотрел результат работы за ночь -

WorkBench СОЖРАЛ 293 Гб дискового пространства на решение ОДНОЙ задачи - статика!!!

записывался только конечный результат!!!

ЧТО (какие результаты расчетов) можно записать в таком объеме - я просто не понимаю!!!

Кроме того, нужно постоянно чистить диск от "временных" файлов, которые WorkBench "забывает" убирать!

И как часто? Сколько раз в день?

за день я успеваю провести для одной задачи изменения базы только один раз - проблема в большой размерности!

ибо на открытие базы WorkBench тратит около ОДНОГО ЧАСА!!!

на сохранение базы - около 1,5 часов

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

*** любопытства ради посмотрел сколько времени уходит на каждый этап у тех - кто работает с MSC\Nastran

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

время на каждую операцию - как минимум в несколько раз меньше!!!!

сейчас почти уверен, что причина такой "производительности" работы в "некорректной" архитектуре базы

еще проконсультировался с "писателями", которые до сих пор пишут собственные программы

они были КРАЙНЕ "УДИВЛЕНЫ" размерами рабочих файлов WorkBench!!!!

я попросил их высказать гипотезы по этому поводу: Какие могут быть причины?

ничего внятного они сказать не смогли..... ОТКУДА такие размеры данных?

но особенно их поразило кол-во памяти - которое WorkBench резервирует!!!

*** правда они выразили сомнение, что всю зарезервированную память WorkBench использует....

на третьем компьютере сейчас обнаружил ОЧЕРЕДНОЙ - уже НОВЫЙ сюрприз!

в модели создано около 450 виртуальных поверхностей.

потребовалось сгустить сетку в двух местах

но НЕОЖИДАННО WorkBench уничтожил три виртуальные поверхности

потребовалось более 2-х часов, что бы среди деталей найти те - к которым эти уничтоженные поверхности относятся

кроме поверхностей, WorkBench уничтожил и несколько линий - вот как индифицировать - это я еще не придумал!

как результат - теперь WorkBench не желает создавать сетку, ссылаясь на отсутствие стертых им же виртуальных поверхностей и линий

А главное - как теперь все это "лечить"???

хорошо, если поверхности и линии - относятся только в найденым трем деталям, а если нет?!

в общем есть шанс потратить на создание сетки заново еще 3-4 суток......

Изменено пользователем ValeryMoscow
Ссылка на сообщение
Поделиться на других сайтах

сейчас посмотрел результат работы за ночь -

WorkBench СОЖРАЛ 293 Гб дискового пространства на решение ОДНОЙ задачи - статика!!!

записывался только конечный результат!!!

Какие параметры модели? Сколько узлов, элементов, степеней свободы?

Прямой или итерационный метод решения?

Ссылка на сообщение
Поделиться на других сайтах

An unexpected error (SIG$SERV) has occurred...

ANSYS internal data has been corrupted.

У меня с похожей по размерам задачей было такое же..... создал dat-файл и запустил задачу через лаунчер - прошло без ошибки

Ссылка на сообщение
Поделиться на других сайтах

сейчас посмотрел результат работы за ночь -

WorkBench СОЖРАЛ 293 Гб дискового пространства на решение ОДНОЙ задачи - статика!!!

записывался только конечный результат!!!

Много места уходит во время расчета. После окончания расчета - все борохло удаляется, и остаются одни результаты.

An unexpected error (SIG$SERV) has occurred...

ANSYS internal data has been corrupted.

Очень редко... может было пару раз на ровном месте. Никакого препятствия не представляла.

Из всех, что были до v10 - десятая версия самая стабильная. Молодые версии не смотрел...

Ссылка на сообщение
Поделиться на других сайтах

Какие параметры модели? Сколько узлов, элементов, степеней свободы?

Прямой или итерационный метод решения?

около 7,8 млн КЭ

умножаем на три степени свободы - вся модель - "solid"

решатель итерационный

только не пойму:

какая разница какой решатель?

речь идет о том: ЧТО - в таком огромном объеме WorkBench записывает в базу при выполнении СТАТИЧЕСКОГО расчета и при записи лишь последнего шага!?

А что же тогда делать, если нужно будет записать несколько шагов или например будет динамика?!

Какого же размера тогда будет база для модели более-менее большой размерности?

при таком "аппетите" WorkBench - никакие диски не спасут!

Изменено пользователем ValeryMoscow
Ссылка на сообщение
Поделиться на других сайтах

около 7,8 млн КЭ

умножаем на три степени свободы - вся модель - "solid"

Это количество КЭ или количество узлов?

Зачем количество КЭ умножать на три?

Ссылка на сообщение
Поделиться на других сайтах

около 7,8 млн КЭ

умножаем на три степени свободы - вся модель - "solid"

если узлов 7,8 млн и нет вращательных степеней - то да...

если 7,8 млн элементов - то сложнее подсчитать... кол-во dof-ов равно 3*N узлов в элемента - кол-во связей между узлами внутри элемента.... да еще надо учесть общие узлы у элементов.... так никто не считает

Ссылка на сообщение
Поделиться на других сайтах

Присоединяйтесь к обсуждению

Вы можете опубликовать сообщение сейчас, а зарегистрироваться позже. Если у вас есть аккаунт, войдите в него для написания от своего имени.
Примечание: вашему сообщению потребуется утверждение модератора, прежде чем оно станет доступным.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.



  • Сообщения

    • davidovka
      в уравнении Гибкой области ячейки наименование первую строку исправьте на  r=ptstrim(1,asm_mbr_НАИМЕНОВАНИЕ,22,0)  
    • M_u_x_a
      @fenics555, согласен с Вами полностью. Риски, о которых Вы говорите - имеют место наравне с прочими. Выкладываю шаблон и форматку, сохранено в Creo 11. Если сравнить мануалы, реализовано по-разному. Но правка результатов не принесла.  
    • RokiSIA
      Вот и попались, пусть теперь они уже отбрехиваются
    • davidovka
      Выкладывайте свои, посмотри что не работает.
    • Anat2015
      А что, бывает по другому, программисты и операторы сразу сознаются?
    • fenics555
      так пока кто-то пользуется кнопкой "сделайкрасиво" он набивает номенклатуру, библиотеку изделий, с уже неправильно указанными параметрами. И вдальнейшем другим конструкторам пользоваться штатными средствами никак не получится, кроме как открыть КАЖДЫЙ файл, добавить нужные парметры (тут можно импортом из шаблона)  и лапками подправить. КАЖДЫЙ! И сборки. Все. Еще с булками разобраться. Иначе без этой DLLки выводиться будет ерунда. ДАЖЕ СРАНЫЙ ЧЕРТЕЖ ОБЫЧНОЙ ДЕТАЛИ! И никто другой даже не додумается, в чем же дело. Ну вот возьмет он (Конструктор с кнопочкой умной) и уволится от неразделенной любви, или по дороге на работу разобьется. Ну фактор человеческий. Бывает. Он работал, получал ЗП за то, что делал "вроде правильно", но любой другой придет- и не сможет сразбегу "в красоту"! И Бос такой, затягивая сигару: "Эх, салага, вот Стас был- да! ..." Ну там, слеза скупая, всё такое. И не объяснить, что он х8йню делал. Поэтому я стараюсь работу работать так, чтоб после меня "Фен -просто красавчик" сказал тот, кто будет после.
    • M_u_x_a
      Уважаемые Господа @fenics555 и @-stas- ! Каждый из вас по-своему прав. Пользоваться или нет дополнительными приложениями при возможности реализации штатными средствами - это выбор каждого инженера. Тут влияет ещё и специфика работы, взаимодействие с другими инженерами и тд. Лично я, пожалуй, вижу в конкретно этом инструменте скорее положительное, нежели бесполезное. В списке дополнительных приложений запущено и работает. Дело в том, что тот релиз, на который я жаловался, был под Creo 1. С этим мне помог уважаемый @davidovka , за что мой ему поклон. Однако, желаемого результата достичь не удалось, несмотря на правку графы таблицы согласно инструкции-мануалу. Теперь там просто пусто, не заполняет. Прошу кинуть в мою сторону шаблон детали и форматку с которыми оно точно работает. Успехов всем в делах и делишках.
    • Сергей Кочев
      При разборе полётов, все утверждали, что программа отлажена и её ни кто не менял и сделали по ней две детали. Ну вот зашёл в свойства файла программы и увидел, что программу редактировали именно в день аварии. Сздана 11.10 Изменена 30.10. Был в отпуске хотел посмотреть Action Log к сожалению уже данные перезаписались.
    • Даниил_91
      спасибо, просто по поиску не нашел конкретной темы кстати надо попробовать, об этом даже не подумал, спасибо
    • Onizuka
      Удалите параметр DRAWN_BY и создайте снова. Список должен обновиться после этого
×
×
  • Создать...