mikekaganski (Все сообщения пользователя)

<blockquote>Цитата:<hr size="1" noshade><i>После того, как мы задали эти местные изменения высот, и перерассчитали, появились незначительные потери напора, давления,расхода в этой точке.</i><hr size="1" noshade></blockquote>Пожалуйста, не вводите людей в заблуждение!
В верхней точке компенсатора действительно давление будет на соответствующую величину ниже. Зато после опуска оно снова станет на соответствующую величину выше. Собственно подъём и последующий опуск на гидравлику _не влияют_!
А вот отводы влияют. И задвижки. И длина труб тоже влияет. Поэтому результат будет правильным не тогда, когда Вы понаделаете локальных подъёмов-опусков, а когда Вы учтёте коэффициенты местных сопротивлений всей арматуры, фиттингов и _длины_ всех опусков-подъёмов.

Геодезическая отметка спинки П-образника может иметь значение только для определения требуемого напора для заполнения трубопровода. После заполнения она не влияет ни на что. А учесть влияние на гидравлику целого сооружения под названием "П-образный компенсатор" можно, задав в свойствах участка сумму местных сопротивлений (ну, или для наглядности поставив условно в точку его расположения "локальное сопротивление" с соответствующими данными).

<B>gooreloov</B>,

Это было бы необходимо, если бы у Вас после подъёма не было опуска на прежний уровень. А так гравитационные силы от перепада высот в этом месте взаимокомпенсируются.

Хотя в теплосетях для статики это имеет значение. В этом случае я бы поставил в месте такого компенсатора один узел, и задал ему статический напор, исходя из верхней точки.

И было бы неплохо иметь возможность видеть такие штуки на пьезометре.

Удачи Вам в новом году, и успехов в работе и дома!
Вообще всего самого наилучшего коллективу, делающему хорошую программу и оказывающему наилучшую техподдержку!

<blockquote>Цитата:<hr size="1" noshade><i>1. @"C:\Zu\Layer1" используется для того чтобы символ "\" в пути файла (который является служебным в тексте, например \n переносит последующий текст на новую строку) а символ "@" перед текстом отключает восприятие "\" как служебного символа.</i><hr size="1" noshade></blockquote>Как вариант, можно просто использовать "/" вместо "\".

Можно ещё установить виртуальный принтер (например, CutePDF Writer, PDFill, MS XPS) и напечатать на него. А потом распечатать полученный файл в агентстве

Спасибо.

Спасибо.

Но ведь при этом не получится сделать это для _группы_? (Т.е. и присвоение, и сумма должны ограничиваться выделенными объектами.) Или я не прав?

Здравствуйте.

Есть ли возможность выполнить запрос на присвоение нового значения типа "CHANGETO 123*Fx/{SUM Fx}", где Fx - поле, отичное от того, которому производится присвоение? Так удобно назначать группе участков путевые расходы пропорционально отношению длин каждого из них к общей длине группы.

Если этой возможности нет, нельзя ли это реализовать? Скажем, с использованием специального синтаксиса (фигурные или квадратные скобки), который говорил бы системе сначала выполнить подзапрос и его результат подставить на это место?

Здравствуйте.
Версия 7.0.0.4617
1. Во вновь созданной сети задвижка в режиме "выключен" имеет состояние "Включён".
2. Возможно, это не специфично для модуля Газ, не проверял. В настройке конфигурации пьезометрического графика, Таблица -> <элемент> -> Объекты формулы считаются некоректно в зависимости от порядка множителей:
field("dPfact")*1000/field("len")
считается корректно, а
field("dPfact")/field("len")*1000
считается неправильно, как если бы было написано
field("dPfact")/(field("len")*1000)
3. Не знаю, есть ли альтернативный метод, но прямой ввод в названии графика символа "в третьей степени" (U+00B3: Superscript Three) приводит к появлению вместо него вопросительного знака, хотя шрифт Arial (по крайней мере у меня в системе) содержит соответствующий глиф. Это, случайно, не использование для текстов 8-битной кодировки?

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

При работе с инструментом "Поиск пути" есть возможность "Добавить в группу" объекты, подсвеченные в настоящий момент. Однако эта операция, несмотря на своё название, не модифицирует, а заменяет существующую группу.
Было бы здорово переименовать существующую команду (варианты: "Выделить в группу", "Выбрать в группу") и добавить новую команду, которая как раз бы и называлась "Добавить в группу".

При поверочном расчёте с учётом утечек из систем теплопотребления и при использовании обобщённых потребителей в окне сообщений расчёта результаты расчёта выводятся так:

Источник ID=NNNN ABCD:
   Количество тепла, вырабатываемое на источнике за ч.        234.653, Гкал/ч
   Расход тепла на обобщенных потребителях                    174.298, Гкал/ч
   Расход тепла на водоразбор на обобщенных потребителях       36.292, Гкал/ч
   Потери тепла от утечек в подающем тр-де                     17.754, Гкал/ч
   Потери тепла от утечек в обратном тр-де                      6.309, Гкал/ч
...

При этом в строке "Расход тепла на водоразбор на обобщенных потребителях" объединены собственно водоразбор и утечки из потребительских систем.
Можно ли разнести эти значения в разные строки?

Версия 7.0.0.4603
При задании у ПНС "Способ задания насоса на подающем" = "Давление после насоса" и введённом "Напор после насоса на подающем, м" поверочный расчёт зависает:

************************************************************
* ZuluThermo 7.0.0.4603
* Поверочный расчет сети "Хабаровск"
* Сопла и шайбы фактически установленные
* Диаметры фактически установленные
* Не учитывать неравномерность потребления горячей воды
* С учетом утечек
* Без учета тепловых потерь
* Минимальный диаметр сопла 3.0 мм
* Минимальный диаметр шайбы 3.0 мм
* Температура полки 70.0 °C
* Не включать в расчет тупики без нагрузки
* Формула для расчета коэффициента гидравлического трения: Альтшуля
* Плотность теплоносителя в подающем: 0.975 т/м3
* Плотность теплоносителя в подающем: 0.975 т/м3
* Точность по расходам: 0.00100 т/час
* Точность по температурам: 0.05000 °C
************************************************************
Анализ топологии...
--------- Поверочный расчет тепловой сети от источника: ID=1080 ---------
Кодировка сети...
Чтение данных по источникам...
Чтение данных по обобщенным потребителям...
Чтение данных по потребителям...
Чтение данных по участкам...
Чтение данных по насосам...
Чтение данных по камерам...
Чтение данных по задвижкам...
Расчет потокораспределения #1...
Узлов 522   Участков 521  Циклов 0

При этом попытка прервать расчёт приводит только к появлению ещё одной строки - "Прерывание расчета...".

Интерфейс работает, но выйти из программы корректно не получается - "Идет расчет!"

Прошу прощения за пост в этом форуме, к сожалению, нет форума для газа.

При незаполненном поле участка "Диаметр внутренний, м" (и при заполненном поле "Шероховатость трубопровода, мм") поверочный расчёт выдаёт сообщение
"Ошибка ZD004: ID=X Неверное значение поля 'ke'-'Шероховатость трубопровода, мм'".

Спасибо, работает.

Ситуация: карта в проекции Сферический Меркатор WGS84; в ней 2 слоя: один также в проекции Сферический Меркатор WGS84 (tile-сервер), другой - в заданной вручную (Поперечная Меркатора (Гаусса-Крюгера); Pulkovo 1942 Russia; подобранные центральный меридиан и смещения для посадки местной системы координат на глобус), на который нанесены границы города.

При выполнении экспорта в BMP или при печати в границах слоя города выводится "пустота". Выглядит это так, как будто выводится часть глобуса, у которой _в проекции Сферический Меркатор WGS84_ координаты такие, как у города в _местной СК_ (т.е. где-то в Атлантике). При этом, если выполнить операцию кэширования в границах того же слоя, то кэш создаётся корректно (т.е. из нужного участка на глобусе).

Это я что-то делаю неправильно, или ошибка в программе?

Удачного отпуска!

А можно ли убирать из главного окна панели прокрутки? Пользы от них никакой, за исключением, пожалуй, наличия хваталок для разбиения экрана. Но эта функциональность есть в меню (и, возможно, её можно было бы организовать как-то альтернативно, без привязки к прокрутке), так что опция по скрытию этих панелей была бы приятной мелочью.

<B>Lyosha</B>,
Заранее прошу прощения, если повторяю то, чем кто-то уже Вам надоел. Я понимаю, что эта функциональность может иметь крайне низкий приоритет, но хочу подчеркнуть её целесообразность (т.е. то, что она, несмотря на любой приоритет, всё же имеет смысл).

Что касается реального видения картины: это зависит от схемы. На очень больших схемах, наоборот, исключение второстепенных (с точки зрения восприятия, а не с точки зрения расчёта) деталей может прояснить картину. Вы же, несомненно, знакомы с одним из основных методов проектирования ПО - ООП, который предполагает абстракцию и скрытие деталей реализации на более низких уровнях системы, что не только не усложняет, но и, наоборот, облегчает анализ модели (которой является программа). Да и при любых других современных парадигмах используются подобные объединения - функция является одним из них.

Насчёт только тех обвязок, которые существенны: при вариантном проектировании приходится вносить много деталей, каждая из которых может быть задействована лишь в части вариантов, а в других быть "мусором", однако проще именно переключать режимы узлов/участков (закрыто/открыто), чем постоянно создавать/удалять узлы (и, соответственно, участки) и заносить соответствующую семантику.

Кроме того, уж если делать такую возможность, то она должна быть именно возможностью, т.е. использоваться только тогда, когда нужна, и только теми, кому нужна. Это ведь не требование, чтобы все схемы строились именно так! Поэтому затруднение ввода данных не может быть доводом: кому преимущества будут перевешивать неудобства, тот и будет этим пользоваться, а остальные не будут затронуты.

Насчёт пьезометра. Скрытие столбцов вручную, несомненно, должно быть. Но возможность группировки нескольких элементов в один на схеме позволило бы сделать часть работы (или даже во многих случаях всё) автоматически, что исключило бы необходимость в ручной обработке пьезометра каждый раз, как понадобится его построить по данной схеме. А так придётся <B>каждый раз (!)</B> скрывать <B>одни и те же</B> столбцы. Я полагаю, что в случае эксплуатации построение пьезометра по одному и тому же участку (с изменившимися данными) должно быть обычным явлением.

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

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

Нельзя ли добавить возможность объединять узлы схемы в более крупные мета-узлы?

Конкретнее: хотелось бы иметь возможность объединить в камере разветвление и несколько задвижек с перемычками, или в насосной собственно насосы и задвижки с перемычками, чтобы эти объединения:
1. на схеме выглядели как один узел, не загромождая схему, и раскрывались только при необходимости (редактирование) либо при некоем достаточно крупном масштабе;
2. не загромождали пьезометр, поскольку принадлежат одному логическому узлу.

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

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

Можно ли как-то определять свою систему координат, например, задавая свой произвольный датум (отсутствующий в списке предопределённых), например, по параметрам, приведённым на http://www.mapbasic.ru/msksolutions? И можно ли существующий план, созданный в системе координат "Местная прямоугольная, План-схема, Без датума" перевести в такую систему и отобразить поверх, скажем, OpenStreetMap?

Речь идёт как раз о магистральных трубопроводах.

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

Будет ли предложенный Вами способ адекватным для этого случая?