Форум режимщиков

Цитата:

Цитата: Проект моделирования режимной автоматики есть, работа в этом направлении ведется, результат возможен к концу этого года. (если не начнется очередной рынок )Что касается блока СА, то в хотелках СО его никогда не значилось, разве что в ЦПА, но это совсем другая история. Проект есть - здорово, потому что в " http://regimov.net/po/rastr/future2007.html "  этого нет.А то что в хотелках чего-то не было - плохо, т.к. я свои предложения по ПА давал. Мне хочется выбирать допустимые перетоки соблюдая все требования МУ по устойчивости, где сказано что я должен учитывать работу ПА! А вот инструмента нету, впрочем как и инструмента для расчета динамики. Что касается СА, то для начала нужно определиться кто что под этим понимет, т.к. такого определения нигде нет (по крайней мере мне не известно где есть). Если под этим понимать сисемы АРЧМ, АРВ, FACTS, управляемые реакторы, компенсаторы и другие автоматические устройства регулирования напряжения и перетоков мощности (вопрос какие?), то это одно, а если АЧР, АЛАР или вообще какие-нить АПВ, АВР, УРОВ? Было бы неплохо если при утяжелении режим автоматически корректировался с учетом систем регулирования частоты, напряжения и перетоков мощности, а анализ ражима предлагал включить или отключить реактор, БСК, устранить перегрузку ВЛ,Тр-ров путем деления или загрузки/разгрузки генераторов на N МВт. Ну и верх совершенства - это если бы программа позволяла эти самые мероприятия сделать автоматически.

Согласен, что нужна достаточно чёткая нормативная база и по терминам и по методикам. Частично она существует, особенно по вопросам устойчивости. А вот, что касается вопросов превентивного моделирования возможных аварий - тут вариантов не так много, мягко говоря.  :(В основном эти вопросы сейчас решаются на основании квалификации режимного персонала, который, как правило, ограничен по времени, а значит и по числу анализируемых вариантов. Про учёт возможных отказов ПАА я уже не говорю. :(То что нужна дифференциация по системам управления и ПАА - это очевидно. Учёт средств регулирования и ПАА при утяжелениии - мысль интересная.   :roll: В АНАРЭС в одиночном расчёте или в цикле надёжности - ПАА и регулирование можно учитывать, а вот при утяжелении почему-то не пробовали даже. Просто не додумались.   Проверим. М.б. там всё автоматом работать будет (а может и нет)? Там на шаге утяжеления в принципе идёт расчёт одиночного УР. Вроде теоретически тогда и в утяжелении регуляторы и ПАА должны подцепляться. В бижайшее время посмотрим и доложим результат.Что касается автоматизации выбора дозировок УВ как на уровне коммутаций силовых элементов сети так и изменения нагрузки/генерации - это пока наша тоже "голубая" мечта. Но не такая уж и далёкая.

Перед тем как разработчики начнут договариваться о важнейшем вопросе стандартизации ПО на современном этапе, хорошо было бы ведущим технологам СО определиться с тем, как мы видим построение схем замещения.Думается пора заканчивать со схемами  "для обработки кз", "для динамики", "для Космоса", "для ОИКа", "для торгов" и т.п. По-моему современный уровень компьютерной техники уже давно позволяет обходиться без ненужного эквивалентирования.  Схема должна быть единой и иерархически цельной. Дальше высказываю свое видение:1) первичной остается схема энергосистемы. В ней должны присутствовать все линии и трансформаторы классом 110 кВ и выше в явном неэквивалентированном виде;2) к узлу могут быть отнесены N-нагрузок, М-генераторов; интерфейс пользователя должен позволять увидеть как списочный состав отнесенных нагрузок и генераторов, так и их суммы; c помощью таких узлов формируются коммутационные схемы и данные для динамики; Для схемы энергосистемы достаточно K<=999 узлов.3) на уровне ОДУ никаких эквивалентирований не проводится, перенумерация не производится, "ключ" узла: номер района (L<=99)+K; Выполняется синтез энергообъединения.4) на уровне ЦДУ эквивалентирование не проводится; ключ узла аналогично п.3 На всех уровнях во всех схемах остается одинаковая нумерация "укрупненных узлов" п.2

Цитата:

Перед тем как разработчики начнут договариваться о важнейшем вопросе стандартизации ПО на современном этапе, хорошо было бы ведущим технологам СО определиться с тем, как мы видим построение схем замещения.Думается пора заканчивать со схемами  "для обработки кз", "для динамики", "для Космоса", "для ОИКа", "для торгов" и т.п. По-моему современный уровень компьютерной техники уже давно позволяет обходиться без ненужного эквивалентирования.  Схема должна быть единой и иерархически цельной. Дальше высказываю свое видение:1) первичной остается схема энергосистемы. В ней должны присутствовать все линии и трансформаторы классом 110 кВ и выше в явном неэквивалентированном виде;2) к узлу могут быть отнесены N-нагрузок, М-генераторов; интерфейс пользователя должен позволять увидеть как списочный состав отнесенных нагрузок и генераторов, так и их суммы; c помощью таких узлов формируются коммутационные схемы и данные для динамики; Для схемы энергосистемы достаточно K<=999 узлов.3) на уровне ОДУ никаких эквивалентирований не проводится, перенумерация не производится, "ключ" узла: номер района (L<=99)+K; Выполняется синтез энергообъединения.4) на уровне ЦДУ эквивалентирование не проводится; ключ узла аналогично п.3 На всех уровнях во всех схемах остается одинаковая нумерация "укрупненных узлов" п.2

Теоретически можно детализировать схему до уровня конечного заметного электропотребителя (модель эл.двигателя и др.) и даже бытового электроприбора (например утюга и т.п.). И &nbsp;выполнять расчёт этой мультимиллиардной схемы. Дело не в мощности компьютеров, а в погрешности исходной информации. Эквивалентирование значительно снимает эту проблему. Когда на верхний уровень стекаются сокращённые, но более менее сбалансированные по режиму схемы - снимается много проблем. Кроме этого вопрос наглядности. Представьте себе, что СО будет видеть "режим утюга". ;DКроме этого на разных уровнях иерархии решаются просто очень разные задачи и они требуют разных моделей эл.сети. На одних уровнях - более точных в деталях, на других точных в обобщённом понимании и т.д.Тезис 1) - а почему 35 забыли? Они иногда (редко) тянут не меньше, чем некоторые 110.Тезис 2) - предлагается частный случай модели узла с ограничениями по размерности схемы в терминологии расчётных схем (почему 999? А может 666?) ;D. В терминологии схем РУ это уже давно реализовано в некоторых Российских программах.Тезис 3) - это один из вариантов перенумерации (по сути). Можно предложить ещё 100 не менее удачных.Тезис 4) - аналогично 3).Непонятно, а чем так эквивалентирование достало? Иногда это очень полезная задача

Цитата:

Представьте себе, что СО будет видеть "режим утюга". а почему 35 забыли? Они иногда (редко) тянут не меньше, чем некоторые 110.Непонятно, а чем так эквивалентирование достало? Иногда это очень полезная задача

"Достало" не эквивалентирование, а как было написано множество разных схем в разных нумерациях.Предлагается подход приводящей к единой схеме для всех нужных в СО задач. При таком подходе значительно экономится время технологов на разработку схем."Режим утюга" и 35 кВ не нужны, естественно сделать определенные допущения.Ничего "революционного" я тут и не предлагаю. Чисто системно организационные мероприятия.Также важно, в добавление к моему предыдущему посту-это разработка единого интерфейса для всех программ.Зачем каждому из разработчиков писать свой интерфейс и тратить на это время ?Интерфейс должен быть единым, для него в качестве прототипа можно использовать один из наиболеехорошо разработанных (ИМХО желательно RASTR). А разработчики сконцентрируются на специализированныхалгоритмах своих ПО.

[quote]

Цитата:

Также важно, в добавление к моему предыдущему посту-это разработка единого интерфейса для всех программ.Зачем каждому из разработчиков писать свой интерфейс и тратить на это время ?Интерфейс должен быть единым, для него в качестве прототипа можно использовать один из наиболеехорошо разработанных (ИМХО желательно RASTR). А разработчики сконцентрируются на специализированныхалгоритмах своих ПО.

Если речь идёт о пользовательском интерфейсе (к обмену между разными приложениями это не относится), то разработка единого для всех интерфейса скорее всего не нужна, так как у разных людей разные представления об удобстве интерфейса. Думаю, что некоторое разнообразие никогда не вредно. Другое дело - общие принципы построения интерфейса. Похоже, что кроме КОСМОС, пользовательские интерфейсы основных программы построены на принципах Windows. При работе с таблицами примерно всё похоже. Графика - другое дело. Но все графики сами по себе принципиально разные. Одни упрощённые, другие сложнее, третьи ещё сложнее и универсальнее. Они и задачи поэтому разные могут решать. Поэтому общий интерфейс здесь опять-таки проблематичен. Я считаю, что должен быть выбор у пользователя по вопросу интерфейса. &nbsp;;). А лучше всего иметь несколько вариантов программ (при условии адекватности решений основных задач), которые могут обмениваться между собой. И каждый выберет себе по вкусу . Вообще, на самом деле, программисты на пользовательском интерфейсе "отдыхают", потому, что есть гораздо более сложные задачи - это математика, обмены данными, синхронизация, управление и много ещё т.п..

Цитата:

Также важно, в добавление к моему предыдущему посту-это разработка единого интерфейса для всех программ.Зачем каждому из разработчиков писать свой интерфейс и тратить на это время ?Интерфейс должен быть единым, для него в качестве прототипа можно использовать один из наиболеехорошо разработанных (ИМХО желательно RASTR). А разработчики сконцентрируются на специализированныхалгоритмах своих ПО.

NW, тебе сюда http://regimov.net/forum/YaBB.pl?num=1162443185/10#10

Цитата:

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

Это заметно.Растр с переходом на Windows утратил часть функциональности, зато прибавил в интерфейсе...Космос - ну тут математика впереди планеты всей, с интерфейсом извините, как получается...Анарэс - не знаю, не работал.

Еще в тему:

Цитата:

Еще в тему:

УЖОС!

Цитата:

Еще в тему:

Ну и чего?Уже дял всех филиалов (почти) куплен ОИК СК-200Х, там есть Топаз - говорят, очень неплохая вещь.Я рисовал - мне не понравилось.