От Павел Чайлик
К Alex~1
Дата 12.11.2009 21:12:35
Рубрики В стране и мире;

А что непонятного? :))



>>>Народ еще хвалит visualBasic или как он там теперь называется.
>>Да вот это тоже вариант, надо обсудить с коллегами
>
>>>Но, как обычно, кадры решают все - если кадры имеют опыт работы с Visual Fox, то проблем быть не должно.
>>
>>Некоторые имеют, а некоторые нет
>

>>!----------------------------------
>>Вообще, я посмотрел сеть, выяснил, что проклятые янки как всегда и на эту тему сказали и обобщили:
>>на общетеоретическом уровне
>> http://en.wikipedia.org/wiki/Rapid_application_development
>> и на практическом
>> http://en.wikipedia.org/wiki/List_of_rapid_application_development_tools
>
>Все это теоретическое/практическое великоление - фигня.
>1) Раз Microsoft со своим Excel - значит, тулзы должны быть Microsoft'овские.
>2) Дальнейшее роли не играет, просто смотришь, что умеют те люди, которые готовы взяться. Результат будет принципиально одинаковый.
>3) Ни фига не понял, при чем здесь SOAP, Web-сервсиы и прочая лабуда. :)

Ну, надо людям CV разукрасить. Стандартненько... :)))
У нас тут есть одна, как обычно, исторически сложившаяся программа, так она построена аж на CORBA и на Windows и к ней "пристроек" и примочек на всех технологиях какие только придумывались. Зато масса людей, поработав годик и пополнив свой CV, отправилась на поиски счастья по заграницам. :)))

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

А мне вот еще интересно (к Константину) что же там за формат представления электрических цепей и как и для чего надо эти схемы стыковать с Вашим приложением? Просто для удобства или для решения каких-то задач?
От Константин
К Павел Чайлик (12.11.2009 21:12:35)
Дата 12.11.2009 22:11:30

Re: А что...

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

>А мне вот еще интересно (к Константину) что же там за формат представления электрических цепей и как и для чего надо эти схемы стыковать с Вашим приложением? Просто для удобства или для решения каких-то задач?

Это графическое представление реальной высоковольной сети - от 10 кВ (у нас реально от 110 кВ) и выше. Минимальный набор изображений довольно простой - линии, шины подстанций или электростанций, генераторы, нагрузки, трансформаторы + ещё несколько устройств, например батареи конденсаторов.
В более развитых вариантах делают уже развёрнутые схемы подстанций и станций.
Всё это привязано к записям в БД о реальных объектах. С графического изображения менять параметры в БД. Наиболее типичное изменение - отключить линию и провести расчёт - посмотреть как измениться состояние сети. При расчётах на схему выводятся результатах, напряжения перетоки мощности и т.д.

Вот пример с одной из наиболее используемых в России программ, довольно старой кстати:


[99K]



!---------------------------------------
По моим наблюдениям - у нас более жизнеспособными оказываются проекты , которые сделаны попроще , побыстрее и меньшим числом людей.
От Кудинoв Игорь
К Константин (12.11.2009 22:11:30)
Дата 13.11.2009 00:03:38

в таком виде несложно прямо в фоксе отрисовать

>Это графическое представление реальной высоковольной сети - от 10 кВ (у нас реально от 110 кВ) и выше. Минимальный набор изображений довольно простой - линии, шины подстанций или электростанций, генераторы, нагрузки, трансформаторы + ещё несколько устройств, например батареи конденсаторов.

и в фоксе же обрабатывать. Красиво можно сделать... если хорошо продумать все эти MouseOver и MouseLeave.

>В более развитых вариантах делают уже развёрнутые схемы подстанций и станций.
>Всё это привязано к записям в БД о реальных объектах. С графического изображения менять параметры в БД.
да, обрабатывать правую мышь над каждым объектом, навешивая контекстное меню или показывая панель инструментов. Хотя нынешнее увлечение кнопками до добра не доводит - тут в одной приблуде без текстового меню лектору приходилось говорить "нажимаем белую руку", "нажимаем руку негра"... Описывать или вникать в такой интерфейс просто невозможно, особенно в ч/б документе .

>.... Наиболее типичное изменение - отключить линию и провести расчёт - посмотреть как измениться состояние сети. При расчётах на схему выводятся результатах, напряжения перетоки мощности и т.д.


>Вот пример с одной из наиболее используемых в России программ, довольно старой кстати:

>По моим наблюдениям - у нас более жизнеспособными оказываются проекты , которые сделаны попроще , побыстрее и меньшим числом людей.

да, попильные проекты изрядно отягощают обслуживание.
От Павел Чайлик
К Константин (12.11.2009 22:11:30)
Дата 12.11.2009 23:17:33

На чем помешан я...

>Насчёт CV - это да , была такая тенденция - потренироваться на местных проектах, сбить команду и постараться свалить за границу .

>>А мне вот еще интересно (к Константину) что же там за формат представления электрических цепей и как и для чего надо эти схемы стыковать с Вашим приложением? Просто для удобства или для решения каких-то задач?
>
>Это графическое представление реальной высоковольной сети - от 10 кВ (у нас реально от 110 кВ) и выше. Минимальный набор изображений довольно простой - линии, шины подстанций или электростанций, генераторы, нагрузки, трансформаторы + ещё несколько устройств, например батареи конденсаторов.
>В более развитых вариантах делают уже развёрнутые схемы подстанций и станций.
>Всё это привязано к записям в БД о реальных объектах. С графического изображения менять параметры в БД. Наиболее типичное изменение - отключить линию и провести расчёт - посмотреть как измениться состояние сети. При расчётах на схему выводятся результатах, напряжения перетоки мощности и т.д.

Ух... интересно. А в БД фактически граф?
Т.о. вы хотите моделировать все это дело? А движок ваш - это уравнения Кирхгофа в диф. форме? Я физику тут подзабыл малость, но в общем картину представляю. Вопрос, собственно вот в чем.
Насколько программа, которая, моделирование проводит ваша "родная" или тоже какая-то сторонняя приспособленная разработка? От этого зависят ваши возможности в выборе сценариев.
Например, можно все представить, для начала, как набор утилит или, чуть глубже, библиотек для конвертации форматов туда-сюда между БД и этими графическими (напишите о каких идет речь). Вот утилитки лучше всего строить (это я со своей колокольни) на xsl:fo. Мы тут внедрили открытый пакет FOP (на Java) с помощью которого можно писать шаблоны ("сценарии") такой вот конвертации. Диапазон возможностей весьма широкий. Пока используем его в отчетности (PDF,XML) и в генерации печатных форм документов в PDF.
Но общие возможности весьма широкие.

Если хотите сэкономить и добиться рабочего состояния за преемлемые сроки, то я рекомендую пойти именно по такому сценарию.
Вместо GUI на первоначальном этапе набор утилиток запускаемых с коммандной строки. Это я предлагаю с учетом того, что с приложением работает один (значить квалифицированный) пользователь и этот пользователь, похоже, инженер. Сами утилитки, тогда, есть просто написанные с использованием каких-то открытых бибилотек собственные библиотечки классов (пакеты Java или библиотеки C) и построенные на их основе элементарные конвертеры. Ковертер, если использовать xsl:fo, будет представлять собой простой процессор (могу помочь с его написанием), который трансформирует один набор данных (представленных в XML) в какой-то другой формат по правилу, описанному в шаблоне (обычно xsl-файл). Шаблон - текстовый файл. Редактировать удобно в массе свободных открытых редакторах со встроенной проверкой синтаксиса, а есть и со встроенными процессорами - сразу протестить процесс конвертации. Если заинтересует - подброшу ссылки по теме.
Ну, еще нужна утилитка экспортирующая данные из БД (нужный набор) в файл XML для дальнейшей трансформации.

Другой вопрос - это, собственно, ваша работа с БД.

Ну, а потом, если работы станет настолько много, что неудобно будет запускать последовательности скриптов из коммандной строки, задумаетесь на GUI, собрать которые на основе уже имеющихся утилит будет гораздо проще.

>Вот пример с одной из наиболее используемых в России программ, довольно старой кстати:

>
>[99K]


> !---------------------------------------
>По моим наблюдениям - у нас более жизнеспособными оказываются проекты , которые сделаны попроще , побыстрее и меньшим числом людей.

Ну, или проекты, на поддержку которых не жалеют средств :)))

А вообще, все зависит от того как меняется работа на предприятии. Если не очень, то можно долго работать на одном и том же и даже не самого лучшего качества. Там где все постоянно перестраивают проблем не изюежать.

З.Ы. Мне интересна ваша задача. Я все больше по другим делам.
От Константин
К Павел Чайлик (12.11.2009 23:17:33)
Дата 13.11.2009 12:12:39

Re: На чем

>
>
>Ух... интересно. А в БД фактически граф?
Ну да две таблицы Узлы (шины) и Ветви. Ветви (линии и трансформаторы) связывают узлы в сеть.
>Т.о. вы хотите моделировать все это дело? А движок ваш - это уравнения Кирхгофа в диф. форме?
Там свои уравнения - фактически закон Ома и первый закон Киргофа. Главная сложность в том, что задаются не источники ЭДС и тока , как в обычной электротехнике, а мощности. Из-за этого уравнения получаются нелинейными, а квадратичными (мощность это U на I). Но их давно умеют решать итерациями , например по методу Ньютона.
Дифференциальная форма там явно не используется, но в скрытом виде входит в поправки сопротивления длинных линий (длинные это скажем более 300-500 км)


>Насколько программа, которая, моделирование проводит ваша "родная" или тоже какая-то сторонняя приспособленная разработка? От этого зависят ваши возможности в выборе сценариев.
Программа расчёта полностью наша. Но она общается только с БД , через ODBC (так кажется это называется). Оболочка работает только с БД.

Про графику мне говорить трудно, это разработка моего соседа по комнате, я знаю что она есть :).
На утилитках , работающих из командной строки - не пойдёт. Такой товар точно не возьмут .


>>По моим наблюдениям - у нас более жизнеспособными оказываются проекты , которые сделаны попроще , побыстрее и меньшим числом людей.
>
>Ну, или проекты, на поддержку которых не жалеют средств :)))
Как показывает мой опыт последних лет, деньги необходимое, но отнюдь не достаточное условие успеха. И наличие квалифицированных программистов и технологов тоже.
Это отдельная история, можно как-нибудь обсудить .
От Павел Чайлик
К Константин (13.11.2009 12:12:39)
Дата 13.11.2009 12:48:07

Все интересатее и интересатее :)))

>>
>>
>>Ух... интересно. А в БД фактически граф?
>Ну да две таблицы Узлы (шины) и Ветви. Ветви (линии и трансформаторы) связывают узлы в сеть.

Понятно. Конкретная организация структуры данных не так и важна. Важно на первом этапе понять что за структура в основе.

>>Т.о. вы хотите моделировать все это дело? А движок ваш - это уравнения Кирхгофа в диф. форме?
>Там свои уравнения - фактически закон Ома и первый закон Киргофа. Главная сложность в том, что задаются не источники ЭДС и тока , как в обычной электротехнике, а мощности. Из-за этого уравнения получаются нелинейными, а квадратичными (мощность это U на I). Но их давно умеют решать итерациями , например по методу Ньютона.
>Дифференциальная форма там явно не используется, но в скрытом виде входит в поправки сопротивления длинных линий (длинные это скажем более 300-500 км)


>>Насколько программа, которая, моделирование проводит ваша "родная" или тоже какая-то сторонняя приспособленная разработка? От этого зависят ваши возможности в выборе сценариев.
>Программа расчёта полностью наша. Но она общается только с БД , через ODBC (так кажется это называется). Оболочка работает только с БД.

Ваша, это хорошо. Теперь как я это понял.
Надо:
Читать структуру сети в память (наверное целиком) и проводить некий рассчет с измененными параметрами. Т.е. необходимо создавать копии (проекты) энергосети (ЭС) и проводить с ним процесс "моделирования".
Эксперимент моделирования имеет результаты - набор получаемых характеристик, возможных пределов системы и параметров. Нужно хранить, пусть пока просто "где-то", как этот "экземпляр" ЭС так и результаты его "тестирования" - моделирования нагрузок и всяких "напастей".
Т.е. сами по себе отдельные экземпляры ЭС - изолированны.
Если все именно так, как я понял, и нет никакой дополнительной связи со статистическими данными работы реальных ЭС или они существуют в отдельных структурах (БД и прочее) и программах, то мне кажется, что гораздо удобнее хранить данные не в БД, а в файловой системе. Так как работа тут именно проектная.


>Про графику мне говорить трудно, это разработка моего соседа по комнате, я знаю что она есть :).
>На утилитках , работающих из командной строки - не пойдёт. Такой товар точно не возьмут .

Так это вы на продажу? :)
Я думал сами свои нужны решаете...



>>>По моим наблюдениям - у нас более жизнеспособными оказываются проекты , которые сделаны попроще , побыстрее и меньшим числом людей.
>>
>>Ну, или проекты, на поддержку которых не жалеют средств :)))
>Как показывает мой опыт последних лет, деньги необходимое, но отнюдь не достаточное условие успеха. И наличие квалифицированных программистов и технологов тоже.
>Это отдельная история, можно как-нибудь обсудить .

З.Ы. Стало настолько интересно, что хочу попросить Вас предоставить мне алгоритмы моделирования и структуры ЭС. Я бы поиграл с многопоточной их реализацией (на досуге развлекаюсь обработкой графов многопоточно на Java). Потом подкину Вам библиотеку (пакет). Многопоточно сейчас очень актуально, особенно после того, как можно вполне приобрести рабочую станцию, в которой напихано 4 и больше процессора. А на работе я для своего хобби выпросил себе эккаунт на 16-ти процессорном ящике, где радиоинженеры покрытие рассчитывают. По своему опыту знаю, что вся "старая" реализация математики однопоточная, что несколько удручает.
От Константин
К Павел Чайлик (13.11.2009 12:48:07)
Дата 13.11.2009 18:59:13

Re: Все интересатее...




>
>Ваша, это хорошо. Теперь как я это понял.
>Надо:
>Читать структуру сети в память (наверное целиком) и проводить некий рассчет с измененными параметрами. Т.е. необходимо создавать копии (проекты) энергосети (ЭС) и проводить с ним процесс "моделирования".
>Эксперимент моделирования имеет результаты - набор получаемых характеристик, возможных пределов системы и параметров. Нужно хранить, пусть пока просто "где-то", как этот "экземпляр" ЭС так и результаты его "тестирования" - моделирования нагрузок и всяких "напастей".
>Т.е. сами по себе отдельные экземпляры ЭС - изолированны.
>Если все именно так, как я понял, и нет никакой дополнительной связи со статистическими данными работы реальных ЭС или они существуют в отдельных структурах (БД и прочее) и программах, то мне кажется, что гораздо удобнее хранить данные не в БД, а в файловой системе. Так как работа тут именно проектная.

Да большинство таких программ работают на файлах, в одном случае - используют встроенную БД типа SQLite. В нашем случае переход на БД был вызван следующими обстоятельствами.
1. В программу входил (сейчас уже нет) модуль для работы с телеизмерениями в сети,
2. Планировалась интеграция с БД оборудования. Т.е. не вводить ветку и её сопротивления, а запрашивается параметры скажем воздушной линии длина , марка провода и т.д.
3. Планировалось использовать программу прогнозирования потребления электроэнергии, работающую на статистическом материале.

Т.е. к БД перешли в расчёте на существенное расширение программы.


>Так это вы на продажу? :)
>Я думал сами свои нужны решаете...

Для своих задач вполне хватает, что есть.


>З.Ы. Стало настолько интересно, что хочу попросить Вас предоставить мне алгоритмы моделирования и структуры ЭС. Я бы поиграл с многопоточной их реализацией (на досуге развлекаюсь обработкой графов многопоточно на Java). Потом подкину Вам библиотеку (пакет). Многопоточно сейчас очень актуально, особенно после того, как можно вполне приобрести рабочую станцию, в которой напихано 4 и больше процессора. А на работе я для своего хобби выпросил себе эккаунт на 16-ти процессорном ящике, где радиоинженеры покрытие рассчитывают. По своему опыту знаю, что вся "старая" реализация математики однопоточная, что несколько удручает.

Если кратко, то в тех задачах, что мы делаем сейчас скорость расчётов отнюдь не главная проблема.

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

Параллелизацией таких задач занимались и занимаются. Я посмотрю , что есть на этот счёт .
Задача состоит в многократном решении относительно больших (ну скажем 3-10 тысяч переменных) систем линейных уравнений, при слабозаполненности матриц. Там варианта , как мне представляется два. Можно одну систему решать параллельно. Или правильно распределить всю работу между процессорами если нужно перебрать 1000 вариантов , то поставить перебор так , что на одной 500 и на другой 500.