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

Точность вычислений в МКЭ программах. Делимся опытом.


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



Да я в смысле влияния разрядности на точность решения. Нахлебался когда-то

на ЕС досыта :unsure:

<noindex>http://www.pinega3.narod.ru/propis.htm</noindex> - в смысле графика в Заключении. Вы же поддтвердили, что вычисления

идут на пониженной разрядности real в видеокартах, а так я двумя руками за векторные конвейерные вычисления.

Только поддерживаю идею Страуструпа, что агрессивная оптимизация дело разработчиков компиляторов. :rolleyes:

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

Это, смотря, что понимать под словом РЕШЕНИЕ. Прямые методы не рулят. Это факт.

А здесь, что мешает поднять разрядность.

Я тоже в свое время нахлебался с double. Перешел на 16-ти байтные переменные. Пока не подводили.

С double проблем не испытывал. где-то 10**12 - 10**13 обусловленность нормально проходила и на прямых.

Да и сейчас в Ansys при земле, бетоне и железяках особых проблем нет при сильно искривленных формах элементов

иногда. А модули сильно разнятся. Я смещениями и поворотами проверяю арифметику , как обсуждали где-то здесь. :unsure:

Грубо можно оценить как отношение максимального диагонального к минимальному диагональному на пару порядков ошибетесь, но это мелочь обычно. Ну а точно надо искать минимальное и максимальное собственное число, как требует определение.

В Ansys при решении обычно видно максимальний и минимальный диагональный элемент.

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

У Стренга в алгебре есть концепт - число потерянных верных знаков решения примерно десятичный логарифм от числа обусловленности :unsure:

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

Можно и по другому сформулировать. Улучшайте обусловленность. Пользователю по барабану обусловленность и разрядность. Для пользователя важно соотношение цены (железо+софт) и времени получения результата.

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

Да и квалификации повышенной от пользователя. Тут все непросто по моему, эвристика. :unsure: Бесплатных канфет не бывает. Правильное решение дороже всего остального :rolleyes:

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

Федор вы что-то не поняли. Точность расчета на видео картах таже, что и на процессорах. Результаты одинаковые. Скорость выше. :clap_1: Про цены я уже писал, повторяться не буду. И никакой эвристики, только математика. :g:

Напишите статью, любопытно будет почитать :rolleyes:

Если конечно не рекламная, а по существу :unsure:

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

Так гипертекстовый постмодернистский мир же :unsure:

Ссылок на литературу в Ansys предостаточно, и, согласитесь, это не учебник

по методам вычислений :rolleyes:

Зачем избыточная технологическая информация. Есть достаточно литературы и Вы

ее прекрасно знаете, есть множество статей :rolleyes:

Конечно Help не учебник, а справочник. SAPIENTI SAT :rolleyes:

Мне когда-то Икрамов присылал список статей по разреженным технологиям. Я с ними знакомился,

но это было давненько и электронных носителей не было. Он же у Вас в Москве,

не ленитесь, найдите он поможет с литературой :rolleyes:

Но, как Вы справедливо отмечаете, тут многое связано с железом, а оно меняется :unsure:

В Ansys я не видел методов, которые не были бы описаны в литературе :unsure:

Тем программа и хороша, что работает штатно, без фокусов

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

Числа выводят по 16 цифр, разве трудно догадаться? :unsure:

Пользователям то это зачем? Вся эта возня со сдвигами, вопрос гипотез, типа коэффициента Пуассона 0.5 , мне они не интересны, не слежу.

Про устойчивость ничего не слышал, работает вроде штатно, как Эйлер прописал.

"У программистов принято считать, что в программе нет фокусов пока они не обнаружены" - само-собой, это как точное решение численными методами :rolleyes:

Помню на одной конференции показали график где невязка по перемещениям была сначала одного знака, потом по мере дробления на элементы стала

другого. Я, естественно, спросил, почему они не поискали разбиения пластины с точным конечным решением, когда аналитически оно представляется бесконечным

рядом. Естественный академик обещал найти и прислать ссылку где у других тоже невязка меняет знак. До сих пор не прислал :rolleyes:

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

При чем тут сдвиг, когда об устойчивости говорим? :unsure:

"Да неинтересны ваши догадки. Вывести можно и до 32 знака. Начинка важна" - это копиистам она важна,

остальным до лампочки. Если нормально перемалываются системы с обусловленностью около 10**12 то и к

гадалке ходить не надо :rolleyes:

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

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

Так в графике Заключения статьи на которую ссылался все показано :rolleyes:

Я в Бога верю, а не чудеса и бесплатный сыр :unsure:

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

Спасибо, времени нет, чтобы бесплатно тестированием заниматься :unsure:

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

<noindex>http://lenta.ru/news/2009/08/11/nvidia/</noindex> все еще очень неустойчиво на этих рынках. То, что экспериментируете похвально, никто же не спорит.

Я бы попробовал получить прямое разложение как у Джорджа и Лю описано и Писсанецки. Примерно. На пониженной разрядности, но быстро вычисляя скалярные

произведения. Можно и подрезать немного матрицы для удобства.

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

"64-битные ALU для математических вычислений двойной точности" - это уже другое дело :rolleyes:

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

<noindex>http://lenta.ru/news/2009/08/07/nvidia/</noindex> :rolleyes:

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

Такие шансы не каждый день подворачиваются :unsure:

Там наверное система команд типа RISC один такт - одна команда.

Эх "мне бы шашку да коня, да на линию огня" - по хорошему завидую Вам и желаю удачи :rolleyes:

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

Вот нашел для Вас в книге Ansys Механика разрушения - "Все числовые параметры имеют целый или действительный тип и сохраняются

с двойной точностью" c.303

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

Мы опять говорим о разном Федор. Вычисления на ядрах проводятся на 80-битных переменных. А потом сохраняются с нужной точностью.

Я в курсе как работают сопроцессоры и округляют. Вопрос в том, как все происходит на видеокартах.

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

от порядков зависит :unsure: 1+x=1 бывает при малых x

Я к тому, что программисты Ansys пользовались double и без выкрутасов, похоже.

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

Я в курсе как работают сопроцессоры и округляют. Вопрос в том, как все происходит на видеокартах.

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

от порядков зависит :unsure: 1+x=1 бывает при малых x

Я к тому, что программисты Ansys пользовались double и без выкрутасов, похоже.

Скорее всего там реализован собственный тип.

Приходилось решать одну задачу все в типе doublе задача не сходилось :( выяснилось что при разнице между двумя цифрами в 10у-7 программа считала что точность достигнута.

Потом тоже самое прогоняли на SUNe с его двойной точностью и задача решалась.

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

" выяснилось что при разнице между двумя цифрами в 10у-7 программа считала что точность достигнута" - епсилоном при проверке сходимости

можно управлять в настройках, но это не значит, что используется "свой тип " :rolleyes:

Типы они зашиты в железо, даже real (4 b) это только для хранения в памяти, а вычисления все равно double

Знаете ISPA, было бы интересно если бы Вы нашли машинное эпсилон на видеокарте.

Погоняйте в цикле 1+e == 1 условие окончания, и на каждом шаге e/=2; и предпоследнее e и будет хорошей оценкой

Если 1+10**-7 ==1 это одно, если 1+10**-15 ==1 другое.

Подробнее об этом в книжке Форсайта, Моулера вроде можно посмотреть.

"Потом тоже самое прогоняли на SUNe с его двойной точностью и задача решалась" - в Intel тоже сопроцессор всегда был с двойной точностью,

а считает с большим числом разрядов и округляет, о чес справедливо ISPA писал. Это можно в документации на них посмортеть.

Видеокарты работали иначе, поэтому и многие возможности в Open GL, например, оказались урезанными. Сейчас возможно что-то поменялось, вот и интересуюсь :unsure:

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

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

процессора от них. Чтобы быть абсолютно уверенным несложная проверка не помешала бы.

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

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

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

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

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

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

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

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

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

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

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




  • Сообщения

    • lem_on
      ну с дуру известно что сломать можно.
    • Viktor2004
      руку привязки так сломать легко
    • lem_on
      По моему вполне логично если станок вывалится в ошибку если рука не доехала до места. У меня так же если кулачки или деталь на пути, просто пихаеш ее до места и станок опять активен. Но нынешние пановья даже не могут написать модель станка.
    • Viktor2004
      Я согласен что скорее всего проблема механическая Но если логика прописана криво и возможно не предусмотрела остановку в промежуточном состоянии, разве не логично будет попробовать принудительно подав напряжение дернуть эту руку вверх-вниз? Возможно то что туда попало выпадет  
    • Guhl
      Если оставить за скобками вопрото том, что до м19 работает нормально, а после нет, то вы не считали сколько у него реально импульсов на оборот? с помощью стороннего плк, например  А если ориентацию м5 снимать, а не м20?
    • lem_on
      Что это за станок такой в котором сразу ладер ковырять надо, даже не смотря на возможность механической проблемы? Или профдеформация?
    • Viktor2004
      не сразу я понял в чем вопрос. Долго соображал что такое режим управления скоростью. При завершении ориентации PMC снимает сигнал G70.6 ? И если он после снятия сигнала продолжает удерживать шпиндель, при каких условиях эта ориентация все же снимается? После нажатия аварийного грибка или еще как?
    • Viktor2004
      Ладдер пришлите. Будем принудительно пробовать поднимать и опускать
    • streamdown
      Коллеги приветствую! IPS 8. Подскажите пожалуйста, кто какое серверное железо использует? Интересуют параметры при одновременной работе, ну например, 400 пользователей онлайн
    • gudstartup
      так он так и позиционируется по m19 pmc выдает g70.6 а чпу отвечает f45.7 но ориентацию и смещение в 4077 он отрабатывает нормально шпиндель встает ровно и смена происходит хорошо. вопрос почему после ввода команды управления скоростью он все еще продолжает контролировать число импульсов между нуль метками хотя в принципе уже должен отменить позиционный контроль и просто считать обороты по 0 метке как он это делает без М19? это все понятно но почему оно продолжает проверять это после завершения ориентации мне непонятно
×
×
  • Создать...