Необходимо было во введении к статье указать ссылку на работу в журнале "Известия вузов", таким образом определенный процент читателей мог бы сразу начать более подробное ознакомление с материалом. Теперь что касается содержания статьи:
Отсутствует обзор использующихся в отечественной и зарубежной практиках программных средств для теплогидравлического анализа активных зон ядерных реакторов. Если говорить про иерархию кодов в соответствии с масштабами расчетных областей в ЯЭУ, то можно выделить системные (system), субканальные (subchannel), CFD, DNS.
Следствием из предыдущего пункта является некорректное сравнение времени счета вашего программного средства с CFD-моделированием, т.к. данные коды находятся на разных ступенях в приведенной градации и предназначены совершенно для различного рода анализа. Ваше программное средство логичнее было сравнивать с классическими одномерными кодами, в которых сложное движение теплоносителя в пределах пучков стержней сводится к рассмотрению одномерного течения внутри эквивалентной трубы.
Т.к. отсутствует сравнение с одномерными кодами, а именно они используются в упомянутых вами тренажерах, то область применения вашего ПС является крайне туманной. В особенности учитывая тот факт, что наиболее интересные динамические процессы в ЯЭУ связаны с кипением теплоносителя, моделирование которого с помощью вашего ПС не было рассмотрено.
В целом основное развитие программных средств сейчас идет в сторону корректного моделирования локальных эффектов, которые раньше либо не учитывались вовсе, либо учитывались благодаря введению соответствующей степени консерватизма. Ваше программное средство идет в абсолютно противоположную сторону...
"Пара слов о реализации данного алгоритма" - пункт специально для Хабра... Вообще, если вы добавляете информацию о выборе ЯП, то он должен быть обоснован. Фраза "по моему личному мнению, Java обладает приятным синтаксисом." не является обоснованием (причем я не уверен, что даже создатели Java считали, что у данного ЯП приятный синтаксис). Для задач вычислительной физики подходят другие языки: Fortran, C++, Matlab, Python, Julia (произвольный порядок перечисления)
Во первых, как лично мне показалось, если автором и был кинут камень в огород Фортрана, то исключительно на территорию 77-го.
Во вторых, с использованием 2018-го стандарта есть проблема, которую автор также подметил. Работники науки старшей школы просто не понимают, зачем все это нужно: ООП, классы, интерфейсы, области видимости и т.д., если они всю жизнь обходились с помощью глобальных массивов (или даже массивА, разные части которого хранят разную информацию).
В третьих, как по мне, если и ставить цель избавиться от легаси в науки (а заодно и расширить кругозор некоторых ее работников) то 2018-ый Фортран является плохим вариантом. Ибо будем честны, язык уже фактически мертв (да, есть stdlib, fpm и ещё несколько проектов, но этого мало), даже несмотря на рейтинги Tiobe. Julia является прекрасной альтернативой: схожий синтаксис, скорость, наличие достаточного количества библиотек для мат. вычислений, возможность безболезненного вызова Фортран-кода и т.д. Numba позволяет и Python превратить в нечто похожее, но данную комбинацию я ещё в полной мере не пробовал.
P.S. Я тот человек, который пришел в науку после университета без IT подготовки, но пытающийся расширять свой кругозор.
Установка представляет собой сборку из графитовых блоков с центральными отверстиями
Почему после картинки с уран-водным стендом повествование без какой-либо видимой причины снова возвращается к описанию уран-графитовой сборки?
Сами потоки были рассчитаны с помощью узко-специализированного научного ПО.
Почему бы не привести название используемого программного средства? Оно не сделало бы статью менее научно-популярной, но одновременно с этим дало бы определенную информацию людям с кафедры / из отрасли.
Если к примеру студент изменит шаг решетки, то через сколько он сможет наблюдать визуализацию нового нейтронного поля?
Необходимо было во введении к статье указать ссылку на работу в журнале "Известия вузов", таким образом определенный процент читателей мог бы сразу начать более подробное ознакомление с материалом. Теперь что касается содержания статьи:
Отсутствует обзор использующихся в отечественной и зарубежной практиках программных средств для теплогидравлического анализа активных зон ядерных реакторов. Если говорить про иерархию кодов в соответствии с масштабами расчетных областей в ЯЭУ, то можно выделить системные (system), субканальные (subchannel), CFD, DNS.
Следствием из предыдущего пункта является некорректное сравнение времени счета вашего программного средства с CFD-моделированием, т.к. данные коды находятся на разных ступенях в приведенной градации и предназначены совершенно для различного рода анализа. Ваше программное средство логичнее было сравнивать с классическими одномерными кодами, в которых сложное движение теплоносителя в пределах пучков стержней сводится к рассмотрению одномерного течения внутри эквивалентной трубы.
Т.к. отсутствует сравнение с одномерными кодами, а именно они используются в упомянутых вами тренажерах, то область применения вашего ПС является крайне туманной. В особенности учитывая тот факт, что наиболее интересные динамические процессы в ЯЭУ связаны с кипением теплоносителя, моделирование которого с помощью вашего ПС не было рассмотрено.
В целом основное развитие программных средств сейчас идет в сторону корректного моделирования локальных эффектов, которые раньше либо не учитывались вовсе, либо учитывались благодаря введению соответствующей степени консерватизма. Ваше программное средство идет в абсолютно противоположную сторону...
"Пара слов о реализации данного алгоритма" - пункт специально для Хабра... Вообще, если вы добавляете информацию о выборе ЯП, то он должен быть обоснован. Фраза "по моему личному мнению, Java обладает приятным синтаксисом." не является обоснованием (причем я не уверен, что даже создатели Java считали, что у данного ЯП приятный синтаксис). Для задач вычислительной физики подходят другие языки: Fortran, C++, Matlab, Python, Julia (произвольный порядок перечисления)
Во первых, как лично мне показалось, если автором и был кинут камень в огород Фортрана, то исключительно на территорию 77-го.
Во вторых, с использованием 2018-го стандарта есть проблема, которую автор также подметил. Работники науки старшей школы просто не понимают, зачем все это нужно: ООП, классы, интерфейсы, области видимости и т.д., если они всю жизнь обходились с помощью глобальных массивов (или даже массивА, разные части которого хранят разную информацию).
В третьих, как по мне, если и ставить цель избавиться от легаси в науки (а заодно и расширить кругозор некоторых ее работников) то 2018-ый Фортран является плохим вариантом. Ибо будем честны, язык уже фактически мертв (да, есть stdlib, fpm и ещё несколько проектов, но этого мало), даже несмотря на рейтинги Tiobe. Julia является прекрасной альтернативой: схожий синтаксис, скорость, наличие достаточного количества библиотек для мат. вычислений, возможность безболезненного вызова Фортран-кода и т.д. Numba позволяет и Python превратить в нечто похожее, но данную комбинацию я ещё в полной мере не пробовал.
P.S. Я тот человек, который пришел в науку после университета без IT подготовки, но пытающийся расширять свой кругозор.
Почему после картинки с уран-водным стендом повествование без какой-либо видимой причины снова возвращается к описанию уран-графитовой сборки?
Почему бы не привести название используемого программного средства? Оно не сделало бы статью менее научно-популярной, но одновременно с этим дало бы определенную информацию людям с кафедры / из отрасли.
Если к примеру студент изменит шаг решетки, то через сколько он сможет наблюдать визуализацию нового нейтронного поля?