вопрос по sparse solver

[Цветочек 15]

Неужели вдруг от скорости мы перешли к вполне разумной мысли о том, что матрицы мкэ иногда не особо хорошо обусловлены? Что-то мне подсказывает, что итерационные методы решения плохи для таких систем в принципе, и матрица L тут не шибко поможет, может просто нужон быстрый прямой решатель? И раз медленно приходим к мысли, что в дальнейшем уже трудно придумать что-то новенькое для ускорения решения слау, может попробовать немного изменить кэ формулировку, так сказать подогнать под конкретный решатель, оптимизировать интерфейс между составлением матрицы жесткости, её решением и внесением изменений на следующем шаге?

[Цветочек 15]

Ну и ладно, а то я прочла пост выше, про итерационные методы и расстроилась

Быстрый прямой факторизатор есть быстрый прямой решатель, ибо преобладающее время при решении тратится именно на факторизацию

[Цветочек 15]

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

[Цветочек 15]

Нет, я в общем-то всё поняла, как это ни странно и удалилась

[Борман 2 375]

suvorov.as

из Нижнего чтоли ?

[Цветочек 15]

Я просто удалилась, ибо всё поняла - прочуствовала на себе - 5000 прогонок за 40 минут и 1 факторизацию за 5 минут

[Борман 2 375]

ИПФ РАН. А кто еще из Нижнего?

Я. И я не пользоваель ИСПА, если что...

ИПФ РАН - это круто.

[Цветочек 15]

Нет никакого сарказма

Борман: Как не повезло тем, кто просто работает в АО, ООО, ЧП или в вузе. Давай не забывать, что не именитое заведение работы делает из нас людей, а мы делаем престиж своей работе, тем что там качественно работаем

[Борман 2 375]

Как не повезло тем, кто просто работает в АО, ООО, ЧП или в вузе. Давай не забывать, что не именитое заведение работы делает из нас людей, а мы делаем престиж своей работе, тем что там качественно работаем

Не понимаю как влияет форма собственности предприятия на качество работы.

[Цветочек 15]

Форма собственности предприятия на качество работы никак не влияет.

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

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

[Борман 2 375]

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

Это до определенного возраста (степени неразумности).

[Цветочек 15]

Но я как обычно не хотела никого обидеть. я просто высказала свою мысль об разных работах - вот я, так считаю и всё. Возможно, здесь проявляется стервозность, но надеюсь что это не так

[a_schelyaev 366]

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

Размерность у нас разная.

Кроме того, мы не делаем полную факторизацию, а перекладываем нагрузку на итерационную схему.

За счет этого выигрываем во времени.

И он просто не способен решать задачи прочности.

В текущем виде? Наверное.

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

Так что не в том разделе рекламку разместили.

А никто рекламку и не вешал.

[vl 327]

А LU ихний быстр однако. Можно попробовать его под свои цели применить, только это опять не самый оптимальный вариант.

Почему он хуже конденсации матриц?

Один раз сделали факторизацию и дальше только обратный ход для всех своих векторов В.

[Дмитрий Фролов 0]

я просто оставлю это здесь...

<noindex>урановые ломы</noindex>

[a_schelyaev 366]

Так вы так ничего не и не поняли.

Это ИСПА опять ничего не понял. Сравнение итерационных и прямых методов не делал только ленивый у нас в стране. В том же Абрау-Дюрсо сколько копий было сломано на эту тему. Прямые методы пригодны только до определенной размерности. Точка. Медицинский факт.

Эта схема быстрее работает только на старых процессорах. Это было 3-5 лет назад.

Это вообще кто говорит? Человек, который еще несколько страниц назад писал, что цифры из Ансиса это бред?

:)

В ИСПЕ, наверное да. В FlowVision нет.

А на современных процессорах быстрее работают прямые схемы решения. Количество операций с плавающей точкой прямой метод требует больше, а времени МЕНЬШЕ.

На какой размерности?

15 млн гекса элементов, 90 млн степеней свободы по вашим понятиям.

А вам слабо? То что у ваших клиентов такие задачи не решаются мне по барабану - меня волнуют мои клиенты.

Ваши разработчики только зря потратили время. Но это понимают только те кто знает как на игровом процессоре (4 ядра) добиться скорости 118 Гфл. Цена этого процессора 10 тыс руб.

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

:)

Разработчики ИСПА это знают. И такой прямой решатель уже работает в новой версии ИСПА.

Да и пускай работает. Кто-то запрещает?

[Практик_Прочнист 0]

Это вообще кто говорит? Человек, который еще несколько страниц назад писал, что цифры из Ансиса это бред?

:)

Дайте ссылку. Где ИСПА такое писал?

[soklakov 1 475]

Это ИСПА опять ничего не понял. Сравнение итерационных и прямых методов не делал только ленивый у нас в стране. В том же Абрау-Дюрсо сколько копий было сломано на эту тему. Прямые методы пригодны только до определенной размерности. Точка. Медицинский факт.

О, Боги! Неужели это правда?! Я поддержу ИСПУ.

Действительно, только до определенной размерности. И размерность эта, в первую очередь, определяется железом, в частности - объемом оперативной памяти. И эти возможности растут с такой скоростью, что прямые решатели уже если не решают, то скоро решат и 100кк DOF.

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

[Цветочек 15]

Лет 30 назад тоже комплексовали, ибо не было возможности использовать тип double. Это всё возникло из-за того, что при решении плохо обусловленных слау прямыми методами, пытались несколько улучшить решение итерационно. Так вот оказалось, что можно использовать single по нашему на итерационном этапе и это не сильно меняет результат, как если бы использовали double, например.

[a_schelyaev 366]

И эти возможности растут с такой скоростью, что прямые решатели уже если не решают, то скоро решат и 100кк DOF.

Вот как раз тусуюсь на ПАВТе в Новосибирске и тут вещают про экзафлопные системы к 18му году, пожирающие в идеале 20 МВт.

:)

Есть только одно НО - насколько эффективно такие алгоритмы работают на системах с распределенной памятью по сравнению с итерационными алгоритмами?

Дело не только в размерности, но и в обусловленности матрицы.

Вот именно по этой причине заказчики за нашу итерационную решалку и зацепились.