Низкопотенциальное - означает маленькую разницу температур теплоносителя на входе и на выходе. Например, датацентр производит много воздуха нагретого до 45-50 градусов. Или воды нагретой до 40. Забирать теплоноситель из водяного контура крайне нежелательно. Много денег порачено на водоподготовку, да и токсичный он. А использовать теплоноситель такой низкой температуры сложно, транспортировать такое тепло дорого.
О результатах конкурса почитать уже нигде. Это внутренний конкурс и в интернет эти данные никогда не попадали. Да и внутри корпорации эти документы скорее всего уже канули в лету, 14 лет прошло как никак.
С датацентра тепло идет низкопотенциальное (т.е. невысокой температуры). В 2011 Майкрософт проводил внутренний конкурс проектов куда это тепло можно пристроить. Никто не победил. Но идея про подвалы в принципе годная. т.к. транспортировать такое тепло далеко не надо.
Не нужно греть дом старыми телевизорами! У меня домашний десктоп неспроста имеет БП 1000 Вт мощности. Да и сервер числомолотилка легко скушает 1 кВт, а потом отдаст вам его в качестве отопления. При этом он еще и радостно будет рендерить видео, или распознавать объекты на снимках.
Можно перестать постоянно выключать свет и вообще экономить на освещении. Для большого дома это сотни ватт постоянно.
Нет конечно! Просто добавьте в список другие средства разработки. Например Visual Studio 2018, PyCharm. И сразу будет заметно, что можно сделать сильно эффективнее без сжирания всей доступной памяти в одно перекормленное лицо.
"Приличное моделирование" должно воспроизводить "неоднородности нейтронного поля на малой мощности" и "неустойчивость реактора в режимах малой мощности и активной работы стежнями СУЗ". Это критерий "приличности" с моей точки зрения. Какова потребная сложность модели? Видимо с точностью по ТВЭЛа, либо с точностью до кассеты (как минимум). По высоте активную зону придется разбивать на ячейки размером сравнимым с размер графитового наконечника срежня регулирования (точно не менее 100 ячеек по высоте). Т.е. активную зону моделировать как 1693 * 100 = 169300 независимых тепловыделяющих сборки (с точностью до кассеты). Либо как 1693 * 18 * 100 = 3047400 независимых тепловыделяющих элемента (с точностью до ТВЭЛа). Плюс каналы (и паросодержание в каждом), плюс положение каждого стержня регулирования. Итого расход памяти на такую модель от миллиона до первых десятков миллионов числовых параметров.
Теперь смотрим на упоминаемую машину М-200 как типичного представителя ЦВМ того времени:
ОЗУ от 4 до 16 тысяч 47-битных слов,
Накопители на магнитном барабане объёмом от 24 до 65 тысяч слов.
Накопитель на магнитной ленте (4 блока) ёмкостью от 4 до 16 миллионов слов
производительность — до 27000 оп/сек И видим, что как сову не натягивай, а нехватка по памяти полтора порядка даже при использовании магнитных барабанов. По производительности тоже все очень плохо. Расчет будет идти со скоростью несколько минут (десятков минут) на один шаг по времени. Т.е. на просчет одного режима уйдут недели и месяцы машинного времени в режиме монопольного использования ЦВМ. А режимов десятки.
Вот я и говорю, что "теми средствами" реалистичную модель было непотянуть. В 80-е что-то моделировать стало возможно. Но к тому времени проект был успешно сдан и снова тратить месяцы и годы на моделирование никто бы не дал.
Очевидно, что сложность модели сильно (О(h^3)) зависит от физических размеров активной зоны. Из-за этого ВВЭРы моделировать проще, а результат выходит точнее.
Печаль - тоска в том, что забывают/игнорируют сценарии реально тяжелого использования. А на них вся эта Electron'ная чухня дохнет, сожрав предварительно всю память. Если у тебя проект на несколько MLOC и ты открываешь по паре сотен файлов одновременно, сколько инстансов IDE ты можешь запустить одновременно? А ведь надо иногда! В том же Хроме 2 меня тоже больше сотни вкладок открыто одновременно. Так для удобства приходится 5 инстансов Хрома запускать. И что? Он же сссамка собаки течет и падает. А ведь когда-то это было нормальным сценарием и все работало! Вкладки в браузере в 3-4 ряда и нормально. Что-то недочитал, недоделал можно было вкладку оставить открытой и не бояться что браузер рухнет и потеряет контекст. Про падения VS вообще никто не думал что так бывает. А сейчас приложений на JS наклепали, да только они работают по сценарию "строго 1 инстанс, не более 5 файлов разом, раз в день рестартуем ибо течет сильно". Как будто при профессиональном использовании кроме этого приложения человек ничем не пользуется и больше на машине ничего не запускает!
Все электричество которое вы потребляете в доме в конечном итоге превращается в тепло. Поэтому гонять электрообогреватель идея изначально дурная. Нужно гонять оборудование, которое попутно производит что-то еще полезное. Компы которые майнят крипту, обучают нейросетки, обрабатывают видео, хостят что угодно. Телевизоры, освещение - да что угодно, только не тупые электрообогреватели. В содержании датацентров самое дорогое это не железо, а оплата счетов за электричество. Тут можно иметь и отопление, и национальную сеть по хостингу видео/распознанию образов/расчету фолдинга белков. И все это примерно за одни и те-же деньги.
Ну тут вот товарищ выше пишет, что теперь падает. Либо за последние 4 года начала, либо у него какой-то "особенный" плагин добавлен. Плагины и раньше могли Студию уронить, или всю память сожрать.
Так она раньше не падала. Я даже больше скажу. Она и месяцами работала стабильно, я на ночь ее и не закрывал. Раз в месяц приходили патчи и машина перезагружалась. А остальное время VS перезапускать и не приходилось. А еще у меня в ней по 200 файлов было открыто. И иногда я мог несколько экземпляров VS открыть для разных проектов. И все это прекрасно работало.
Да в том то и дело, что было не "планомерное снижение мощности", а была "игра мощностью вверх-вниз и долгая работа на половинной мощности". Это и загнало реактор в нестабильный режим ксенонового отравления. В этому добавилось желание провести эксперимент "во что бы ни стало", и регулирование без хорошего понимания процессов в реакторе. В конструкции реактора были недостатки как в системе регулирования - "положительная обратная связь" ака "положительная реактивность", так и в системе контроля - "параметры критически важные для работы на малой мощности на пульте не отображались".
Но это обычная история, что любая катастрофа это всегда сочетание многих факторов. И не будь любого, аварии бы не было.
Такой запас регулирования мог понадобится по мере выгорания топлива. То что не было аппаратных ограничений на поднятие всех стержней - да, косяк проектировщика. Хотя не факт что тогдашняя техника позволила бы такое ограничение качественно реализовать.
Хотя педаль газа на авто тоже можно выжать "до упора", и часто такое кончится плохо (дождь, снег). Но иногда такой запас "по газу" может понадобится. Вот педаль и сделали такой. С реактором ситуация похожа.
Один вариант - просто плохо посчитали (кибернетика - буржуазная девка. Есть интервью одного тогда (в начале 1970-х) молодого-наглого студента, который пытался РБМК просчитать на компьютере - и в результате его с волчьим билетом выпнули из проекта. Но - интервью то отдаёт сильной дартаньянистостью
Это даже не вариант. Это факт который всеми признается. Для приличного моделирования такого реактора в 60-х просто не существовало технических средств. Тот-же МКЭ требует слишком много памяти и вычислительных операций чтоб реалистично моделировать локальные эффекты на такой громадине. И это не было исключительно советской проблемой. Постфактум же все стали дартаньянами и мудрыми провидцами.
Т.е. были некие модельные эксперименты. Дальше проектировщики масштабировали эти данные, оценивая динамику реактора "в общем". При этом ожидали, что заложенного запаса хватит чтоб компенсировать локальные отклонения реального реактора от расчетной модели.
Про стремление сделать не дорого - это конечно чистая правда. И тогда, и сейчас проектировщиков прессуют вопросом - а не будет ли предложенное решение слишком дорогим. А СССР в 60-е это очень небогатая страна.
И не смотря на все это, реактор спроектировали довольно безопасным. Он самоглушился при случайном разгоне на малой мощности за счет нагрева и отравления ксеноном.
Увы, можно сделать защиту от дурака, но только от неизобретательного. Хоть оставленный в покое реактор и самозатухал, а комсомольского напора с криками: "я заставлю тебя разгоняться", он не выдержал. И пошел в разнос!
режим при котором реактор взорвался был вообще неизвестен
Известен: режим работы при 5% от максимальной мощности. Этот режим проходит дважды в год КАЖДЫЙ реактор РБМК: при остановке на ППР и при запуске после ППР.
Не верно! Взрыв произошел из-за того что стержни сначала подняли (практически все), а потом единовременно все ввели. А подняли их все из-за того, что реактор был отравлен ксеноном в следствие долгой работы на низкой мощности.
Т.е. Опасным режимом была попытка разогнать реактор после слишком медленного снижения мощности. А это совсем не то, что проходит дважды в год каждый реактор.
Т.е. для аварии нужно было нарушить регламент минимум дважды + использовать аварийное средство в режиме который не был предусмотрен.
Не глушить реактор сразу, а долго гонять его на малой мощности отравляя ксеноном (проигнорировав команды АСУ).
После этого выдвинуть все регулирующие стержни пытаясь удержать нужный уровень мощности на тухнущем реакторе (заблокировав систему защиты).
А когда реактор таки пошел в разгон, пытаться его остановить, введя все регулирующие стержни разом (кнопка АЗ-5).
Сильно похоже на сценарий:
Долго жарить шашлыки на мангале.
Когда угли почти прогорели вспомнить, что еще колбаски пожарить забыли.
Плеснуть в мангал щедрой рукой керосина, что раскочегарить его опять.
А когда пламя от керосина достигнет 2 метров херануть туда воды из ковшика. Просто чтоб погасить огонь. Результат у всех вокруг обоженные морды и сгоревшие волосы. Вокруг все в копоти и воняет.
Это вы видите разницу между авто и ОС. Но для компании это просто продукт. И все решения относительно продукта принимаются на основе анализа прибылей и убытков (в том числе будущих). Я далек от мысли что весь топ менеджмент Майкрософта неопытные дураки. Они скорее очень умные, но излишне хитрожопые люди. Все больше похоже на то, что компании просто выгоднее продавать ОС через реселеров. Другие продукты компания продает на своих сайтах (Ажуре подписки и другие облачные сервисы).
К сожалению, биоинформатика сейчас только только начинается. Прорыв в понимании будет только когда количество секвенированных организмов дойдет до реально уровня BigData. Плюс нужны остальные данные о донорах (история болезни). А пока данных сильно недостаточно. Учитывая размер генома и "ошибки чтения" при секвенировании нужны данные сотен миллионов людей для поиска корреляций. Со временем повториться история с данными для обучения ИИ (данных для обучения все время недостаточно). ДНК датасеты будут представлять большую ценность, ими будут торговать, и без них будет невозможен дальнейший прогресс в медицине и биологии.
Полностью поддержу то что написано в статье. И часто дела обстоят еще хуже. Ты непрерывно пилишь эту огромную кодовую базу на компоненты, удаляешь старый код, разбиваешь зависимости только для того чтобы стоять на месте. Это позволяет добиться только того, что сложность не сильно быстро растет. Потому что все новые фичи, исправления ошибок только наращивают и сложность, и кодовую базу.
Здесь нужно все время бежать только для того чтобы остаться на месте. Чтобы двигаться вперед нужно бежать вдвое быстрее!
Низкопотенциальное - означает маленькую разницу температур теплоносителя на входе и на выходе. Например, датацентр производит много воздуха нагретого до 45-50 градусов. Или воды нагретой до 40. Забирать теплоноситель из водяного контура крайне нежелательно. Много денег порачено на водоподготовку, да и токсичный он. А использовать теплоноситель такой низкой температуры сложно, транспортировать такое тепло дорого.
О результатах конкурса почитать уже нигде. Это внутренний конкурс и в интернет эти данные никогда не попадали. Да и внутри корпорации эти документы скорее всего уже канули в лету, 14 лет прошло как никак.
В смысле потратить еще денег в дополнение к 1 bln USD по счетам за электричество? А результат отобьется?
https://www.dns-shop.ru/catalog/recipe/83b7b2608460a247/s-kostnoj-provodimostu - не вариант?
С датацентра тепло идет низкопотенциальное (т.е. невысокой температуры). В 2011 Майкрософт проводил внутренний конкурс проектов куда это тепло можно пристроить. Никто не победил.
Но идея про подвалы в принципе годная. т.к. транспортировать такое тепло далеко не надо.
Не нужно греть дом старыми телевизорами! У меня домашний десктоп неспроста имеет БП 1000 Вт мощности. Да и сервер числомолотилка легко скушает 1 кВт, а потом отдаст вам его в качестве отопления. При этом он еще и радостно будет рендерить видео, или распознавать объекты на снимках.
Можно перестать постоянно выключать свет и вообще экономить на освещении. Для большого дома это сотни ватт постоянно.
Нет конечно! Просто добавьте в список другие средства разработки. Например Visual Studio 2018, PyCharm.
И сразу будет заметно, что можно сделать сильно эффективнее без сжирания всей доступной памяти в одно перекормленное лицо.
"Приличное моделирование" должно воспроизводить "неоднородности нейтронного поля на малой мощности" и "неустойчивость реактора в режимах малой мощности и активной работы стежнями СУЗ". Это критерий "приличности" с моей точки зрения.
Какова потребная сложность модели? Видимо с точностью по ТВЭЛа, либо с точностью до кассеты (как минимум). По высоте активную зону придется разбивать на ячейки размером сравнимым с размер графитового наконечника срежня регулирования (точно не менее 100 ячеек по высоте).
Т.е. активную зону моделировать как 1693 * 100 = 169300 независимых тепловыделяющих сборки (с точностью до кассеты). Либо как 1693 * 18 * 100 = 3047400 независимых тепловыделяющих элемента (с точностью до ТВЭЛа). Плюс каналы (и паросодержание в каждом), плюс положение каждого стержня регулирования.
Итого расход памяти на такую модель от миллиона до первых десятков миллионов числовых параметров.
Теперь смотрим на упоминаемую машину М-200 как типичного представителя ЦВМ того времени:
ОЗУ от 4 до 16 тысяч 47-битных слов,
Накопители на магнитном барабане объёмом от 24 до 65 тысяч слов.
Накопитель на магнитной ленте (4 блока) ёмкостью от 4 до 16 миллионов слов
производительность — до 27000 оп/сек И видим, что как сову не натягивай, а нехватка по памяти полтора порядка даже при использовании магнитных барабанов. По производительности тоже все очень плохо. Расчет будет идти со скоростью несколько минут (десятков минут) на один шаг по времени. Т.е. на просчет одного режима уйдут недели и месяцы машинного времени в режиме монопольного использования ЦВМ. А режимов десятки.
Вот я и говорю, что "теми средствами" реалистичную модель было непотянуть. В 80-е что-то моделировать стало возможно. Но к тому времени проект был успешно сдан и снова тратить месяцы и годы на моделирование никто бы не дал.
Очевидно, что сложность модели сильно (О(h^3)) зависит от физических размеров активной зоны. Из-за этого ВВЭРы моделировать проще, а результат выходит точнее.
Печаль - тоска в том, что забывают/игнорируют сценарии реально тяжелого использования. А на них вся эта Electron'ная чухня дохнет, сожрав предварительно всю память.
Если у тебя проект на несколько MLOC и ты открываешь по паре сотен файлов одновременно, сколько инстансов IDE ты можешь запустить одновременно? А ведь надо иногда!
В том же Хроме 2 меня тоже больше сотни вкладок открыто одновременно. Так для удобства приходится 5 инстансов Хрома запускать. И что? Он же сссамка собаки течет и падает.
А ведь когда-то это было нормальным сценарием и все работало! Вкладки в браузере в 3-4 ряда и нормально. Что-то недочитал, недоделал можно было вкладку оставить открытой и не бояться что браузер рухнет и потеряет контекст. Про падения VS вообще никто не думал что так бывает.
А сейчас приложений на JS наклепали, да только они работают по сценарию "строго 1 инстанс, не более 5 файлов разом, раз в день рестартуем ибо течет сильно". Как будто при профессиональном использовании кроме этого приложения человек ничем не пользуется и больше на машине ничего не запускает!
Все электричество которое вы потребляете в доме в конечном итоге превращается в тепло. Поэтому гонять электрообогреватель идея изначально дурная. Нужно гонять оборудование, которое попутно производит что-то еще полезное. Компы которые майнят крипту, обучают нейросетки, обрабатывают видео, хостят что угодно. Телевизоры, освещение - да что угодно, только не тупые электрообогреватели.
В содержании датацентров самое дорогое это не железо, а оплата счетов за электричество. Тут можно иметь и отопление, и национальную сеть по хостингу видео/распознанию образов/расчету фолдинга белков. И все это примерно за одни и те-же деньги.
Ну тут вот товарищ выше пишет, что теперь падает. Либо за последние 4 года начала, либо у него какой-то "особенный" плагин добавлен. Плагины и раньше могли Студию уронить, или всю память сожрать.
Так она раньше не падала. Я даже больше скажу. Она и месяцами работала стабильно, я на ночь ее и не закрывал. Раз в месяц приходили патчи и машина перезагружалась. А остальное время VS перезапускать и не приходилось. А еще у меня в ней по 200 файлов было открыто. И иногда я мог несколько экземпляров VS открыть для разных проектов. И все это прекрасно работало.
Вы просто сравниваете 3-х перекормленных монстров и оказывается что все они примерно одинаковые.
Оно бы было хорошо, если бы не общие библиотеки. От просто общих до системных.
Да в том то и дело, что было не "планомерное снижение мощности", а была "игра мощностью вверх-вниз и долгая работа на половинной мощности". Это и загнало реактор в нестабильный режим ксенонового отравления. В этому добавилось желание провести эксперимент "во что бы ни стало", и регулирование без хорошего понимания процессов в реакторе.
В конструкции реактора были недостатки как в системе регулирования - "положительная обратная связь" ака "положительная реактивность", так и в системе контроля - "параметры критически важные для работы на малой мощности на пульте не отображались".
Но это обычная история, что любая катастрофа это всегда сочетание многих факторов. И не будь любого, аварии бы не было.
Такой запас регулирования мог понадобится по мере выгорания топлива. То что не было аппаратных ограничений на поднятие всех стержней - да, косяк проектировщика. Хотя не факт что тогдашняя техника позволила бы такое ограничение качественно реализовать.
Хотя педаль газа на авто тоже можно выжать "до упора", и часто такое кончится плохо (дождь, снег). Но иногда такой запас "по газу" может понадобится. Вот педаль и сделали такой.
С реактором ситуация похожа.
Это даже не вариант. Это факт который всеми признается. Для приличного моделирования такого реактора в 60-х просто не существовало технических средств. Тот-же МКЭ требует слишком много памяти и вычислительных операций чтоб реалистично моделировать локальные эффекты на такой громадине. И это не было исключительно советской проблемой. Постфактум же все стали дартаньянами и мудрыми провидцами.
Т.е. были некие модельные эксперименты. Дальше проектировщики масштабировали эти данные, оценивая динамику реактора "в общем". При этом ожидали, что заложенного запаса хватит чтоб компенсировать локальные отклонения реального реактора от расчетной модели.
Про стремление сделать не дорого - это конечно чистая правда. И тогда, и сейчас проектировщиков прессуют вопросом - а не будет ли предложенное решение слишком дорогим. А СССР в 60-е это очень небогатая страна.
И не смотря на все это, реактор спроектировали довольно безопасным. Он самоглушился при случайном разгоне на малой мощности за счет нагрева и отравления ксеноном.
Увы, можно сделать защиту от дурака, но только от неизобретательного. Хоть оставленный в покое реактор и самозатухал, а комсомольского напора с криками: "я заставлю тебя разгоняться", он не выдержал. И пошел в разнос!
Не верно! Взрыв произошел из-за того что стержни сначала подняли (практически все), а потом единовременно все ввели. А подняли их все из-за того, что реактор был отравлен ксеноном в следствие долгой работы на низкой мощности.
Т.е. Опасным режимом была попытка разогнать реактор после слишком медленного снижения мощности. А это совсем не то, что проходит дважды в год каждый реактор.
Т.е. для аварии нужно было нарушить регламент минимум дважды + использовать аварийное средство в режиме который не был предусмотрен.
Не глушить реактор сразу, а долго гонять его на малой мощности отравляя ксеноном (проигнорировав команды АСУ).
После этого выдвинуть все регулирующие стержни пытаясь удержать нужный уровень мощности на тухнущем реакторе (заблокировав систему защиты).
А когда реактор таки пошел в разгон, пытаться его остановить, введя все регулирующие стержни разом (кнопка АЗ-5).
Сильно похоже на сценарий:
Долго жарить шашлыки на мангале.
Когда угли почти прогорели вспомнить, что еще колбаски пожарить забыли.
Плеснуть в мангал щедрой рукой керосина, что раскочегарить его опять.
А когда пламя от керосина достигнет 2 метров херануть туда воды из ковшика. Просто чтоб погасить огонь. Результат у всех вокруг обоженные морды и сгоревшие волосы. Вокруг все в копоти и воняет.
Это вы видите разницу между авто и ОС. Но для компании это просто продукт. И все решения относительно продукта принимаются на основе анализа прибылей и убытков (в том числе будущих).
Я далек от мысли что весь топ менеджмент Майкрософта неопытные дураки. Они скорее очень умные, но излишне хитрожопые люди.
Все больше похоже на то, что компании просто выгоднее продавать ОС через реселеров. Другие продукты компания продает на своих сайтах (Ажуре подписки и другие облачные сервисы).
К сожалению, биоинформатика сейчас только только начинается. Прорыв в понимании будет только когда количество секвенированных организмов дойдет до реально уровня BigData. Плюс нужны остальные данные о донорах (история болезни).
А пока данных сильно недостаточно. Учитывая размер генома и "ошибки чтения" при секвенировании нужны данные сотен миллионов людей для поиска корреляций.
Со временем повториться история с данными для обучения ИИ (данных для обучения все время недостаточно). ДНК датасеты будут представлять большую ценность, ими будут торговать, и без них будет невозможен дальнейший прогресс в медицине и биологии.
Полностью поддержу то что написано в статье.
И часто дела обстоят еще хуже. Ты непрерывно пилишь эту огромную кодовую базу на компоненты, удаляешь старый код, разбиваешь зависимости только для того чтобы стоять на месте. Это позволяет добиться только того, что сложность не сильно быстро растет. Потому что все новые фичи, исправления ошибок только наращивают и сложность, и кодовую базу.
Здесь нужно все время бежать только для того чтобы остаться на месте. Чтобы двигаться вперед нужно бежать вдвое быстрее!