~<Krab>~ писал(а) Tue, 15 December 2009 21:13 |
SinAlbert для начала давай определимся для кого именно пишем, во вторых надо определиться что на входе и какие точно условия ведь я думаю приорететы у линий тоже есть толи пускать сначала 500 а потом 110 или наоборот, разница есть??? я думаю есть, третье запланированные ремонты (в годовом графике) они не могут "переезжать" правильно я понимаю??. пока я думаю и трех хватит вот когда будут внятные объяснения по этим хотя бы трем вопросам то можно будет продолжить работу над проектом такого плана.. а не полагаться на интуицию и все остальное.. |
А какая разница для кого, алгоритм должен работать на всех уровнях. Если у тебя получится программа, которая оптимизирует только по трем-четырем условиям, то мне, например, она не подойдет (также может не подойти и другим РДУ, все зависит от от особенностей схемы ЭС). Несколькими постами выше я наглядно разбирал этапы формирования годового графика, какие условия и т.д.
Еще раз на пальцах что у меня получалось: задаю теже 3 ограничения - в результате все несовместимости переносятся на январь-апрель и декабрь. Но в апреле у нас паводок => для всех транзитов и их шунтов, участвующих в выдаче мощности ГЭС, задаю ограничения с апреля по июнь. В результате прога их опять же двигает на зиму ( а куда еще? весна - паводок, лето и осень - ремонтная компания с кучей несовместимостей). Но имея опыт работы в сетевом предприятии, я прекрасно понимаю, что в этот период ремонт данной ВЛ и не только данной ВЛ не может быть выполнен (сдесь и низкие температуры, и заснеженные зимой и раскисшие весной поля, по которым техника к ВЛ не подойдет и т.д.). Задаю ограничения на ремонт ВЛ зимой - и все, в худщем случае висяк, в лучшем выдается инфа типа "Не могу разнести ремонт ... Задайте период ремонта вручную".
Вот сдесь уже начинаются звонки в сетевые организации и соместный поиск приемлемых решений (типа разбить ремонт на несколько частей или вместо одного длинного срока ремонта заложить в график это оборудование три раза но с меньшим сроком, чтоб "воткнуть" между несовместимых ремонтов).
~<Krab>~ писал(а) Tue, 15 December 2009 21:13 |
... ведь в любом случае есть какой то алгоритм решения этой проблемы где то в голове, просто его надо перенести на машину(да и эти условия не такие уж и сложные)... |
В том и дело, что ты рассуждаещь как теоретик, я же в реалиях пытался это сделать. Да, при двух-трех ограничениях все работает, проблемы начинаются когда закладываешь все реальные ограничения, которые необходимо учитывать.
~<Krab>~ писал(а) Tue, 15 December 2009 21:13 |
... мысль конечно есть объединить все РДУ с общей базай на SQL сервере, но есть ли уверенность что у каждого РДУ, ОДУ и так далее есть нормальный канал ineta? при помощи SQL и одной машины можно уже сделать что то похожее на правду, так как там уже можно сделать что то наподобие сводной проверочной таблицы(в базе) что бы мы уже представляли что двигать будут РДУ после ОДУ не попадая с ними в конфликт... |
Все эти SQL, серверы, каналы ineta, это все "примочки". Отбрось все лишнее, не распыляйся, есть задача оптимизировать ремонты - надо ее решить (написать рабочий алгоритм) в первую очередь, остальное потом.
Я от всей души (поверь, говорю серьезно) желаю тебе удачи. Если все получится, то многие люди тебе спасибо скажут, да и денежку заплатят. Ну а дальнейшее обсуждение, наверное, надо приостановить до получениях каких-либо практических результатов.
P.S. Кстати, была у меня мысль заложить приоритет оптимизации (какие ремонты обязательно надо разнести и в ущерб каким). Попробуй, на мой взгляд, это более реально.