Крупнейший оползень в Боливии

Учитесь программировать

На днях привалило мне «счастье» - 100 с гаком гигабайтов базы данных. Очень важных и очень интересных. Однако сразу всплыло несколько "но":

1. База создана в Borland Interbase 7.5.
2. Сами важные данные хранятся в виде BLOB-записей в графическом формате.

Сначала пришлось изрядно повозиться только для того, чтоб просто открыть базу, т.к. общедоступный Firebird этого формата не понимает. Потом выяснилось, что ни одна из популярных программ для работы с базами Interbase не умеет в пакетном режиме выуживать из оттуда BLOB-записи и сохранять их в виде файлов. Задача еще усложнялась тем, что мало выудить файл, надо еще его сохранить под правильным именем, которое хранится в отдельном столбце в таблице.
Делать нечего, пришлось экспортировать базу в формат SQLite. В принципе, на этом можно было бы и остановиться, SQLite вполне себе общеупотребимый и удобный формат, но опять проблемы:

1. BLOB-записи из Interbase почему-то сконвертировались в HEX-строки SQLite (хотя тоже в формате BLOB). Т.е. из бинарного вида они превратились в ASCII: "04В458A4C1...". Т.е. напрямую с этими данными работать не получится — придется извлекать, конвертировать в бинарный вид и уже после этого открывать в графическом редакторе. Либо, как вариант, можно пройтись по базе и перекодировать данные.
2. Сама идея хранить файлы в базе данных мне кажется сугубо порочной. Для файлов уже создана отличная база данных и называется она — файловая система.
3. Программы, которые я подобрал для извлечения BLOB-записей из SQLite, отлично работают на маленьких базах, но на больших либо денег просят, либо падают от недостатка памяти при экспорте >1000-й строки (а всего там их около 80 тысяч), а часто и то и другое.

Помог скрипт sqlite-blob-dumper.py. Пришлось его немного модифицировать (о слава тем далеким годам, когда я занимался программированием), чтобы имена экспортируемых файлов брались из базы, а не генерировались на основе номера строки, названия базы и столбца с данными и все заработало. Причем довольно быстро и без проблем с памятью.
Скрипт уже выгрузил 80% базы, когда я понял, что могу сэкономить еще одну итерацию: ведь файлы сохранялись все в том же HEX-виде и для перекодирования в бинарный вид я собирался использовать отдельную программу xxd.exe — хорошую, но медленную под Windows. Тормознул скрипт, модифицировал, добавив в него функцию перекодирования. Теперь файлы сразу сохраняются в нужном бинарном виде — существенная экономия времени и дискового пространства.

P.S.: Для особо прозорливых, кто догадался, что это за база: извините, не моё — не дам.

Халтурщики

Есть у меня один «любимый» заказчик, который из серии — «за копейку канарейку, чтоб басом пела». Ну очень любят на всем экономить. Сначала сэкономили на выборе участка строительства — строят в пойме реки. Потом сэкономили на изысканиях — выбрали таких изыскателей, что не особо утруждаясь нарисовали все без бурения «как попросили» проектировщики. На проект, думаю, тоже денег не много ушло — изыскания то были рисованы под самые простые проектные решения. Насчет строительства я не особо в курсе, но думаю, что и в этом они были верны себе.
Что в результате:

1. Дороги, отсыпанные местным грунтом, не держат строительную технику — грузовики уходят под грунт по самую крышу.
2. Уже построенные корпуса покосились через полгода после окончания строительства.
3. Строят рядом два новых здания: одно с осушением котлована иглофильтрами, другое со «стеной в грунте» из бетона. И тут беда: почему-то бетона на заливку буросекущих свай «стены в грунте» уходит на треть больше. Причем они скорее поверят в барабашку, который ворует под землей бетон, чем в суффозию.

И это они еще через экватор строительства не перевалили. А кто-то еще потом в этих домах квартиры купит. Бр-р.

Зоны подтопления

В последнее время ко мне в почту часто приходят вопросы по поводу федеральной программы по определению зон затопления и подтопления. В крайне невнятном ТЗ от государственного заказчика часто прямым текстом бывает указано, что зоны подтопления определяются на основе архивных данных изысканий. Исполнитель несет отчет в экспертизу и получает логичное замечание о необходимости проведения режимных наблюдений. В особо тяжелых случаях требуют годовой ряд наблюдений, хотя формально можно ограничиться периодом проявления процесса (СП 11-105-97).
В принципе, зоны подтопления можно нарисовать и вовсе без режимных наблюдений — основываясь на параметрах, полученных при откачках. Для этого есть формулы Каменского и Форхгеймера, а можно и вовсе модель сделать. Однако, именно режимные наблюдения есть прямой метод по изучению процесса подтопления и поэтому крайне желательно применять именно их.

Дайджест ссылок

Geology of Britain. Интерактивная геологическая карта Британии. Круто сделано. У нас, кстати, тоже есть нечто подобное, но масштаб помельче.

What is the relevance of confined / unconfined aquifer type on groundwater flow? Любопытная статья о напорных и безнапорных горизонтах и как их моделировать.

Maybe confined or unconfined aquifer are terms that would sound familiar from your first hydrogeology class, however it´s a simple definition about the location of the hydraulic head over the vertical limits of your aquifer. It might be that you have employed those terms in different reports, or maybe you have seen this aquifer classification on some environmental impact assessments or geological reports, but which is the relevance of this classification on the groundwater flow? This article talks about the comparison of the the confined / unconfined aquifer condition based on numerical modeling with some discussion about the convertible character of the aquifer.

The limits of modelling: knowing we don’t know. Коротенькая, но очень правильная статья о том, как ошибки в концептуальной модели приводят к неверным прогнозным решениям. Там очень занятная мысль есть: попытка восстановить на модели реальную (гидро)геологическую среду по данным бурения — это все-равно, что нарисовать человека, видя только его палец.

Modelling the impact of mine developments on groundwater is critical for protecting ecosystems and agriculture, but it can go astray if we don’t recognise that all models lack certainty.

Australian groundwater modelling guidelines. В статье выше нашел эту ссылку (там еще несколько есть, кстати). Молодцы австралийцы — заботятся о коллегах-гидрогеологах. Такие шикарные руководства по моделированию пишут.

This paper is part of a series of works commissioned by the National Water Commission on key water issues. This work has been undertaken by Sinclair Knight Merz and the National Centre for Groundwater Research and Training on behalf of the National Water Commission.

Хозяйке на заметку

Когда заказчик зовет вас в экспертизу снимать замечания эксперта к вашему отчету — сперва убедитесь, что эксперт ваш отчет вообще видел. Иначе рискуете попасть в не самую приятную ситуацию.

Главгосэкспертиза

Решил рассказать о случившемся со мной недавно очередном разочаровании в людях.
Довелось мне считать прогноз влияния расширяющейся свалки на подземные воды. Глянул я на геологическую карту и ахнул: в 200 м ниже по потоку зияет конкретная такая дыра в водоупоре, а ниже залегает ни много ни мало — основной водоносный горизонт, эксплуатируемый для водоснабжения в не самом маленьком регионе нашей страны. Я как честный специалист все это дело задал на модели и получил закономерный результат: как вы свалку ни изолируйте, но загрязнение в горизонт через 10 лет попадет — к гадалке не ходи. Хорошо изоляцию сделаете (кто в теме, тем уже смешно) — меньше придет, да и только. Соответственно и выводы сделал: свалку не расширять надо, а убирать отсюда подобру-поздорову, и автограф свой честный поставил.
Что самое удивительное: именно в таком виде и с такими выводами мой отчет пошел в «Главгосэкспертизу». Честно скажу: не ожидал такой смелости от заказчика.
А вот от экспертизы я получил совершенно убийственные замечания. Дословно не помню, но смысл примерно такой: наличие окна водоупоре не подтверждено данными бурения (ну правильно, оно далеко за пределами площадки изысканий), а карты ваши — филькина грамота и никакого к ним доверия. Поэтому либо бурите там скважину (ага, кто нам разрешит), либо убирайте окно из расчетов и пишите положительные выводы.

Как бороться с осушенными ячейками

Я уже писал когда-то на эту тему. Пришло время немного обновить советы.
Модельные ячейки осушаются в том случае, когда уровень воды в безнапорной ячейке на каком-то из этапов расчета оказывается ниже её подошвы. В ряде случаев, это абсолютно нормальное явление, хотя по-возможности лучше этого избегать, но в большинстве ситуаций — такое поведение модели является результатом ошибки. Если площадные размеры модельной ячейки сильно превышают ее мощность, а градиент фильтрационного потока очень большой — с большой степени вероятности ячейка осушится. Когда подошва слоя активно «ныряет» вниз и «взлетает» вверх — тоже жди неприятностей.
Несколько способов борьбы с этим явлением:

1. Смириться. В ряде случаев, как я уже говорил, осушение — это вполне ожидаемая модельная картина, но сразу предупрежу: делать потом на такой модели прогнозные расчеты будет очень сложно, если вообще возможно. 
2. Дополнительно дискретизировать модельную сетку на проблемных участках. Способ очевидный, однако он не всегда помогает, а если и помогает, то увеличивает время счета, что критично при многовариантных расчетах или при использовании модулей автоматического подбора параметров типа PEST. 
3. Использовать опцию повторного обводнения (rewetting). Такая опция стала доступна в MODFLOW-2000/2005, однако будьте готовы к проблемам со сходимостью. Кроме того, скорость расчета после включения этого режима падает чуть ли не на порядок. 
4. Воспользоваться MODFLOW-NWT. Этот алгоритм был специально разработан для борьбы с нежелательным осушением ячеек. Работает в целом хорошо, стабильно и сравнительно быстро, но иногда излишне «сопротивляется» этому самому осушению, как-бы «размазывая» УГВ тонким слоем по подошве слоя.