Программы Опции

[Гость]

открываю страшную тайну - перед тем как какой либо код можно использовать для вычислений на нем рассчитывается система (топливная сборка, зона реактора или еще что) и результаты расчета сравниваются с ЭКСПЕРИМЕНТАЛЬНЫМИ ДАННЫМИ. только после этого код можно использовать. а в начале любого нового проекта проводят benchmark расчет (одну и туже по геометрии и композиции систему считают на разных кодах и проверяют величину ошибки).

Тайна то в другом. На экспериментальных данных хренъ что проверишь. Ошибки экспериментаторов пострашнее ошибок теоретиков будут.

[Editor-in-Chief]

Тайна то в другом. На экспериментальных данных хренъ что проверишь. Ошибки экспериментаторов пострашнее ошибок теоретиков будут.

Согласен, но только частично.

Интересно, слышал кто из присутствовавших нашумевший в свое время доклад по верификации программ для БН-350? Там первое, с чем столкнулись расчетчики, был состав обедненного урана в экранах. Его, оказывается, свозили из разных мест, сваливали в кучу и делали таблетки. А сколько конкретно было обогащение, нигде не помечали. И что ставить в модели? 0,2% или 0,4%?

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

Только зачем же лезть с верификацией/валидацией программы сразу на "сложные" системы? Берутся бенчмарки попроще, сделанные из модельных экспериментов с намеренно упрощенной геометрией и пр. СКЕРЦО (?) была отличным примером, гомогенная среда из металлического урана.

Или вот хороший пример бенчмарка по кассетам PWR. Геометрия проще не бывает, для особых любителей дан аксиальный баклинг. Верифицируйтесь на здоровье!
http://www-rsicc.ornl.gov/cfdocs/blk/db/rpdlwrbmarkfnl.pdf

[Гость]

не понял пассаж про "разное понимание точности". это как такое может быть?????? )))

хм, может быть всякое вот и тема предметной дискуссии!
а скажите, например, с какой точностью mcnp (casmo, helios) считает решетку типа Х? а наперед сказать можно - "вот мы посчитаем новую решетку Х27, результат будет +- 3%"? И какова надежность этой оценки погрешности? Как она получена? Говорите, верифицировались на решетках типа Х13 и Х25 - а можно ли переносить эти оценки на другой изотопный состав, спектр и т.п. ? Использовали статистические критерии? - насколько справедливы такие оценки, какая надежность. Да множество обоснованных сомнений можно высказать

В России для паспортов программ вроде принят был один подход, теперь есть большая свобода, лишь бы обосновал свою оценку (и тут говорят бывает такое). Потом читаешь материалы по американскому коду (вот хоть из APA-H Вестингауза), а они заявляют точность в 2-3 раза выше нашей! Как так?! Потом скупо упоминают, что такой результат получен на спец. подобранной выборке, оч. небольшой, но формально достаточной, т.п... т.е. другой подход.
И как сравнивать, какой код точнее?

открываю страшную тайну - перед тем как какой либо код можно использовать для вычислений на нем рассчитывается система (топливная сборка, зона реактора или еще что) и результаты расчета сравниваются с ЭКСПЕРИМЕНТАЛЬНЫМИ ДАННЫМИ. только после этого код можно использовать. а в начале любого нового проекта проводят benchmark расчет (одну и туже по геометрии и композиции систему считают на разных кодах и проверяют величину ошибки).

хорошо, что есть еще Плохиши, а то бы мы тайны не узнали
Валидация - это конечно нужно, но что с этой оценкой делать дальше? Можно ее распространить на все случаи? Тут уже упоминали про точность эксперимента, тоже получаемую порой из расчетно-экспериментального сравнения Тот же ORNL сейчас ведет в международном сотрудничестве (и ФЭИ там, и КИ) мега-работу по созданию библиотеки экспериментов, которые могут быть бенчмарками. Большое внимание уделяется поиску всех возможных источников погрешностей - и это титаническая (а порой неблагодарная) работа.
Но это все для случая расчета ячеек, простых геометрий, где возможны простые эксперименты. А перейти к активной зоне в целом? а динамика? а если с тепло-гидравликой? А как насчет "сопряженных кодов" типа простр.нейтр.динамика/теплогидравлика? А эти коды используются в процессе лицензирования АЭС. Там придумывают себе "интегральные бенчмарки", но как понимать результаты сравнений, как использовать? И какие могут быть эксперименты по аварии RIA (выброс кластера из зоны на 100% мощности? ) И т.д. - вот и есть разное понимание точности.
А вы какую величину считаете "точностью расчета"?

[Гость]

Вопрос в тему возник. Чем отличается валидация кода от верификации?

[Гость]

Вопрос в тему возник. Чем отличается валидация кода от верификации?

Валидация
Процесс, позволяющий определить, насколько точно с позиций потенциального пользователя некоторая модель представляет заданные сущности реального мира. (AIAA G-077-1998)
См. Validation Assessment.


Верификация
Процесс, позволяющий определить, что разработанное программное средство точно реализует концептуальное описание данной системы. (AIAA G-077-1998)
См. Verification Assessment.

http://sp.cs.msu.ru/specsem/vvp/

[Гость]

Классно! А по-русски как это выйдет?

Валидация проверяет, работает ли программа, решает ли уравнение диффузии, не валится ли, все ли печатает?

А верификация проверяет, правильно ли программа считает конкретный тип реакторов?

Или я не правильно понял?

[Гость]

Классно! А по-русски как это выйдет?

Валидация проверяет, работает ли программа, решает ли уравнение диффузии, не валится ли, все ли печатает?

А верификация проверяет, правильно ли программа считает конкретный тип реакторов?

Или я не правильно понял?

Есть такое впечатление, что все с точностью до наоборот :-) Верификация есть формальная проверка кода на соответствие заданным требованиям, а валидация проходит при настройке его на конкретные ВВЭРы.

[Гость]

Классно! А по-русски как это выйдет?
Валидация проверяет, работает ли программа, решает ли уравнение диффузии, не валится ли, все ли печатает?
А верификация проверяет, правильно ли программа считает конкретный тип реакторов?
Или я не правильно понял?

нет, неправильно, хотя все там написнно по-русски

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

Верификация - отвечает на вопрос, насколько правильно выбранная модель реализованна в виде программы. Сравнение с другими подобными кодами тоже можно отнести к верификации.

Нужны оба процесса. Например, модель реализована с ошибками, но на конкретном объекте (конфигурации) показала хорошее совпадение (вроде как валидацию прошла), а на других ошибется. Или - модель верифицирована, все что задумано, сделано, но изначально выбрана неадекватная модель (например, выбрана точечная, а нужна 3D)
Есть вопрос, как организовать процессы валидации/верификации; какие эксперименты или расчетные бенчмарки выбрать. Отдельный вопрос, как понимать результаты валидации/верификации, как пользоваться ими.

[ДяДя ФеДоР]

У меня был небольшой опыт с французским комплексом для расчета быстрых реакторов. Названия не помню, но очень похоже на СССР. Поразило (1) стандартизация (все лаборатории считают по одной и той же программе, поддерживаемой централизованно, в то время как у нас раньше каждый норовил написать собственную); (2) большая забота об удобстве пользователей (хочешь, вводи массы изотопов, хочешь, концентрации и т.п.).

А так, комплекс как комплекс (кодами их тогда не называли, только программы и комплексы). Несмотря на то, что делался он для быстрых реакторов, элементарные ячейки он рассчитывал не совсем верно (не было учтено то, что в советской АРАМАКО называлось "B-житиками").

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

[Editor-in-Chief]

оказалось, что правки в код внести некому, специалистов, разбирающихся в нем досконально на уровне разработчиков - не осталось....

Это да. Но у меня-то "свое время" было в 1991 году, когда еще все были в полном соку и расцвете сил!

Хотя тревожные звоночки тогда поступали... Помню, долго возился над тем, что у меня не сходились результаты по разным модулям. Бился долго, пока не понял, что один из операторов ввода данных по составу топлива подвирает.

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

Но то, что он безусловно крайне удобен для использования - это факт!

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

Но не в том суть. Что тогда - повторюсь, в 1991 году - сразу бросилось в глаза по поводу удобств?

Код в той лаборатории, куда я попал, применялся для расчетов трансмутации MA в EFR и PRISM. Последний они считали только для сравнения, а вот EFR тогда могли и построить, поэтому расчеты шли всерьез.

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

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

Так вот. Код автоматизировать эти операции не позволял. Все выполнялось вручную. Пересчитал концентрации, сформировал новое задание и послал на счет. Техника у французов была - прелесть, пальчики оближешь! Не то, что наши ЕС-ки... Но использовалась она при таком подходе весьма и весьма неэффективно. Я бы сказал, с КИУМ много меньшим 50%

Но всех это устраивало. Почему? Работу делали стажеры, в основном, иностранцы. 2-3 раза в день они пересчитывали концентрации, тратя каждый раз минут 10-15, а в остальное время они занимались своими делами. Трещали друг с другом и по телефону, курили, пили кофе... короче, вели нормальную жизнь офисного планктона.

Казалось бы, начальство должно было бы быть недовольно. Как же так? Один человек в рабочий день продвигался в расчетах, дай Бог, если на одну кампанию... Дык ну и что? Стажеров в Кадараше хватало, з/п им платило французское государство. Помню, посадили нас - русского, американца, испанца, баска, араба и француза - и дали установку: вперед, ребята! Поспешаем не торопясь, через полгода отчет.

Признаюсь честно - мне как-то стало сразу не по себе! Чертыхаясь и плюясь, сколотил пакетный файл из команд Юникса и фортрановских программулечек-самопалов. Отладил - работает, само берет данные из выходных файлов, корректирует как надо и вставляет в файл исходных данных.

Просчитал за выходные весь набор заданий, показал результаты... и в конечном итоге, получил от оторопевшего начальства (того самого Алана З.) искренний ответ: "Ну что, особо шустрый молодой человек? Сделал за выходные всю работу группы за полгода? Теперь сиди и думай, чем будешь дальше заниматься, чтобы оправдывать свое пребывание на рабочем месте!"

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

Что, судя по Вашему комментарию, у французов в конце концов и произошло.

С уважением,
Александр Уваров
AtomInfo.Ru, гл.ред.

Сообщение отредактировал Editor-in-Chief - 22.9.2008, 20:00

[ДяДя ФеДоР]

мое "свое время" - это 2004 год, и не Кадараш, а исследовательский центр EdF под Парижем, местечко Clamart Cedex...
Видимо, Вам все-таки довелось общаться с другим кодом, поскольку ERANOS был очень приспособлен для расчета перегрузок.
Я тогда считал на нем БРЕСТ с виброуплотненным мокс-топливом, просчитывали вплоть до 40-60 циклов... до этого - жидкосолевые реакторы, и наш БН (был совместный русско/французский проект).

Просто, писался этот ERANOS давно, писался хоть и хорошо - но видимо после этого интерес угас... А жаль! Код очень приличный, удобный, понятный... респект французам!

[Гость]

(славному парню Алану З., теперь он, как говорят, стал большим боссом)...

Относительно большим - Deputy head of division

Абсолютно из головы вылетело название их кода, с которым работал Почему-то кажется, что не ERANOS...

Может, APOLLO?

[Editor-in-Chief]

Относительно большим - Deputy head of division

Всё равно рад за него! Славный парень.

Случайно, о судьбе такого Марка Д. ничего не знаете?

[Гость]

Случайно, о судьбе такого Марка Д. ничего не знаете?

Если Вы имеете в виду того Марка Д., который с Жаном-Полем Г. работал, то, если я ничего не путаю, после 2007 г. он, вроде, в Сакле перешёл. К сожалению, позднее я из темы выпал, да и постоянных контактов с нашими общими знакомыми не поддерживал, season greetings, не более.

[Phenix]

Если Вы имеете в виду того Марка Д., который с Жаном-Полем Г. работал, то, если я ничего не путаю, после 2007 г. он, вроде, в Сакле перешёл. К сожалению, позднее я из темы выпал, да и постоянных контактов с нашими общими знакомыми не поддерживал, season greetings, не более.

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

[Editor-in-Chief]

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

Ну, Алан З. - это Alain Zaetta. Deputy head of division at CEA, как написано сейчас в Гугле. У меня о нём остались самые хорошие впечатления.

Мне было немножко непривычно брать интервью у Сальватореса. Когда я стажировался в Кадараше, он был там главным.
http://atominfo.ru/news/air2348.htm
Кстати, у него была хорошая традиция - все стажёры в обязательном порядке один раз приглашались с ним на обед в замке. Помню, я его повеселил изрядно. Он начал рассказывать о недавно бушевавшем вокруг Кадараша пожаре, я уточнил, что огонь подходил к центру на столько-то там метров, а он развеселился - мол, ха-ха, советская разведка, как видно, уже всё знает.

А Вы где работали в Кадараше, если не секрет? Я как раз у Алана, считал трансмутацию Np, Am и Cu в EFR и PRISM'е.

[AtomInfo.Ru]

Редакция рекомендует.

Интервью с одним из организаторов "Нейтроники".

http://atominfo.ru/news/air8162.htm

[Гость]

В порядке отступления - сразу вспоминается фраза, звучавшая при пусконаладке Тяньваня, о том, что устройство локализации расплава топлива в натурной проверке не нуждается…

Пять баллов!!! Хорошо сказано! И за все интервью спасибо.

[www]

Пять баллов!!! Хорошо сказано! И за все интервью спасибо.

Это как сказать. Амеры свою теорию in-core retention проверяли в натуре для AP-600. То есть плавили и заливали снаружи водой. Потом разрезали корпус и смотрели как кориум вел себя и корректировали модель.

Корейцы смоделировали/распространили этот эксперимент на свой реактор. Потому Саркози зубами скрежетит... да укусить не может

[Editor-in-Chief]

Корейцы смоделировали/распространили этот эксперимент на свой реактор.

А вот это как раз момент тонкий. Финны корейцам не поверили. Мол, для 600 МВт технология доказана, но для 1400 МВт - нет. Поэтому корейцы для своих европейских проектов будут вставлять ловушку.

Замечу в скобках, что ответить на вопрос "Нужна или не нужна ловушка?" я бы лично сильно затруднился.