СП 250.1325800.2016 — «Здания и сооружения. Защита от подземных вод»

В прошлой своей записи я обещал поделиться мнением о новом СП 250.1325800.2016. Я вообще люблю обещать о чем-нибудь рассказать, а потом благополучно об этом забываю, но не в этот раз. Уж больно любопытный документ. Сразу скажу, что по моему скромному мнению, он достаточно толково написан, хотя содержит несколько, скажем так, спорных моментов. Вот, один из них:

6.3.2.2 При постановке расчетов «в понижениях» (6.1.13—6.1.14) верификация модели может быть выполнена на основе данных по эксплуатации водозаборных скважин, систем водопонижения и дренажей (их производительности и вызванных ими изменениях уровней подземных вод). В этом случае критерием достоверности построенной геофильтрационной модели служит удовлетворительное совпадение натурных и модельных изменений уровней подземных вод.

При моделировании в пределах небольших по размеру зон влияния водопонизительных или дренажных мероприятий, когда формирование водопритоков и воронки депрессии в основном определяется геофильтрационными параметрами, полученными на площадке строительства, верификацию геофильтрационной модели, построенной для решения «в понижениях», допускается не проводить.

Как я вижу этот пункт: с оговорками, ограничениями и допущениями специалисту законодательно дается возможность «лепить» модель как левая пятка пожелает. Ну, т.е. без верификации. Берем фильтрационные параметры «по лаборатории», ну ладно, пусть даже ОФР сделают, ограничиваем площадь моделирования тремя размерами здания и считаем задачу «в понижениях». Впрочем, надо отметить, что этот подход применим только для расчета водопонижения, но не для «барражного эффекта» (и об этом прямо сказано в обсуждаемом СП). И что-то я не припомню, чтоб считал за последние несколько лет модели только с водопонижением, но без барража (хотя некоторые, пожалуй, и можно было).

Вообще я иногда использую эти самые «решения в понижениях». В понижениях удобно на модели режим обрабатывать — нивелируются ошибки в высотной привязке пунктов наблюдения. Для прогнозных же расчетов, как мне кажется, этот подход в основном применим в рамках диапазонного анализа: с его помощью можно сравнительно просто и быстро показать особенности работы того же водопонижения при различных значениях параметров (той же проводимости, к примеру, раз уж мы без верификации работаем).


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

И еще разок о сметах

Шесть лет назад (ужас какой, как быстро летит время!) я писал об особенностях осмечивания работ на моделирование. Насколько я понимаю, идея с обновлением методик расчета смет так и осталась лишь идеей. Проблемы же никуда не делись, однако маразм достиг новых высот, точнее — глубин. Теперь отчет по гидрогеологическому моделированию (кстати, а вы в курсе что теперь действует новый СП 250.1325800.2016, в котором весьма подробно это самое моделирование описано, но об этом замечательном документе я чуть попозже напишу) рискует получить замечания не только от эксперта-геолога, но и от эксперта по сметам. И тут начинается цирк с конями: «а почему у вас так много ячеек, а почему такая большая область моделирования, давайте вы сделаете ячейки побольше, а область поменьше, а то у нас смета слишком большая получается» и т.д. Если вдуматься, это же бред какой-то: я при моделировании должен подстраиваться под смету, лишь бы она за лимиты не вышла и размеры области моделирования выбирать не из гидрогеологических предпосылок, а под смету подгонять.

У меня есть грешок — я люблю делать большие по площади модели, мне так удобнее. Особенно, когда нет проблем с факт-матом. А само сооружение делается либо на модели-врезке (редко), либо у него просто сильнее дробится модельная сетка (чаще).

Вроде бы пока удается решить проблему со сметчиками указанием размеров именно модели-врезки или участка с подробной сеткой. Получается и нашим и вашим — и цена по смете разумная и модель переделывать не надо.

О постановке на кадастровый учет зон подтопления

Занятный момент обнаружился: оказывается, если какая-либо граница зоны подтопления пересекает урез реки, то при попытке поставить такую границу на кадастровый учет придет отлуп, т.к. с точки зрения валидатора такого не может быть.
Таким образом, типичный в общем-то случай, когда при глинистом ложе реки наблюдается слабая связь между уровнем грунтовых и поверхностных вод (а то и вовсе отрыв уровней и режим «дождевания»), оказывается «вне закона». Фактически приходится фальсифицировать расчетные зоны подтопления для прохождения валидации кадастровой службы.

Вакансия полевого гидрогеолога

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

Обращаюсь к уважаемым читателям блога, если у вас есть желание, возможность и достаточно квалификации для работы в качестве полевого гидрогеолога, то напишите мне на water+blog@alick.ru.

Работа предстоит тяжелая, но интересная в суровых, но красивых местах: Чукотка, Норильск, Приморье, Камчатка и др. Задачи обычно довольно стандартные: проведение опытно-фильтрационных работ с целью оценки водопритоков в подземные выработки и поиска месторождений подземных вод.

Жду ваши резюме на почте.

ОФР и моделирование

Даже среди умудренных сединами гидрогеологов довольно популярно мнение, что все эти ваши откачки совершенно не нужны при создании модели. Типа все подберем при калибровке. Накидаем «от фонаря» граничных условий (особенно тех, которые 4 рода, т.е. границ с разными фильтрационными характеристиками) и получим идеальный «диагональный график».
Должен заметить, этот подход возник не сам собой и не от хорошей жизни. Когда изыскатели 90% откачек просто рисуют (о художественной ценности этих «произведений» поговорим как-нибудь потом) — тут уж действительно, уж лучше бы их действительно и вовсе не было. Более того, из оставшихся 10%: 5 — проведены или обработаны неграмотно, а 4 — просто неудачные в силу разных обстоятельств. Так и остается 1% нормально проведенных удачных откачек с правильной обработкой. Маловато, прямо скажем. А еще бы с лупой присмотреться на эти откачки, так и вовсе окажется, что они такие удачные потому, что их «рисовал» не инженер-камеральщик, а более или менее грамотный гидрогеолог.
Вот так и получается, что не нужны откачки при моделировании — только проблем лишних создают, т.к. вынуждают потом отдельно объяснять почему принятые при моделировании параметры не совпадают с данными ОФР. И ведь не скажешь, что «ввиду очевидной фиктивности исходных данных, внимание мы на них обращать не будем», как бы этого ни хотелось.
Совсем другое дело, когда и ОФР и моделирование делает один и тот же специалист-гидрогеолог. Тут даже неудачный опыт может дать толику информации. Правда, далеко не все моделисты хорошо разбираются в откачках (чего греха таить, я и сам такой), но уж хотя бы пусть посмотрят. Поэтому я никогда не отказываюсь от приглашения поприсутствовать на реально проводимых заказчиком ОФР.

Уже ничего не стесняются

Совсем народ стыд и совесть потерял. Ребята вообще не палятся.

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

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

На днях привалило мне «счастье» - 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.: Для особо прозорливых, кто догадался, что это за база: извините, не моё — не дам.