Двухщелевой эксперимент и квантовая запутанность

[valeriy]

У программы нет ограничения на число щелей, оно может быть задано сколь угодно большим (только тогда придется очень долго ждать окончания расчетов).

Отлично. Я обычно увеличиваю числа кратно двойке = 2, 4, 8, ... ,64, 128 и т.д. Как показали оценки, N=64 вполне достаточно, чтобы, в первом приближении, можно было бы наблюдать эффект Талбота.

[Pipa]

   Выложила версию 1.15, оптимизированную по скорости. Т.е. выжала все, что смогла. Полагаю это предел, если считать по тем формулам, что вы мне когда-то дали.
   Экспоненту считаю сама на ассемблере, как действительную, так и комплексную (вычисление второй требует умения вычислять первую). Вынесла из внутреннего цикла по щелям всё, что возможно.
   Во внутреннем цикле (суммирование по щелям) меняется только x, а остальные параметры постоянны. Благодаря этому упростила цикл до предела:

for( int n = 0; n < N; n++)
{ PSIsumm += exp((x1*x1)*temp2);
   x1 -= d;    // шаги по щелям
}
  
А первоначально было вот что:

PSI(t,x) = sqrt(sqrt(1/(2*pi*sigmaT*sigmaT)))
        *exp(-((x*x)/(4*sigma0*sigmaT))) + i*((pZ/hP)*vZ*t + (EZ/hP)*t))

Чтобы не было сложения с членом  i*((pZ/hP)*vZ*t + (EZ/hP)*t)) внутри подэкспоненциального выражения, представила его в виде произведения двух экспонент, второе из которых вынесла из цикла, как постоянный множитель. Это exp(i*((pZ/hP)*vZ*t + (EZ/hP)*t))).
   В результате достигнуто приличное ускорение: 64 щели считаются за 5 секунд, а за старое время 45 секунд теперь можно сосчитать 512 щелей.

   В ходе упрощений у меня появился к вам вопрос относительно выражения (Pz/h)*Vz*t + (Ez/h)*t. Именно для него мы считаем энергию Ez. Тут сейчас я чуточку изменила обозначения, но не на столько, чтобы стало совсем непохоже.
   Сначала возьмусь за первое слагаемое (Pz/h)*Vz*t. Заменяю в нем t = z/Vz, сокращаю Vz и получаю (Pz/h)*z. Теперь подставляю вместо Pz его выражение через лямбду Pz = h*2*п/λ и после сокращения на h имею:
2*(п/λ)*z
   Теперь займусь упрощением второго слагаемого (Ez/h)*t, хотя оно и так кажется предельно простым. Для этого я подставляю в него значение энергии Ez = Pz*Pz/(2*m) и времени t = z/Vz. В последнем выражении Vz = Pz/m. После подстановки и сокращения подобных получаю, что (Ez/h)*t тождественно равно выражению:
(Pz/2h)*z
а если в нем заменить Pz на Pz = h*2*π/λ, то 2h сократится и по получится:
(π/λ)*z
  Сравнивая новые выражения первого и второго слагаемых замечаем, что первое из них ровно вдвое больше второго! А их сумма равна
3*(π/λ)*z
причем ни энергии, ни скорости для этого считать не надо.
   Как вы прокомментируете этот результат? Или я здесь где-то ошиблась?

[valeriy]

Выложила версию 1.15, оптимизированную по скорости. Т.е. выжала все, что смогла.

Спасибо Пипа, я посмотрю как она считает.

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

Нет, не ошиблась.  
Пользуясь известными де Бройлевской и Эйнштейновской формулами λ=h/p и E=h*f (здесь p и f есть импульс и линейная частота, 2πf=ω), можно многие выражения значительно упростить. Именно это ты и сделала.
В частности, то же самое можно проделать и в формуле для
sigmaT=(1+i ℏt/(2mσ²), если вместо t подставить z/V_z и заметить, что mV_z является компонентой импульса p_z= ℏ*2*п/λ. В результате получаем
sigmaT=(1+izλ/(4пσ²)).

Посмотрел как считает версия 1.15. Превосходно. Для случая N=512 она считала даже быстрее, чем старая верися для N=64. При этом выдает ясный Талбот паттерн с хорошо очерченными белыми полосами и ромбовидными лакунами. Спасибо Пипа, хорошая версия.

[Pipa]

   Меня сейчас вот что больше всего беспокоит.
   Преобразования, которые я сделала для ускорения счета, на видимую картину распределения вероятностей (ковер Талбота) не повлияли. По крайней мере файлы картинок, полученные до и после оптимизации, полностью совпали друг с другом при побайтном сравнении. Однако проведение бомовских траекторий настолько чувствительно к порядку вычислений, что я побоялась трогать эту часть, оставив ее неоптимизированной.
   Дело вовсе не в том, что эта часть программы нуждается в оптимизации - по сравнению с построением всего ковра, эта работа гораздо меньшая, и потому временные задержки здесь вполне терпимые. Меня крайне беспокоит другое - сверхчувствительность траекторий ко всякой мелочевке. Ведь это означает, что задача, которую я решаю, крайне плохо определена. А в этом случае становится невозможным определить, как пролегают траектории.
    Приведу наглядный пример для того, чтобы вы разделили вместе со мной мою озабоченность. Возьмем для примера хотя бы то выражение, о котором шла речь в моем прошлом сообщении:
i*((pZ/hP)*vZ*t + (EZ/hP)*t))
Не то, чтобы именно оно здесь больше всего было виновато, а исключительно для примера, т.к. со всеми остальными выражениями дела, порой, обстоят еще хуже.
    Взгляните на это выражение и скажите, можно ли здесь вынести общий множитель hP (постоянную Планка) за скобки, чтобы сократить в вычислениях одну операцию деления? Вот так:
i*((pZ*vZ*t + EZ*t)/hP)
 Скажите, что можно? А вот поглядите, что из этого получается с траекториями:





Верхний рисунок соответствует варианту, когда на постоянную Планка делят каждое слагаемое, а нижний рисунок - варианту, когда постоянную Планка вынесли за скобки и делят на нее сумму.
   Обратите пристальное внимание на участок, обведенный в рамочку, и ... найдите 10 отличий . Видите, как далеко от старта сказалась эта разница?
   А если проверить величину разности между величинами, вычисленными по первой и второй формулам, то окажется, что единственная разница между ними обнаруживается лишь в одной единственной точке на бомовской траектории! На одной из траекторий в единственной точке имеет место расхождение на -9.095e-13, а на другой траектории и тоже в единственной точке 2.274e-13. И это при весе последнего знака в 2.2204e-16 (вычисления проводятся в разрядной сетке double precision). Такие потери часто бывают при вычитании друг из друга двух чисел разного порядка.
   Т.е. вот такое ничтожное расхождение в одной единственной точке может приводить к тому, что вся дальнейшая траектория оказывается другой. Ведь мы проводим эти траектории по шагам, и один единственный шаг в сторону способен привести к непредсказуемым последствиям, поскольку мы не координату вычисляем, а приращение к координате предыдущего шага. И хорошо еще, если потом пути сходятся (как на приведенных мною рисунках), но я видела и такие, когда от подобной замены трактория скатывалась в соседнюю колею.
   С постоянной Планка это еще ерунда, хуже когда приходится делить на комплексное число. Тут в знаменателе появляются квадраты, которые съедают точность мантиссы.
    В принципе упрощение формул (в смысле уменьшения числа операций) благоприятствует повышению точности вычисления результатов, однако от этого возникнет расхождение между старыми картинками траекторий и новыми. И, полагаю, что вам может не понравиться их изменение в каждой новой версии программы. Поэтому я сохранила самый старый вариант расчета траекторий, но не потому что он самый точный или лучший, а только потому, что мы нему привыкли.

[Pipa]

P.S. Забыла сообщить, что только что выложенная мной версия 1.16 способна (по заказу!) рисовать траектории еще двумя цветами - желтым (yellow) и циановым (cyan). Тот цвет, которым они проводятся по умолчанию, называется лиловым (magenta). Чтобы изменить цвет траектории надо в файле interference.dat справа от точки старта поставить букву Y для желтого или С для цианового. Цвета различаются по первой букве, не обращая внимания на регистр. Например так:

-0.495 Magenta
-0.499 Cyan
-0.503 Yellow
-0.506 M
-0.510 C
-0.520 Y
-0.540 m
-0.600 c

Все это различные способы задания той же самой тройки цветов. Однако, еще раз повторяю, задавать цвет magenta нет необходимости - при отсутствии задания цвета или наличия чужой буквы в строке цвет останется magenta.
   Эта тройка цветов не самая удачная (желтый плоховато различим), но у меня нет выбора. Дело тут еще в том, что эти три цвета MCY порождают троицу, подобную RGB, поскольку являются к ней дополнительными. Благодаря этому они способны при смешении порождать все остальные цвета. Это очень полезно, когда траектории накладываются друг на друга. В этих случаях образуется смешанный цвет, но не закрашивание одного цвета другим. Такая особенность может оказаться полезной при разборке сложных случаев.  
  

[valeriy]

Меня сейчас вот что больше всего беспокоит.

Я полностью разделяю твое мнение. Артефакты, на которые ты указываешь, тем сильнее себя будут проявлять, чем более выраженную фрактальность будет демонстрировать Талбот паттерн. То есть, чем больше отношение d к λ задается. На Талбот паттерне самыми критическими областями являются темные узлы, на которые сходятся траектории, чтобы затем разбежаться. Чем сильнее на этих узлах происходит фокусировка, тем больше погрешностей будет выдавать программа. И это из-за того, что числа с плавающей запятой имеют конечную точность (наибольшую точность могут дать  double-precision variables. Но и они имею предел) К сожалению, с этим приходится мириться и ограничиваться только Талбот паттернами, у которых эти темные узлы не настолько сильно фокусируют входящие траектории, или брать бОльшую разрядку между ближайшими траекториями.

Разумеется, здесь еще существуют хитрости программирования, о которых ты упомянула (складывать и вычитать числа, порядки которых соизмеримы и десятичные числа группируются вблизи десятичной точки). Ты хорошо сделала, что ввела разный цвет для ближайших траекторий. Сразу видны артефакты - пересечения траекторий. При этом я вижу такие пересечения как на верхнем рисунке, так и на нижнем. Соглашусь, что построение на компьютере требует учета подобных заморочек, даже если это и идет в ущерб расчетного времени.

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

PS: Спасибо за новую версию. Обязательно посмотрю ее возможности.

[valeriy]

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

Это твое образное сравнение очень хорошо подчеркивает те трудности, с которыми приходится сталкиваться при изучении Талбот эффекта. Тоже самое как в задачах гидродинамики. Одно дело расчитывать машинными средствами ламинарные потоки. И совершенно иная ситуация возникает, когда предстоит расчитывать турбулентные потоки. В последнем случае также возникает проблема следить за тем, чтобы ближайшие потоки не пересекались, в какой бы водоворот они при этом не закручивались.

[valeriy]

Забыла сообщить, что только что выложенная мной версия 1.16 способна (по заказу!) рисовать траектории еще двумя цветами - желтым (yellow) и циановым (cyan).

Спасибо Пипа, посмотрел - хорошо рисует. Это очень уместно, поскольку при объяснениях можно обращаться к траекториям с разными цветами.

[Pipa]

На Талбот паттерне самыми критическими областями являются темные узлы, на которые сходятся траектории, чтобы затем разбежаться. Чем сильнее на этих узлах происходит фокусировка, тем больше погрешностей будет выдавать программа. И это из-за того, что числа с плавающей запятой имеют конечную точность (наибольшую точность могут дать double-precision variables. Но и они имею предел) К сожалению, с этим приходится мириться и ограничиваться только Талбот паттернами, у которых эти темные узлы не настолько сильно фокусируют входящие траектории, или брать бОльшую разрядку между ближайшими траекториями.

Разумеется, здесь еще существуют хитрости программирования, о которых ты упомянула (складывать и вычитать числа, порядки которых соизмеримы и десятичные числа группируются вблизи десятичной точки).
...
 Соглашусь, что построение на компьютере требует учета подобных заморочек, даже если это и идет в ущерб расчетного времени.

   Не вполне разделяю ваше мнение о том, что артефакты порождаются погрешностями вычислений. Мое мнение (и я его прошлый раз высказала) состоит в том, что траектории и в самом деле способны к расщеплению в особых точках. А погрешности вычислений дают лишь ничтожное преимущество одному из равнозначных вариантов ветвления.
   Ваше мнение о том, что траектории в узлах только лишь собираются в плотный жгут, который в последствии расплетается, кажется мне очень сомнительным и бездоказательным.
   Мое же мнение вытекает уже из поведения светлых (малонаселенных) полос, которые в лагунах ПЕРЕСЕКАЮТСЯ, но не отражаются зеркально от горизонтали. Т.е. ведут себя как оптические линзы по отношению к проходящему через них свету. Конечно это вопрос интерпретации. И если вы упорно хотите в этом месте видеть «угол падения равен углу отражения», то это исключительно ваш субъективный поход. Пока четкого доказательства тому, что бомовские траектории не могут между собой пересекаться, вы не дали. Для сравнения скажу, что если бы в окрестности щели действительно было бы расхождение лучей, то ничего бы не мешало пересечься лучам, исходящим из разных щелей.
   К этому вопросу мы еще вернемся, а сейчас, с вашего позволения, поговорим про точность вычислений и что с ней еще можно сделать.
   Прежде всего замечу, что double precision это не предельная точность расчетов на персональных компьютерах. Используемые в них процессоры как от Intel, так и от AMD, аппаратно поддерживают еще большую точность – long double precision. Правда эта возможность нынче «не кошерная», т.к. лет 5 тому было заключено соглашение крупных разработчиков программного обеспечения, чтобы этот тип данных не поддерживать. С тех пор Microsoft изъяла этот тип данных из своих компиляторов. Нет их и в пакетах MatLab и Matematica. Но кое-где такие возможности остались. Например, в моем компиляторе от Borland, ну и, конечно, на C-компиляторе от самого Intel, который уж никак не мог полностью забыть ту опцию, которую сам же впаял в свои процессоры. Правда о существовании последнего компилятора мало кто знает, но тем не менее.
    Несмотря на свое название long double precision, она не дотягивает даже до тройной точности. Для сравнения напомню, что тип float precision (одинарная точность) считает в разрядной сетке размером 4 байта (6 десятичных разрядов мантиссы), double precision (двойная точность) в сетке размером 8 байт (15 десятичных разрядов мантиссы) и long double precision в сетке 10 байт (18 десятичных разрядов мантиссы). И пусть не вдвое, но лишние 3 десятичных разряда – уже хлеб.

   Короче говоря, я врубила эту повышенную точность в процессе расчета шагов бомовской траектории (при вычислении тангенциальной скорости Vx). Напомню, что эта скорость считается суммированием вкладов от всех щелей и вычисляется алгоритмом:

PSIsumm = 0
nablaPSIsumm = 0
Цикл по всем щелям в фигурных скобках
{ x = расстояние до щели
   PSI = temp1 * exp((x*x)/temp2 + temp3)
   PSIsumm = PSIsumm + PSI
   nablaPSIsumm = nablaPSIsumm + PSI * (x/2) / temp2
}
Vx = (h/m) * Мнимая_часть_от(nablaPSIsumm / PSIsumm)

здесь:
PSI – вычисляемое значение пси-функции
PSIsumm и nablaPSIsumm – суммы накапливающие PSI и nablaPSI.
temp1, temp, temp2 – какие-то комплексные числа, вычисляемые вне цикла.

Итак, самым напрашивающимся шагом для повышения точности вычислений явился перевод всех переменных, участвующих в алгоритме, в более длинную разрядную сетку long double precision. Посмотрим, что из этого получилось!





Вверху вновь повторенная картинка того, что выдает версия 1.16, расчитывающая траектории в лоб (т.е. PSI считается по выданным вами формулам), а внизу то, что получается при переходе к long double precision.
   Видите пересечение циановых траекторий? Ах, у вас остались сомнения относительно того, пересечение ли это? Может быть это нижняя циановая линия от горизонтали отразилась? А мы это сейчас проверим! Для этой цели я ввела еще 3 цвета: red, green и blue. В отличие от цветов magena, cyan и yellow, они дают при  смешении черный цвет, но для нашей цели это сгодится. Смотрим с другим окрасом:



Видите, что творится? Синяя пересекла magenta, впрочем как и cyan и yellow!

Что же дальше? Предел точности исчерпан или еще нет? Оказывается, еще нет.
Взглянем на выражение для пси-функции
PSI = temp1 * exp((x*x)/temp2 + temp3)
и заметим, что довольно громоздкий множитель перед экспонентой, предварительно вычисленный и помещенный в tеmp1, ... нам совершенно не нужен! Не нужен потому, что он одинаково вхож как в сумму пси-функций PSIsumm, так и в сумму набл nablaPSIsumm. Означает ли это, что его можно вынести за пределы цикла, как постоянный множитель? Означает. Но означает и гораздо большее – на него вообще не надо множить (!), поскольку скорость Vx определяет отношение nablaPSIsumm / PSIsumm. Так зачем же терять точность, умножая на то, что в результате полностью сократится? Значит и умножение на этот множитель для наших целей можно опустить и сам этот множитель не вычислять. Смотрим, что получилось в результате удаления temp1:



- в принципе то же самое, хотя мелкие отклонения найти можно.

Что дальше? Смотрим, что у нас осталось от пси-функции после удаления сомножителя temp1:
PSI = exp((x*x)/temp2 + temp3)
и замечаем, что сумма в показателе степени позволяет нам представить это выражение, как произведение экспонент:
PSI = exp((x*x)/temp2) * exp(temp3)
А поскольку множитель exp(temp3) внутри цикла постоянный, то его можно удалить из выражения по тем же причинам, по которым был удален temp1. Другими словами  сложение с temp3 можно не производить, т.к. на отношение nablaPSIsumm / PSIsumm это влияния не окажет!
   Это место замечательно еще и тем, что удаленный temp3 как раз является тем выражением, ошибка в младшем знаке которого возникала при вынесении постоянной Планка за скобку! Т.е.
temp3 = i*((pZ/hP)*vZ*t + (EZ/hP)*t))
Таким образом оказывается, что повышение точности вычислений достигается не посредством более точного исчисления этого выражения, а в том, что мы вообще отказываемся его считать! Точность от этого, несомненно, повышается, но картинка получается не очень удачной, т.к. синий цвет получается еще и от наложения разных цветов на магистральной прямой:



Тут уже, вслед за синей, по близкой к ней траектории пошла еще cyan и одна из magenta (я уж не разбиралась, которая из двух, но полагаю, что верхняя).
Короче, берите версию 1.17 и смотрите сами. Она – результат последнего упрощения, выдающая последний рисунок.
Цвета задаются в файле interference.dat, кодировка цветов такая:
M – magenta (лиловый)
C – cyan (циановый)
Y – yellow (желтый)
R – red (красный)
G – green (зеленый)
B – blue (синий)
X – black (черный)
А из пожеланий у меня просьба привести действительную и мнимую части выражения 1/sigmaT (sigma0 из него можно вынести). В настоящее время вся оставшаяся неточность сосредоточилась в погрешности вычисления этой обратной величины. Было бы замечательно, если бы мы могли бы порекомендовать мне подходящую для расчета формулу, поскольку при делении на комплексное число пропадает вся точность из-за наличия квадратов в знаменателе.

[valeriy]

Видите пересечение циановых траекторий? Ах, у вас остались сомнения относительно того, пересечение ли это? Может быть это нижняя циановая линия от горизонтали отразилась? А мы это сейчас проверим!

...

Видите, что творится? Синяя пересекла magenta, впрочем как и cyan и yellow!

Слишком экстравагантный результат, невольно хочется воскликнуть - "Этого не может быть, потому что этого не может быть никогда!"
Из классической механики, которая давно работает с уравнениями Гамильтона-Якоби, и в которой построение геодезических траекторий является обычным делом, известно, что геодезические траектории нигде никогда не пересекаются. Окрась разными чернилами струйки воды, текущих по какому-либо желобу, и понаблюдай могут-ли они пройти насквозб друг друга. Я не призываю тебя проделать подобный опыт, но интуитивно ясно, что струйки воды не будут персекать друг друга; они могут слиться и дать смешанный цвет струи, но и только.

Впрочем, здесь мы имеем дело с квантовыми потоками - с уравнениями Гамильтона-Якоби, в которых замешен квантовый потенциал. И было бы опрометчиво говорить фразы, подобную той, которую я привел в самом начале. Надо думать. Для меня твой результат слишком экстравагантен. Да, я вижу - очень даже хорошо показано, как на определенном этапе синяя траектория начинает пересекать фиолетовую и голубую. Думаю надо постепенно ослабевать отношение d к λ и проследить, когда кривые перестанут пересекаться. Прежде всего придется выяснить , не является ли артефактом этот результат. Ну а я постараюсь привести действительную и мнимую части выражения 1/sigmaT.

PS: что-то я не обнаружил в твоем постинге ссылку на версию 1.17, дано только ее упоминание.

[Pipa]

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

   Я уже предупреждала вас (#414), что не стану каждый раз приводить ссылку на то место, где лежит программа. Поскольку это место всегда одно и тоже, а стало быть и ссылка одна и та же. Версии меняются, но называние у файла неизменно.
   Найдите в теме одну из старых ссылок и поместите ее себе в фавориты.

[valeriy]

Я уже предупреждала вас (#414)

Понял, достану

[valeriy]

Проверил работу версии 1.17.
Проверил Талбот паттерны для отношений d/λ=10, d/λ=20, d/λ=40.

Для первых двух отношений я не обнаружил пересечений каких-либо траекторий.
Для последнего отношения пересечение траекторий обнаружено. Все было сделано для N=512.
Паттерны, показывающие поведение траекторий для выше перечисленных режимов, я пришлю тебе на твой е-мэйл вместе с формулами, относящимися к преобразованию члена sigmaT.

А здесь привоже данные файлов interference.ini и interference.dat, относящихся к последенму случаю

interference.ini :

[PARAMETERS]       
slits=512         
mass=1.674927E-27 
lambda=5E-9       
d=20E-8           
slite width=3.33E-9
sigma0=8E-10       
[AXIS]             
X-scale=1:4        <== для d/λ=20, X-scale=1:2  <== для d/λ=10, X-scale=1:1
Z-scale=1:16      <==                  Z-scale=1:4  <==                  Z-scale=1:2
P-scale=1:1       
[2D]               
nx=768             
nz=1024           
nxb=384           
dxb=1             

interference.dat :

-0.493 X       }
-0.495 M      }
-0.499 C      }
-0.503 Y      }
-0.506 R <-I }
-0.510 G <-I }
-0.520 B }   
-0.540 X }   

Здесь символами <-I отмечены те данные, которые приводят к пересечению траекторий.
Затем все они сливаются вместе.
Последние два значения приводят к слиянию траекторий на ранних этапах.

Во-первых, хотелось бы знать те начальные данные, с которыми оперировала ты.
Во-вторых, почему траектории обнаруживают пересечения при d/λ=40, а при меньших значениях подобных пересечений не обнаружено. Или они могут быть, но при выборе других значений начальных условий?

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

[Pipa]

Во-первых, хотелось бы знать те начальные данные, с которыми оперировала ты.

interference.ini :

[PARAMETERS]
slits=64
mass=1.674927E-27
lambda=5E-9
d=2E-7
slite width=1E-8
sigma0=8E-10
[AXIS]
X-scale=1:4
Z-scale=1:20
P-scale=1:1
[2D]
nx=768
nz=1024
nxb=384
dxb=0.5

interference.dat :

-0.495 M
-0.499 C
-0.503 Y
-0.506 M
-0.510 B
-0.520 Y
-0.540 M
-0.600 C

[valeriy]

Спасибо за данные. Только что выслал на твой е-мэйл файл interference512.doc