Pull to refresh
20
0
Цыбулин Иван @Uranix

User

Send message

Поэтому ничто не помешает записать

кроме математики и здравого смысла

У вас a = b с точностью до 10^-16. Это значит, что a - b имеет 16 нулей. А теперь посчитайте сколько членов в выражении a - b

Когда-то давно подобным образом пытался находить аналитические выражения для интегралов, взятых численно. А потом понял простой факт - любое число с N знаками после запятой может быть аппроксимировано какой-то формулой с ~N членами/цифрами. Поэтому такие длинные крокодилы не несут совершенно никакой ценности

Использовать spsolve для трехдиагональной матрицы - это из пушки по воробьям. Трехдиагональные системы решают прогонкой, в питоне для этого есть solve_banded.

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

И все равно делая Scatter / Gather на нулевой процесс каждый шаг, хорошего распараллеливания не получить

На самом деле и прогонку можно распараллелить с помощью MPI. Просто это делается не тривиально.

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

Другая гипотеза - что яблоко представляет собой по большей части воду, из-за чего нагреть его выше 100С становится проблематично вплоть до состояния, когда большая часть воды испарится / свяжется с чем-то. А тесту такой температуры недостаточно для застывания, вот тесто вблизи яблок не пропекается.

Но возможно тут существенен еще переход теста из жидкого состояния в твердое с изменением физических характеристик, тогда это уже ближе к задаче Стефана.

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

А вы сравнивали, какое ускорение дает MPI версия? Я не вчитывался в код, но кажется что объем обменов и вычислений одного порядка, не понятно, почему вы пишете что задача CPU bound. Использование Scatter / Gather в вашем случае скорее всего убивает всю производительность.

Пример для 3D не удачный - ППП не применяют для 3D, так как она теряет свойство безусловной устойчивости.

Уравнение теплопроводности с переменным коэффициентом записывается как

u_t = \mathrm{div}\, (\lambda \nabla u)

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

Квадратичная зависимость силы сопротивления от скорости - это только при больших скоростях. А при малых работает формула Стокса с линейным законом. Чтобы понять какой у вас случай реализуется, надо прикинуть число Рейнольдса

UPD. Прикинул, кажется что линейный режим там в лучшем случае при v \ll 1 \text{ м/с}реализуется

Сделал в инерциальной системе отсчета
https://gist.github.com/uranix/b101ca6ce8dcc2b616502dd8e9a2f9e9

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

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

https://gist.github.com/uranix/7c137c2c3a0fb22579f54d96721e69be

Думаю, что ошибка в update - вы сначала обновляете omega, а затем этой обновленной omega доворачиваете углы поворота. Правильно же применять метод интегрирования к совместной системе для углов и скоростей

Значение вектора состояния обычно отображается не на сфере Блоха

Зачем он тогда полюса на сфере подписал как |0> и |1>?

Рассматривать нечетные N, затем четные вида N = 2^k (2m-1), k,m > 1. Заметить, что t и t+2j+1 разной четности, поэтому одно из них делится на 2^k, а второе — на 2m-1.

Любопытно, конечно, каким способом сделал ее Хейвенс, что "[Гордон] был впечатлён изобретательностью Хейвенса, его поразил способ, который Хейвенс применил для получения правильного ответа".
CPU код для моделирования нагрева пластины, в котором используется FEniCS, не имеет практически ничего общего с кодом, использующим Cython+CUDA.
Первый решает задачу теплопроводности конечными элементами на треугольной сетке неявным методом. Второй же решает уравнение Лапласа (то есть ищет стационарное распределение температуры) конечными разностями на прямоугольной сетке итерационным методом Якоби. По сути, первый вариант на каждом шаге решает задачу, эквивалентную той, которую решает второй вариант.
Конечно, в таких условиях выигрыш будет на стороне GPU. Я не сомневаюсь, что эту задачу можно на GPU решить гораздо быстрее, но давайте делать честные сравнения!
Первое слагаемое не дает лапласиан, там получается выражение image. Если не убедил, проверьте u = x^2 - y^2. Эта функция удовлетворяет уравнению Лапласа, но не уравнению минимальной поверхности.

Пожалуйста, объясните, что именно кэшируется в задаче 6, и как это на результат работы влияет?

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

А при каком числе гармоник решения вам перестает хватать стандартной двойной точности для метода Ньютона? В свое время при решении полиномиальных систем уравнений приходилось привлекать четверную и восьмерную точность для систем из ~30 уравнений, у вас же несравнимо больше. Или вы все же производите вычисления в длинной арифметике?
А можно источник, где написано, что система Лоренца жесткая? Неустойчивая — да, а вот жесткая?
А еще я бы в с++ коде попробовал бы использовать Point4D вместо Point3D. В этом случае, мне кажется, выравнивание может еще ускорить код. Насколько я знаю, стандартные библиотеки для работы с матрицами стараются выравнивать строки.

Information

Rating
Does not participate
Location
Долгопрудный, Москва и Московская обл., Россия
Date of birth
Registered
Activity