вторник, 13 ноября 2018 г.

Why gravity corrections for latitude/free-air/Bouguer/terrain are obsolete and the spatial filtered observed gravity must be used instead

Link: https://www.linkedin.com/pulse/why-gravity-correction-latitudefree-airbouguerterrain-pechnikov/

Traditional geophysics uses a set of corrections (reduction) for the observed gravity measurements (https://en.wikipedia.org/wiki/Bouguer_anomaly). But what they mean? In terms of common physics these are just products of spatial bandpass filtering. However geophysics still based on these rough coefficients instead of using spatial bandpass filters. That’s really nonsense when these common tables of coefficients applied to high-resolution data observations! As example we have subcentimeter accuracy and ~100m spatial resolution of altimeter satellite measurements to calculate gravity on the sea surface level. In fact the table-based corrections are only tribute to traditions and these are absolutely useless. Let’s use spatial filters to extract the anomalies of all spatial scales.

Pearson correlation between spatial harmonics of free-air gravity anomaly on the Earth's surface and the Earth's topography is almost 1

Link: https://www.linkedin.com/pulse/pearson-correlation-between-spatial-harmonics-gravity-pechnikov/


We consider Free-air gravity anomaly and ETOPO1 topography in WGM2012 Earth's gravity anomalies datasets (see references below).

There is high correlation (0.80) between topography and free air gravity for small areas only:


For relatively large areas the correlation is low (0.41) but the scatter plot looks strange. Let's decompose in spatial domain the topography and the free air gravity and check the spatial harmonics. Pixel resolution of these datasets is about 3.7km. For spatial band pass pixel-wise filters 1-4px, 4-8px, 8-12px, 12-16px, 16-20px we have spatial scales 3.7-14.8km, and so on.


We see on the pictures above that the correlation between the same spatial harmonics of topography and free air gravity is very high for as small as large areas. In fact we have the same results by all spatial harmonics based methods on topography and free air gravity. For example there is well-known Saxov-Nygaard method where concentric circles mean the spatial harmonics (Saxov, Nygaard, 1953). Also we provide our technology to restoring the density gradient of the geological environment from the high-frequency component of the gravitational field or topography data.

References:

1. WGM2012 global model: WGM2012 Earth's gravity anomalies,

http://bgi.omp.obs-mip.fr/data-products/Grids-and-models/wgm2012

2. Saxov, S., & Nygaard, K. (1953). RESIDUAL ANOMALIES AND DEPTH ESTIMATION. GEOPHYSICS, 18(4), 913–928. doi:10.1190/1.1437945

среда, 15 августа 2018 г.

Кольцевые структуры в геофизике

Опубликовал теоретическое обоснование и результаты численной модели для появления кольцевых структур в гравитационном поле. Поскольку найденные структуры существуют после применения фильтра высоких частот к полю, из этого следуют разные интересные вещи. Например, эти же структуры проявляются в цифровой модели рельефа и на космических снимках. Таким образом, подтверждаются практические работы Ю.И. Фивенского о существовании разномасштабных кольцевых структур, их видимости на рельефе и на снимках и пропорциональности их радиусов с глубиной залегания вызывающих их источников таких, как ловушки углеводородов, с коэффициентом около 0.7. Также можно предположить, что снежный покров работает как фильтр высокой частоты, что и позволяет лучше проявиться паттернам на поверхности - для тех конфигураций источников, которые иначе без фильтрации гравитационного поля не различимы.

Ссылка на гитхаб-репозиторий со статьями: https://github.com/mobigroup/articles/ Первые две работы вводные, интересные для геологов результаты получены в последней:


[1] Alexey Pechnikov, Compensation of noise using circular mean Radon transform for the inverse gravity problem, 2018
https://github.com/mobigroup/articles/blob/master/gravity/sphere_radon.pdf

[2] Alexey Pechnikov, Using circular mean Radon transform for circular geological structures recognition and 3D куба как значений КПР [1], [2], известного также какD geological volume reconstruction, 2018
https://github.com/mobigroup/articles/blob/master/gravity/circle_radon.pdf

[3] Alexey Pechnikov, Using circular mean Radon transform for numerical solution of inverse gravity problem, 2018
https://github.com/mobigroup/articles/blob/master/gravity/pairs_radon.pdf

пятница, 1 июня 2012 г.

geomed3d-tclshp package for Shapefile creation from Tcl scripts

Понадобилось мне создавать шейпфайлы, попробовал делать это через gdal (типы полей в DBF, похоже, всегда строковые, не подходит, да и не понравилось - нужно создавать XML файл, в котором прописывать имена файлов, и проч. непотребства совершать) и Spatialite (типы полей могут быть и числовые, но все равно не устраивает - сложно и не быстро). Опробовав два вышеназванных пути, сделал свой пакет GeoMed3dSHP для языка Tcl (получается вдвое быстрее, чем делать то же через Spatialite). Пример использования:
rm -f test.* && tclsh8.5
package require GeoMed3dSHP
set id [SHPCreateFiles test]
SHPWritePoint $id 374868.671871 2828378.81973 100.0 777
SHPWritePoint $id 374868.671871 2828378.81973 100.0 888
SHPCloseFiles $id
exit
Ну и заодно расширение GeoMed3dDBF для создания только DBF файлов:
rm -f test.* && tclsh8.5
lappend auto_path .
package require GeoMed3dDBF
set id [DBFCreateFile test]
DBFWrite $id 374868.671871 2828378.81973 100.0 777
DBFWrite $id 374868.671871 2828378.81973 100.0 888
DBFCloseFile $id
exit
Типы полей в DBF фиксированы, ибо мне так надо :) При необходимости поправить тип/количество полей в DBF в исходнике сложностей не вызывает.

вторник, 24 января 2012 г.

Сканер CanoScan LiDE 210 в debian


Взял себе на днях CanoScan LiDE 210 взамен CanoScan LiDE 90, для которого поддержку так и не сделали в линуксе, а танцы с бубном мне надоели. Итак, подключил CanoScan LiDE 210, запустил xsane - все работает. Не настраивал вообще ничего, только установил xsane. Сканер шустрый и достаточно тихий. С поддержкой кнопок (в терминологии разработчиков sane - sensors) все хреново, как обычно, но есть финт ушами:
$ scanimage -d "genesys:`sane-find-scanner|grep CanoScan|cut -d' ' -f 10`" -A|grep '\[hardware\]'|grep "\[yes\]"|wc -l
0
а теперь нажимаем любую кнопку:
$ scanimage -d "genesys:`sane-find-scanner|grep CanoScan|cut -d' ' -f 10`" -A|grep '\[hardware\]'|grep "\[yes\]"|wc -l
1
Одна из кнопок сканера не вызывает никакой реакции, остальные работают (хотя их названия в выводе scanimage -A перепутаны). Так что несложно сделать скрипт для пакетного сканирования, реагирующий на кнопки:
scan.sh
#!/bin/bash

SCANNER=`sane-find-scanner|grep CanoScan|cut -d' ' -f 10`
if [ -z $SCANNER ]
then
    echo "Scanner not found!"
    exit 1
fi
SCANNER="genesys:$SCANNER"

counter=1
while true
do
    BUTTON=`scanimage -d "$SCANNER" -A | grep '\[hardware\]' | grep "\[yes\]" | wc -l`
    if [ $BUTTON == 1 ]
    then
        echo -n "Start scan image $counter ..."
        scanimage -d "$SCANNER" --resolution 75 --mode Color --depth 16 --format png > $counter.png.tmp
        mv $counter.png.tmp $counter.png
        echo " complete"
        counter=$(($counter+1))
    fi
done
Собственно, запускаем вышеуказанный скрипт и жмем любую кнопку на сканере после помещения в него очередного документа.

суббота, 17 декабря 2011 г.

Открытый софт для научных расчетов

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

Дело происходит в Linux Debian, соответственно, интересует софт, который устанавливается из стандартного репозитория (что подразумевает опенсорсность). 

Для начала я протестировал двумерное Фурье преобразование (прямое и обратное) на широко известном тестовом изображении Lenna. Заодно в процессе поиска нужных функций увидел заметки об истории этого изображения Просто Лена и Обработка изображений: кто такая Лена

Выбор софта для такой типичной задачки вполне себе наличествует:
На практике же оказалось не так радужно, как хотелось бы. Из того, что есть в дебиане, работает "из коробки" только пакет octave. Зато для него можно установить множество расширений - например, необходимый мне пакет octave-image. Если же расширения нет в дебиан, можно установить из репозитория octave. Например, если мы хотим поставить последнюю версию разширения для работы с изображениями, качаем архив image-1.0.15.tar.gz: и далее в текущей директории выполняем:

aptitude install octave3.2-headers 
sudo octave
pkg install image-1.0.15.tar.gz
exit

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

Далее я занялся тем, для чего, собственно, и подбирал софт. А именно, построением 3D модели земных недр по космоснимкам высокого разрешения. Несколько ссылок из предметной области:


На 32-бит хосте обработка космоснимка порядка 60 Мб размером требует около 1 Гб ОЗУ. Если же выполнять передискретизацию (скажем, уменьшить матрицу значений в 3 или 5 раз), то и намного меньше. Для Landsat 7 панхроматический снимок будет имеет вдвое большее разрешение и примерно вчетверо больший размер, так что 60 Мб снимок видимого и ИК диапазонов  соответствует примерно 250 Мб панхроматическому. Значит,  8 Гб ОЗУ на 64 бит хосте должно хватить и на обработку панхромата без передискретизации. Интересно, удастся ли это сделать на 32 бит хосте. Скоро проверю и это, как отлажу расчет на ближнем ИК диапазоне. Update. На 32-бит хосте панхроматический снимок прочитать не удалось - octave сообщает, что невозможно выделить требуемый объем памяти.

Статьи и документация по Octave плюс еще некоторые полезные ссылки:

среда, 14 декабря 2011 г.

MS Excel XML to CSV

XSLT file excel2csv.xsl
<?xml version="1.0" encoding="UTF-8" ?>
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:mso="urn:schemas-microsoft-com:office:spreadsheet" version="1.0">
<xsl:output method="text" encoding="UTF-8"/>
<xsl:template match="/">
   <xsl:for-each select="mso:Workbook/mso:Worksheet/mso:Table/mso:Row">
        <xsl:for-each select="mso:Cell">
                <xsl:value-of select="mso:Data"/>
                        <xsl:if test="position()!=last()">
                        <xsl:text>      </xsl:text>
                        </xsl:if>
        </xsl:for-each>
        <xsl:text>&#10;</xsl:text>
   </xsl:for-each>
</xsl:template>
</xsl:stylesheet>

Important: you may replace 4 spaces in "<xsl:text>      </xsl:text>" to single tabulation (or any other delimiter)!

Use as
cat file.xls | xsltproc excel2csv.xsl - > file.csv

пятница, 25 ноября 2011 г.

Lossless музыка: ape+cue и flac+cue

Как мне недавно имели честь сообщить, аз есмь ретроград - не слушаю Vinil RIP :) В самом деле, по старинке обхожусь mp3. Собственно, когда-то проблемы были с воспроизведением lossless форматов, а разницы с mp3 не заметил. Но вот сегодня доступно много всякого разного именно в виде рипов виниловых пластинок, из того что я давно хотел отыскать - так что разбираемся.

1. Если у нас есть flac+cue - достаточно привести к юникодной кодировку (текстового) файла cue:
cat *.cue | iconv -f cp1251 -t utf8 > .cue
Впрочем, необходимо это только тогда, когда имя файла flac содержит не-латинские символы - в ином случае все можно прослушать и без перекодировки.

2. Когда у нас наличествует набор файлов ape + cue, ставим пакеты pacpl, flac и monkeys-audio (для установки последнего нужно подключить репозиторий http://www.debian-multimedia.org/) и далее перекодируем (здесь команда рекурсивно пройдет все подкаталоги в поисках файлов ape и создаст файлы flac):
pacpl -t flac -o ape -r .
Как и выше, перекодируем файлы cue в юникод и меняем в них имя_файла.ape на имя_файла.flac

Прослушать файлы cue умеет audacious ( в нем можно настроить определение кодировки CP1251 для файла cue и проч.) и qmmp (работает в однобитной кодировке, так что кириллические названия в нем увидеть не удастся, но прослушать трэки - можно). Из прочих популярных плееров _не справились_ с задачей amarok, rhythmbox, juk и smplayer.

Ссылки:
Работа с flac+cue и ape+cue в Debian
Converting Monkey’s Audio (ape) to flac in Ubuntu
Split lossless audio (ape, flac, wv, wav) by cue file in Ubuntu

пятница, 29 июля 2011 г.

О LevelDB и SQLite


Новость:
Компания Google открыла исходные тексты БД LevelDB

Кратко о LevelDB - хранилище ключ-значение, однопоточный доступ, нет гарантий целостности всех данных, в памяти держит копию всех данных лог-файлов.

Утилита для тестирования SQLite у них кривая, мои патчи к ней брать тут

Результаты тестирования с патчем для использования целочисленного Primary Key смотреть здесь

Как видим, LevelDB на тестах показывает местами так себе преимущество относительно реляционной транзакционной СУБД... а местами ухитряется быть еще и медленнее :) Неплохо бы сравнить с CDB от DJB с патчем, убирающем ограничение на "константность". В любом случае, по проведенным тестам нет смысла в использовании LevelDB - функционал урезан сильно, а заметного выигрыша в производительности не видно.

Равно есть куда улучшать и SQLite - некоторые результаты плохи на фоне остальных тестов. Значит, у нас многое еще впереди.

пятница, 22 июля 2011 г.

Обновление eglibc в debian

eglibc (2.13-8) unstable; urgency=low

Starting with the eglibc package version 2.13-5, the libraries are
shipped in the multiarch directory /lib/$arch instead of the more
traditional /lib.

The toolchain in Debian has been updated to cope with that, and most
build systems should be unaffected. If you are using a non-Debian
toolchain to build your software and it is not able to cope with
multiarch, you might try to pass the following options to your
compiler:

-I/usr/include/$arch --sysroot /usr/lib/$arch

-- Aurelien Jarno Sun, 26 Jun 2011 22:28:52 +0200



(C) Alexey Pechnikov aka MBG, mobigroup.ru