Закрываем счёт в произвольном отделении Сбербанка

Как человек, расставшийся со сберкнижкой лет 6 назад, я даже не думал, что и карточку можно закрывать исключительно в родном отделении Сбербанка. Потому я месяц назад пришёл в первое попавшееся отделение в Москве, взял талон и стал ждать очереди.

Через минут сорок ожидания в зале мне сказали, что моя карточка открыта на м. Кунцевская (её открывала мне РАН, и я знать не знал, в каком отделении), и ехать мне надо туда.

Ошибки численных приближений

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

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

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

Случай первый. От перемены мест слагаемых сумма меняется.

Дано:

Есть массив oxmass_sum, каждый элемент которого определяется по формуле, приведённой на картинке: oxmass_sum(i) = oxmass_sum(i) + tmass*foxide(i) - mass_oxide_new(i).

Источник проблемы и к чему это приводит:

Значения массива oxmass_sum(:) могут быть порядка единицы и её десятых долей. С другой стороны, количество знаков tmass*foxide(i) превышает точность вычислений. Поэтому при вычислении при прибавлении к oxmass_sum(i) величины tmass*foxide(i) и выполнении дальнейших операций величина отбрасывается.

Решение:

Переставить oxmass_sum(i) в конец суммы:

oxmass_sum(i) = tmass*foxide(i) - mass_oxide_new(i) + oxmass_sum(i)

Комментарий:

Об этом меня предупреждали книжки 60-х годов. Однако их рекомендация была в суммах упорядочивать числа по возрастанию - и в данном случае она таки не срабатывает. Складывать надо после приведения к единому порядку величины.
Подход к пределу точности явно следует из спецификации типа данных REAL*8.

PS: да, я глупый, порядок столбцов в третьей таблице
tmass, foxide(:), mass_oxide_new(:), oxmass_sum(:)_old, oxmass_sum(:)_new

Случай второй. Разница в адцатом знаке.

Дано:

Есть массив oxmass_sum, каждый элемент которого определяется по формуле, приведённой на картинке: oxmass_sum(i) = tmass*foxide(i) - mass_oxide_new(i) + oxmass_sum(i).

Источник проблемы: 

Для расчёта массива mass_oxide_new(i) есть два массива cox(:) и cc(:), причём cc(:) - это изначальные значения, а cox(:) - те же, но полученные из другого источника (при этом они должны быть равны, т.к. считаются из одних и тех же констант, только по разным формулам). Как можно увидеть в строке вывода, представление чисел несколько отличается - хотя с точностью до энного знака числа полностью идентичны.

К чему это приводит:

При перемножении этих одних и тех же с машинной точностью (VARIANT 1) на скриншоте на константу tmass полученное третье значение массива cox отличается на 0.5 от cc(3)*tmass и foxide(3)*tmass. Как результат, массив с разностями получается ненулевой. 

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

Решение:

Физически приравнивать числа, если их разность меньше определённого предела. Массив получается нулевой.

Комментарий:

В принципе, просто иной поворот старого правила, что сравнивать два числа с плавающей точкой (if a == b then ...) некорректно и неправильно. Однако здесь домножение на Очень Большое Число tmass привело к тому, что исчезающая разность стала вполне расчётной величиной.

PS: а меня шеф похвалил! "It's great that you are finding some subtle bugs." уруру

Нюансы закупок оборудования в МГУ

В 2010 году я сверхурочно проработал полгода на родное МГУ им. М.В. Ломоносова, создавая и поддерживая информационные ресурсы (сайтики) о нём. В конце этого полугода вместо оговорённой зарплаты получил шиш.

Руководитель работ сказал мне "так и так, нам денег не дали". На мой резонный вопрос "а что мне тогда кушать?" он ответил "ну мне что, из своих денег тебе выплачивать работу на общеМГУшные проекты? Почему моя семья должна оплачивать тебе провалы руководства МГУ?".
По понятным причинам политического характера я не стал тогда высказывать своего убеждения, что непосредственный руководитель при найме работника таки должен отвечать своим кошельком перед ним. Вне зависимости от того, кто его самого и когда кинул. Иначе почему работник должен отвечать за отсутствие денег у субподрядчика?

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

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

Понятно, требовать себе кусок спектроскопа - крайне глупо, равно как и думать, что МГУ и его представители научатся платить по счетам. Но, мне кажется, латунная табличка с именами в чёрной рамке и надписью "прибор куплен на личные средства тех-то и по такой-то программе" на двери лаборатории была бы крайне уместна. Как дань уважения к (экс-) коллегам.

В общем, показательное дополнение к замечательному финалу другой работы на отечественную науку.

PS на основе заданных вопросов: создание и поддержка информационных ресурсов о МГУ никак не связано ни с учебной, ни с научной деятельностью юного падавана-геолога. Да и на тот момент я вообще не учился в МГУ, являясь исключительно работником по найму.

Компилирование кода с использованием HDF5

HDF5 - формат хранения больших объёмов структурированных данных, предназначенный для различных научных и научно-прикладных приложений. В частности, он позволяет хранить информацию об эволюции значений каких-либо переменных в 3D объекте с течением времени. Большой его плюс - это поставка в виде готового набора библиотек, которые могут использоваться либо как dll, либо как компилируемые исходники при разработке своих приложений, что снимает головную боль по записи данных.

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

Наша группа перешла на него в этом году.

Библиотека HDF5, будучи предназначенной для паралелльной записи в один файл вывода, нуждается в параллельном компиляторе под MPI. Пост про то, как это завести на openSUSE и на MacOS.

Примечание для пишущих на C++. HDF5 не поддерживает параллельную версию для C++, есть только для C и fortran. Насколько я понял, с остальными языками всё ещё хуже.

Текущий релиз, если что, от июня 2015 года.

За прошедший месяц прилетели какие-то чудесные обновления, благодаря которым наш код перестал компилироваться как на рабочем компе с MacOS, так и на моём ноутбуке под openSUSE.

Я понимаю, что это звучит как "вот я ничего не трогал, а оно само упало", но разбираться в причинах у меня нет времени и желания. Потому вместо разбора полётов я приведу инструкцию по решению проблемы.

Решаемая задача: компилирование параллельного кода на Fortran-90 с выводом в HDF5-файлы. Подразумевается, что на машине уже установлен gcc и gfortran.