В грунте по колено | Геотехника

Нейронки для инженера: парсим мониторинг 🤓   В геотехнике очень полезно сравнивать результаты расчетов с фактическим поведением зданий и сооружений, иными словами – очень важен опыт строительства. Для этого на всех наших объектах мы закладываем геотехнический мониторинг, который впоследствии сравниваем с результатами расчетов. Так мы сравниваем то, как здание или сооружение «должно» себя вести по результатам расчетов, и то, как они ведут себя фактически, и извлекаем из этого немало пользы, особенно при строительстве нескольких объектов на одной территории – каждый построенный объект является «испытательным полигоном» для следующих и позволяет назначать более корректную этапность строительства и заранее калибровать расчетные модели. Но как водится – объектов много, марок еще больше (ну еще бы), циклы измерений раз в месяц, вроде бы одинаковые журналы измерений могут заполняться по-разному – играет человеческий фактор, марки теряются и вводятся вновь. Чтобы обработать это все, надо сильно заморочиться и потратить уйму времени. 🔺И тут в дело вступают нейронки🔺 Один из вариантов применения этих чудесных технологий — парсинг массивных документов, которые приходят в максимально неудобной для дальнейшей работы форме.   Как это выглядит до их применения: мы получаем очередной отчёт по геотехническому мониторингу на n-ое количество страниц, где на первый взгляд всё красиво: таблицы, графики, схемы, фотографии. Но попробуй вытащить оттуда несколько десятков (а то и сотен) измерений марок за все циклы, сопоставить их между собой, привязать к этапам строительства и подготовить данные для дальнейшего анализа. Это куча монотонной ручной работы: как только представляешь этот объем, да помноженный на количество объектов, появляются мысли – а не нужны ли нам еще люди в отдел? Мечты, мечты.   Так что там с нейронками и как мы их используем? Поясним для тех, кто пока не в курсе: парсинг – это автоматическое извлечение нужных данных из документа и укладывание их в заранее заданную структуру. Самый надёжный вариант здесь не просто закинуть PDF в чат и попросить нейронку «разберись, пожалуйста», рабочая схема выглядит немного сложнее: ⚫️обычный парсер вытаскивает из PDF текст и таблицы; ⚫️если документ оказался сканом, подключается распознавание текста — OCR; ⚫️нейронка получает данные и строгую схему: объект, номер марки, дата, цикл, отметка, приращение, накопленное перемещение и другие нужные поля; ⚫️отдельный скрипт проверяет пропуски, дубли, единицы измерения и подозрительные скачки; ⚫️результат собирается в единую таблицу Excel. Дополним для тех, кто шарит: Python + PyMuPDF/pdfplumber + OCR + JSON + pydantic (валидация) + pandas ➡️ Excel. Для текста и разметки отлично справляется PyMuPDF. Но если в отчёте сложные таблицы с объединёнными ячейками подключаются специализированные инструменты вроде pdfplumber или camelot. Нейронка получает распознанный текст и работает в режиме строгого вывода, она знает заранее заданную схему: объект, номер марки, дата, цикл, отметка, приращение, накопленное перемещение и другие нужные поля. Результат на выходе - не свободный текст, а валидный JSON, где каждое поле строго на своём месте.   При этом нейронка не заменяет геотехника – она не рассчитывает деформации и не оценивает их допустимость. Здесь она работает переводчиком между не самым удобным документом и строгой структурой данных. Всё, что не прошло автоматические проверки, отправляется человеку геотехнику на контроль. Как итог мы получаем единую большую таблицу, полностью готовую к анализу и визуализации. Кайф! 😎 Саму визуализацию мы пока что выполняем во внешнем софте – Кредо Деформации. Ключевое здесь «пока что»: структурированные данные и опыт написания приложений у нас уже есть, а значит следующий шаг вполне читаем 🥹   Кстати, зацените: на картинке показан результат обработки мониторинга и поведение расчетной модели на одинаковом этапе строительства. Как по мне, это более чем солидный результат 😋

Неделю назад рассказали вам тру-стори о том, как внутри нашего отдела начали появляться приложения вместо экселек, а уже сегодня мы расскажем о том, как Света продвинулась в работе с ИИ во время написания тех самых приложений! 😎 Раньше обращение к нейросетям было похоже на горячую картошку: Света писала код в Visual Studio и копировала блоки кода из редактора, вставляла их в чат нейронки и сама накидывала ей контекст. После обработки запроса нейронкой происходили обратные манипуляции: Света вручную создавала файлы, переносила код, вносила правки в namespace-ы (контейнер имен, вроде переменных в формуле, к которому обращается программа). Если в ходе работы возникали изменения в архитектуре, появлялись новые файлы или «забывались» глубокие переписки из-за ограничений контекстного окна – приходилось все начинать сначала: стартовать новый чат и заново грузить нейронку контекстом происходящего. Сложности добавляло то, что спецификация оставалась в истории сообщений, а не в репозитории. В общем, сплошные сложности, лишние клики и никакой оптимизации, а это, как известно, – минус вайб 😕 Но что происходит сейчас: Сейчас Света выполнила консольную интеграцию ИИ-агента внутрь Visual Studio, в данном случае это Kimi Code. «Кими» видит всю файловую структуру проекта, знает namespace-ы и подключенные сборки, читает и редактирует файлы самостоятельно. Теперь не нужно ничего копировать – просто ссылаешься на нужный файл и алга voila! Нейронка сама предлагает изменения, а Света их проверяет и только после этого внедряет одной командой. Также преимущества консольного ИИ-агента над условным DeepSeek в том, что он может «сверх» обычного функционала нейронки создавать новые классы, переименовывать файлы, генерировать документацию внутри директории проекта и т.д. Будут ли минусы? Нет! Если резюмировать – теперь нет траты времени на механическое перекидывание кода и файлов и накидывание контекста, отчего и качество получаемого результата неумолимо растет. И с ростом сложности задачи эффект от такого внедрения нейронок экспоненциально растет. А самое величие в том, что теперь почти не приходится писать ручками, что позволяет тратить минимум времени на код и максимум на геотехнику и наш руководитель от этого просто счастлив 🥹

Отпуск начался, значит есть время хорошенько поработать заняться пабликом! Накопилось n-ое количество историй, которые хотелось бы вам рассказать, но думаю начать стоит с неочевидного для нас небольшого цикла статей (почти EP рок-группы) - ИИ и программирование. В совокупности и по-отдельности. Штож, врываемся в этот дивный новый мир! ☺️ Путь продукта. Как инженерный скрипт превратился в программу. И при чем тут нейронки? Для начала, дам вам немного контекста происходящего. Однажды мы рассказывали про наши подходы к выводу результатов из Midas GTS NX Нелинейности ГЕО (Да, вы еще увидите такую форму написания, как мы ее ласково между собой зовем, "линейки", начиналась эта эпопея еще в эпоху Midas GTS NX) в различные конструкторские ПК - и даже файлик вам скидывали на посмотреть. На тот момент встроенная утилита Midas-а умела работать только с ЛИРА-ми, а у нас в ходу еще существовал Ing+, да и функционал нам требовался пошире. Так вот, в конечном счете наша экселька полегчала, стала вполне себе шустро работать, ей стало все равно на то, что узлы находятся в разных координатах - даже поворот в пространстве модели был не страшен. И тут же можно было выполнить верификацию результатов и выполнить подгонку жесткостей для максимальной сходимости результатов. Но как бы это все здорово не звучало, но экселька есть экселька - нет возможности создать файлик готовый на все случаи жизни - нет-нет да надо раздвинуть количество строк; что-нибудь начнет троить; формула где-то начнет считать некорректно и все просто выпадает в ошибку пока не перезапустишь; да и создать супер удобный интерфейс, будем честны - сложно. Одновременно с тем, в нашей богадельне есть молодые таланты, у которых есть желание поделать что-нибудь эдакое, интересное и общественно полезное. Так мы и оказались в ситуации, что мы можем написать свой собственный софт. Или правильнее сказать - не "мы", а один конкретный человек-легенда - Света. Идей что можно было бы написать - море, но, одновременно с тем, мы понимали что у нас еще не отлажен этот процесс - его просто не существует - и надо бы просто набить руку, чтобы было понимание как мы с этим живем дальше. Так и было принято решение, что для начала нам надо перевести гору наших экселек в отдельные программы и далее заниматься чем-то более серьезным. И первым конкурсантом на выбывание стала та самая экселька для экспорта результатов из Midas GTS NX Нелинейности ГЕО. А теперь к сути дела. Для тех, кто шарит, сходу напишу что код программы написан на C# + WPF, в процессе были использованы ChatGPT и DeepSeek. В процесс кодинга погружаться не будем, здесь ведь не паблик кодеров, huh? Мы хотим поведать о другом - как мы начали юзать нейронки. Итак, нейронки оказались хорошим подспорьем в решении данной задачи и сильно ускорили процесс разработки. Да, у нас уже была готова математика в экселе - с ней не было вопросов и ее "просто" перенесли в будущую программу. Все остальное помогал осуществить, в основном, DeepSeek - он помог с архитектурой приложения (модульностью, масштабируемостью, разделению ответственности и т.д.); рефакторингом кода (улучшением работы и упрощением кода); интеграцией библиотек (в частности, ЛИРА-api); находил узкие места в архитектуре и предлагал паттерны и абстракции. Резюмируя, нейронка подсказывала как лучше соблюсти принципы проектирования и позволила получить отлично работающее приложение. Как ни тестировали - нуль осечек и ошибок, все летает, еще и фишек стало больше. Из очевидного - теперь данные сами подтягиваются из/в ЛИРА. Кайф! 🤩 Что касается UI и XAML (пользовательский интерфейс - прим. ред.) - они полностью формировались нейронками. Формировался запрос с требованиями к layout и нейронка выдавала готовую разметку приложения, с корректными биндингами (связками кода с интерфейсом) и стилями. В результате это позволило не тратить время на оформление, а все ресурсы пустить в проектирование. Это новый виток оптимизации нашей работы и это очередная ступенька на пути к чему-то новому и интересному. Выражаю огромный респект Свете за возможность на этой ступеньке быть 😎 Стэй тьюнд! 😋

Привет! Соскучились по нам? ☺️ Давно нас здесь не было: все это время мы смотрели за тем, как эта красотка перемещается по площадке. Честное слово! Да-да, оправдания. Лето выдалось жарким на события и нам есть что рассказать: осталось ещё немного отпусков (наконец-то пойду я, пишущий этот пост, ура!) и немного авралов - и начнем писать вам всякое интересное. И, кстати, с прошедшим профессиональным праздником! Счастья, здоровья 😁

Привет! У нас вышел новый пост на портале ГеоИнфо, погнали читать? Расскажите о своем опыте проектирования в Екатеринбурге и в схожих грунтовых условиях, нам будет интересно!

Предупреждаю на берегу: данное видео не относится к предыдущей статье 😁 Видео снято в городе N, автор неизвестен, а происходящее - изумляет. Как вы думаете, какие были планы у сего мероприятия? 😁

Вынести на суд общественности то, о чем пойдет речь далее, лично я – пишущий этот пост – хотел очень давно, но мне все били по рукам: надо дождаться. И дождались! ☺️ В кузнице нашего отдела рождаются не только гениальные (ну а как иначе) тех. решения и хиханьки с хаханьками, но и научные изыскания, большинство из которых остается в закромах, хотя и надо бы их публиковать. Таки пошло, публикуем! Представляем вашему вниманию статью, выпущенную в коллаборации с коллегами из СПбГАСУ и ООО «ГеоСпецТехнология», на тему: Повышение жесткости основания свайного фундамента грунтоцементными колоннами: численное моделирование и экспериментальная верификация. Приглашаем к обсуждению здесь, в комментариях ❤️

Привет с затяжных выходных! Рады сообщить, что у нас теперь есть блог на портале ГеоИнфо 😎 Первый дельный пост, кстати, можете найти по ссылке.

Почти что прямое включение с лагом в 50 минут 😁 Скрестим пальцы, первые 800 тонн уже давят на баррету 🔥 Балка поучаствует после 4500 тонн 🤟 Или не поучаствует, как пойдет 😁

Испытания баррет начнутся со дня на день, а пока мы ждем - ловите красивое видео с площадки

В продолжение цикла постов по испытаниям свай методом O-Cell, а конкретно к теме измерений перемещений: Малютка на фото - это тензодатчик для измерения деформаций бетона и арматуры. В сумме на испытуемую баррету заложено 30 датчиков, измерения деформаций снимаются не реже 15 минут 🤓

Не зря ведь мы писали про испытания методом O-Cell 🤓 Небольшой тизер к будущим постам по этой теме. Переходим от теории к практике 😎

Метод O-Cell. Часть 3.2. Измерение перемещений на глубине – просто. В части 3.1. Мы измерили перемещения нижней части сваи стандартным способом O-Cell - с помощью специальных глубинных датчиков перемещений. Но всегда возникает вопрос: а можно ли сделать то же самое проще — без всей этой «электроники» и сложной обработки? Краткий ответ - можно, но есть нюансы😅 Метод называется «стержень в трубе» в России или «rod-in-tube» в мире. Впервые я столкнулся с этим методом вовсе не в контексте O-Cell, а в книге И.Г. Ладыженского «Перспективные фундаменты» (кстати очень рекомендую к прочтению). Там его применяли на одном из объектов Москва-Сити для раздельного определения перемещений пяты сваи и её оголовка По сути — ровно то, что нам и нужно в O-Cell. А теперь поподробнее про метод «стержень в трубе». Что за стержень в трубе и из чего он состоит? Состав системы: ➡️Штанга (стальная труба Ø 25-50 мм, или арматурный стержень) проходит внутри сваи по всей её длине. Нижний конец штанги анкеруется в арматурном каркасе нижнего сегмента либо приваривается нижней опорной плите O-Cell. ➡️ Защитная труба – необходима для изоляции штанги от перемещения верхней части сваи. Диаметр должен быть чуть больше диаметра штанги. Защитная труба крепится к арматурному каркасу верхней части сваи. ➡️Средство измерения перемещения - механические индикаторы часового типа, LVDT-датчики перемещения. Как это работает? Все просто до безобразия. В тело сваи, до её забуривания или погружения, устанавливают одну или несколько жёстких штанг из стальных труб. Нижний конец штанги жёстко закрепляется в нижнем сегменте сваи, а верхний выходит на поверхность в специальной защитной трубе. На голове штанги устанавливается LVDT (линейный датчик перемещения) или индикатор часового типа. Этот датчик опирается на независимую реперную балку. При нагружении нижний сегмент сжимается и смещается относительно острия. Это смещение передаётся по штанге и фиксируется датчиком наверху. Если кратко: нижняя часть сваи двигается вниз➡️тянет за собой штангу➡️штанга передаёт это перемещение наверх➡️датчик фиксирует. Измеряемая величина: S_down — перемещение нижней части сваи. В чем подвох? ⚡️Может заклинить. При раскрытии O-Cell может возникнуть микроповорт плит и штанга может подклинивать, изгибаться, и работать с тренем о защитную трубу. ⚡️ Ты не узнаешь об этом вовремя После бетонирования ты уже ничего не проверишь. Если что-то пошло не так, узнаешь только постфактум Поэтому обычно ставят не одну штангу, а несколько — чтобы хоть как-то подстраховаться. А что говорят нормы? Если открыть ASTM D8169/D8169M, там, конечно, всё про нормальные датчики — LVDT и т.д. А разные рекомендации типа FHWA и ICE говорят примерно так: да, rod-in-tube можно использовать… но лучше как вспомогательный метод. P. S. На фото опорная пластина с таким датчиком на одном из объектов Москва-Сити.

Как говорил Хьюберт Фарнсворт - гуд ньюс евриван! Наши друзья из компании «МИДАС» сообщают о новом витке развития! Загибайте пальцы: 1. Теперь это наш, свой, местный - российский разработчик! Вау 😎 2. Разработали новую единую инженерную платформу НЕЛИНЕЙНОСТЬ, где объединили под одной крышей весь доступный софт! 3. То чего мы так долго ждали: интерфейс на русском! 🥹 По этому поводу 23 апреля в 10:00 Мск состоится онлайн-конференция, где нам все подробно расскажут и покажут о всех нововведениях, а именно: - презентуют новую платформу; - объяснят логику ребрендинга и дальнейшего развития; - расскажут о реальных кейсах пользователей; - вместе с экспертами расскажут об особенностях нового ПО. Итак, делаем пометки крестиком: ✔️ 23 апреля, 10:00 по МСК ✔️ онлайн-трансляция ПРОЙТИ РЕГИСТРАЦИЮ

Друзья, коллеги, привет! Связь нынче штормит, потому зовем в ловящий даже на парковке MAX, чтобы вы могли читать нас всюду. Ссылку оставил в приветственном посте. И на всякий случай здесь ✔️ Со временем перетащим туда архивные посты и параллельно будем дублировать новые. Это не означает что мы бросим писать здесь - держимся до последнего, используем все доступные ресурсы чтобы выходить на связь. Также добавил ссылку, чтобы вы могли написать нам здесь, оказывается я ее не добавил ранее, приношу свои извинения 🥺 Связь!

Метод O-Cell Часть 3.1. Что и как измеряем? В части 2 мы довольно подробно (наверное, даже слишком подробно🥱) ответили на вопрос: «Из чего состоит O-Cell?». Мы поняли как именно устроена конструкция O-cell и как передается испытуемая нагрузка на сваю. (все немного сложнее, чем при стандартных испытаниях). Теперь мы переходим к изучению одной из главных составляющих метода O-Cell - Измерительной системе. В один пост уложиться не получилось - будет продолжение.

Метод O-Cell Часть 2. Из чего состоит O-Cell? Давайте попробуем разобраться, что из себя представляет ячейка Остерберга конструктивно. Как мы уже выяснили в Части 1, O-Cell - это система гидравлических домкратов, интегрированная в тело испытуемой сваи. Очевидно, что главной составляющей ячейки является система гидравлических домкратов. Необходимо понимать, что эта система не универсальна, а проектируется индивидуально для каждой конкретной (иногда невыполнимой) задачи испытаний. Однако можно выделить некоторые общие требования, предъявляемые практически при любых испытаниях методом O-Cell: ✅Домкраты должны обеспечивать расчетное усилие, определенное проектом; ✅Домкраты должны быть откалиброваны с учетом требуемого диапазона нагрузок; ✅ Домкраты должны обеспечивать осевую симметрию нагружения; ✅ Домкраты в ячейке должны быть объединены в единую гидравлическую систему. Для исключения перекосов в ячейке давление в домкратах должно быть строго одинаковым на каждой ступени нагружения; ✅ Полный ход домкратов должен быть не менее ожидаемых перемещений обеих частей сваи (желательно с запасом); ✅Жесткость системы домкратов, должна быть достаточной для исключения любых внутренних деформаций в «конструкции» домкратов; ✅Геометрия домкратов должна позволять их разместить в теле сваи в нужном количестве. Здесь сделаю важную оговорку: проектирование системы домкратов производится совместными усилиями изготовителей домкратов, проектировщиков свай, а также испытательной организации. В результате их взаимодействия подбираются габариты, расположение и необходимое кол-во домкратов. Однако, как говорится, "Не едиными домкратами жива O-Cell"😁. Для корректного проведения такого типа испытаний требуется много вспомогательных элементов: 1. Гидравлическая обвязка – нужна для подачи давления на систему домкратов. Гидравлическая обвязка это: ➡️Маслопроводы высокого давления (они же РВД – рукава высокого давления, они же гидравлические линии😅) Соединяют систему домкратов с наземной маслостанцией – должны быть устойчивы к высокому давлению. ➡️Маслостанция. Источник гидравлического давления, который создаёт нагрузку на силовую ячейку. Располагается на поверхности земли. ➡️Манометры и датчики контроля давления. Манометры обычно устанавливаются на поверхности земли рядом с маслостанцией. Они подключены к гидравлической системе через специальные ответвления от РВД, что позволяет в режиме реального времени отслеживать давление в домкратах. Манометры должны быть предварительно откалиброваны и обеспечивать необходимую точность измерений. Иногда могут быть использованы электронные манометры, интегрированные в систему управления испытаниями. Датчики контроля давления могут располагаться как на поверхности, так и непосредственно в гидравлической системе. Например: ⚡️Датчики могут быть встроены в РВД или на выходе из маслостанции, фиксируя давление перед подачей в силовую ячейку. ⚡️В некоторых системах используются датчики для мониторинга давления в отдельных домкратах силовой ячейки, что позволяет контролировать равномерность распределения нагрузки. 2. Опорные стальные плиты – служат жесткими опорами для домкратов и передают нагрузку на бетон сваи. Проектирование таких плит - отдельный вид искусства. Нужно учесть все необходимые отверстия и при этом уместить все домкраты для создания испытательной нагрузки. Какие же отверстия мы должны учесть? 🔴Отверстия для бетонолитной трубы – кол-во таких отверстий зависит от определенного в ППР кол-ва бетонолитных труб (обычно 1 или 2 трубы); 🔴Отверстия для трубок гидравлических линий и (обычно в верхней опорной плите, но бывают исключения – расскажем в будущих постах); 🔴 Отверстия для УЗК свай; 🔴Отверстия для выхода бурового шлама в процессе бетонирования сваи; 🔴Отверстия для измерительных датчиков типа «стержень в трубе» (об этом подробнее расскажем в будущих постах) 🔴Отверстия для инъецирования пяты сваи (опционально) 3. Измерительная система Эта тема заслуживает отдельного поста – to be continued…

Вышли из салатной комы, чтобы рассказать о новом для нас методе испытаний свай – метод O-Cell. Часть 1. Что это такое и с чем его едят? Для начала давайте попробуем разобраться с «неймингом» Испытание свай методом O-Cell (англ. Osterberg Cell – ячейка Остерберга) – пожалуй самое популярное название, однако далеко не единственное: ➡️В ГОСТ 5686-2020 – «Двунаправленное испытание грунтов сваей» ➡️В ISO 22477-1 – «Bi-directional static load test» - можно перевести, как «Двунаправленное испытание статической нагрузкой» Также встречается: «Испытание свай методом погружных домкратов», «Испытание свай методом двухстороннего нагружения», «Испытание свай встроенным гидродомкратом» и еще примерно пяток похожих вариантов😅 Для удобства восприятия далее будем использовать наиболее популярный вариант, а именно «испытание свай методом O-Cell». Так что же это такое? Испытание свай методом O-Cell — это метод полевых статических испытаний, при котором в тело сваи на заданной глубине устанавливается гидравлическая ячейка, создающая двунаправленную нагрузку: ⬆️вверх — на сопротивление грунта по боковой поверхности сваи выше нагрузочного устройства; ⬇️вниз — на сопротивление грунта под нижним концом сваи и по боковой поверхности ниже нагрузочного устройства. Таким образом, верхняя часть сваи является упором для нижней части сваи и наоборот. В зависимости от задачи, поставленной проектировщиком и требуемого результата возможны различные конфигурации испытаний, в том числе с использованием двух гидравлических ячеек (но об этом поговорим в будущих постах) С чем его едят? Немного перефразирую: Есть ли какой-либо нормативный документ, регламентирующий такой вид испытаний свай? Если кратко - да, но без конкретики. В нормах РФ, а именно в ГОСТ 5686-2020 содержится только общая информация о данном методе испытаний. При этом данный метод не запрещен и может быть реализован по отдельной специально разработанной программе работ. В зарубежных нормах (найденных в открытых источниках) а именно ISO 22477-1 и ASTM D8169 содержится подробная информация о данном методе испытаний свай, имеются конкретные требования к схеме испытаний и к конструкции самой ячейки Остерберга. P. S. Как говорится "stay tuned" - в будущих постах попробуем разобраться с методом O-Cell поподробнее.

Друзья, год подходит к концу, а значит уже можно наконец-то выдохнуть и начинать вовсю планировать предстоящие выходные дни! В этом году наш коллектив созрел на этот паблик, где мы охотно делимся своим опытом и искренне радуемся, когда Вы откликаетесь и делитесь своим. Мы надеемся, что в будущем году мы объединим под "крышей" этого пространства еще больше единомышленников и специалистов своего дела. Важно помнить, что нам всем есть куда расти и вместе нам удастся прийти к успеху. На будущий год мы готовим много интересных материалов, в т.ч. про уникальные объекты, stay tuned! Мы поздравляем Вас с наступающими праздниками, желаем Вам в Новом году работать только с качественными отчетами ИГИ, красивыми КЭ-сетками и амбициозными задачами! Предлагаем всем собраться в кругу своего коллектива и подвести итоги уходящего года и поставить амбициозные цели на будущий! Теперь с чистой совестью мы отчаливаем на выходные. С уважением, коллектив энтузиастов ВГПК 🤎