# Surrogate model in ASTEC code

Louis Proffit, Bastien Poubeau, Lionel Chailan

► To cite this version:

Louis Proffit, Bastien Poubeau, Lionel Chailan. Surrogate model in ASTEC code: ASSAS Project. Engineering Sciences [physics]. 2023. irsn-04589014

HAL Id: irsn-04589014

https://irsn.hal.science/irsn-04589014

Submitted on 27 May 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# Surrogate model in ASTEC code

Louis Proffit, Bastien Poubeau, Lionel Chailan

► To cite this version:

Louis Proffit, Bastien Poubeau, Lionel Chailan. Surrogate model in ASTEC code. Engineering Sciences [physics]. 2023. irsn-04589014

HAL Id: irsn-04589014

https://asnr.hal.science/irsn-04589014v1

Submitted on 27 May 2024

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
<figure><img src="image_2.png" /></figure>

# Internship Report
## ASSAS Project

LOUIS PROFFIT

25 JULY 2023
<figure><img src="image_2.png" /></figure>

# Internship Report
## ASSAS Project

LOUIS PROFFIT

25 JULY 2023
Abstract

Accident Source Term Evaluation Code (ASTEC) is a simulation code developed by the severe accident department of Institut de radioprotection et de sûreté nucléaire (IRSN). It is devoted to severe accident modelling in nuclear facilities, especially Pressurized water reactor (PWR), from initiating event to fission products release in the environment.

"Artificial Intelligence for Simulation of Severe Accidents" (ASSAS) is a european project that aims at building a proof of concept of a simulator based on ASTEC. It will mostly target a PWR 1300 reactor, on some Loss Of Coolant Accident (LOCA) and/or Station blackout (SBO) scenarios. To provide a correct simulation environment, ASTEC will need to compute SA sequences faster than it currently does. Surrogate models of specific parts of the reactor and/or specific part of the physical phenomena are expected to allow such performance. Three criteria: precision, performance and flexibility drive the selection of the most promising surrogate models among the vast set of possible choices.

Such surrogate model will handle variable spaces of very large dimensions, leading to losses in precision and high consumption of storage resources. Identifying which ASTEC variables carry the most information and which can be relatively easily recomputed is a mandatory step in order to reduce those dimensions. A "filter" written during this internship does so.

The design of a surrogate model, following the previously enacted principles has also been tackled. A surrogate model of steam generators is the chosen option. A linear regressive model is compared to more complex neural networks with recurrent structure. The linear model is largely outperformed. Further improvement in the training process greatly increase its performance. The last step of this work consists in wiring it back in ASTEC, which requires handling interfacing and numerical issues. It is still in progress when this report is being written.
**Abstract**

Accident Source Term Evaluation Code (ASTEC) is a simulation code developed by the severe accident department of Institut de radioprotection et de sûreté nucléaire (IRSN). It is devoted to severe accident modelling in nuclear facilities, especially Pressurized water reactor (PWR), from initiating event to fission products release in the environment.

"Artificial Intelligence for Simulation of Severe Accidents" (ASSAS) is a european project that aims at building a proof of concept of a simulator based on ASTEC. It will mostly target a PWR 1300 reactor, on some Loss Of Coolant Accident (LOCA) and/or Station blackout (SBO) scenarios. To provide a correct simulation environment, ASTEC will need to compute SA sequences faster than it currently does. Surrogate models of specific parts of the reactor and/or specific part of the physical phenomena are expected to allow such performance. Three criteria: precision, performance and flexibility drive the selection of the most promising surrogate models among the vast set of possible choices.

Such surrogate model will handle variable spaces of very large dimensions, leading to losses in precision and high consumption of storage resources. Identifying which ASTEC variables carry the most information and which can be relatively easily recomputed is a mandatory step in order to reduce those dimensions. A "filter" written during this internship does so.

The design of a surrogate model, following the previously enacted principles has also been tackled. A surrogate model of steam generators is the chosen option. A linear regressive model is compared to more complex neural networks with recurrent structure. The linear model is largely outperformed. Further improvement in the training process greatly increase its performance. The last step of this work consists in wiring it back in ASTEC, which requires handling interfacing and numerical issues. It is still in progress when this report is being written.
# Résumé opérationnel

Accident Source Term Evaluation Code (ASTEC) est un code développé par le Service des Accidents Graves (SAM) de l'Institut de radioprotection et de sûreté nucléaire (IRSN). Il permet de simuler des accidents graves dans une installation nucléaire, particulièrement les Réacteurs à Eau Pressurisée (REP).

"Artificial Intelligence for Simulation of Severe Accidents" (ASSAS) est un projet européen visant à créer une preuve de concept d'un simulateur d'accident grave ayant ASTEC pour base. Il ciblera principalement un réacteur REP1300, dans des accidents de type Accident de Perte de Réfrigérant Primaire (APRP) et Perte Totale des Alimentations Electriques (PTAE). Pour fournir un environnement de simulation correct, ASTEC devra calculer les séquences d'AG plus rapidement qu'actuellement. Des modèles de substitution de parties du réacteur et/ou de certains phénomènes physiques devraient permettre ce niveau de performance. Trois critères: précision, performance et flexibilité, guident la selection des modèles de substitution les plus prometteurs parmi l'ensemble considérable des choix possibles.

De tels modèles de substitution s'appuient sur des espaces de variables de très grande dimension, qui peuvent limiter la précision des modèles et causer une consommation excessive des ressources de stockage. Identifier quelles variables d'ASTEC contiennent le plus d'informations et quelles autres peuvent être plus ou moins facilement recalculées est nécessaire pour réduire cette dimension. Un "filtre" établi pendant ce stage remplit cette fonction.

La mise au point de modèles de substitution, selon les principes décrits ci-dessus, a également été entreprise. Le générateur de vapeur (GV) est l'option choisie. Trois modèles de substitution utilisant l'apprentissage profond et des structures récurrentes, ainsi qu'un modèle de référence linéaire ont été conçus, entrainés, et comparés. Le modèle de référence est battu par les trois. Des améliorations sur ce modèle ont été obtenues en perfectionnant la phase d'entrainement, sans contrepartie sur la performance ou la flexibilité. La dernière étape de ce travail consiste à connecter ce modèle de substitution au code ASTEC existant, ce qui pose des problèmes d'interface ainsi que des problèmes numériques. Cette tâche est encore en cours au moment de la rédaction de ce rapport.
# Résumé opérationnel

Accident Source Term Evaluation Code (ASTEC) est un code développé par le Service des Accidents Graves (SAM) de l'Institut de radioprotection et de sûreté nucléaire (IRSN). Il permet de simuler des accidents graves dans une installation nucléaire, particulièrement les Réacteurs à Eau Pressurisée (REP).

"Artificial Intelligence for Simulation of Severe Accidents" (ASSAS) est un projet européen visant à créer une preuve de concept d'un simulateur d'accident grave ayant ASTEC pour base. Il ciblera principalement un réacteur REP1300, dans des accidents de type Accident de Perte de Réfrigérant Primaire (APRP) et Perte Totale des Alimentations Electriques (PTAE). Pour fournir un environnement de simulation correct, ASTEC devra calculer les séquences d'AG plus rapidement qu'actuellement. Des modèles de substitution de parties du réacteur et/ou de certains phénomènes physiques devraient permettre ce niveau de performance. Trois critères: précision, performance et flexibilité, guident la selection des modèles de substitution les plus prometteurs parmi l'ensemble considérable des choix possibles.

De tels modèles de substitution s'appuient sur des espaces de variables de très grande dimension, qui peuvent limiter la précision des modèles et causer une consommation excessive des ressources de stockage. Identifier quelles variables d'ASTEC contiennent le plus d'informations et quelles autres peuvent être plus ou moins facilement recalculées est nécessaire pour réduire cette dimension. Un "filtre" établi pendant ce stage remplit cette fonction.

La mise au point de modèles de substitution, selon les principes décrits ci-dessus, a également été entreprise. Le générateur de vapeur (GV) est l'option choisie. Trois modèles de substitution utilisant l'apprentissage profond et des structures récurrentes, ainsi qu'un modèle de référence linéaire ont été conçus, entrainés, et comparés. Le modèle de référence est battu par les trois. Des améliorations sur ce modèle ont été obtenues en perfectionnant la phase d'entrainement, sans contrepartie sur la performance ou la flexibilité. La dernière étape de ce travail consiste à connecter ce modèle de substitution au code ASTEC existant, ce qui pose des problèmes d'interface ainsi que des problèmes numériques. Cette tâche est encore en cours au moment de la rédaction de ce rapport.
# Contents

## 1 ASTEC 6

<table><tr><td>1.1</td><td>ODESSA</td><td>7</td></tr><tr><td>1.2</td><td>Material Data Bank (MDB)</td><td>8</td></tr><tr><td>1.3</td><td>Numerical aspects in ASTEC</td><td>9</td></tr><tr><td>1.4</td><td>Modules description</td><td>10</td></tr><tr><td>1.5</td><td>CESAR-ICARE</td><td>11</td></tr></table>

## 2 ASSAS 12

<table><tr><td>2.1</td><td>Input deck</td><td>13</td></tr><tr><td>2.2</td><td>Surrogate models</td><td>14</td></tr><tr><td>2.3</td><td>Surrogate models, ASTEC considerations</td><td>16</td></tr></table>

## 3 Advances and perspectives 19

<table><tr><td>3.1</td><td>Input-Output identification</td><td>19</td></tr><tr><td>3.2</td><td>Directions for surrogate models</td><td>21</td></tr><tr><td>3.2.1</td><td>Time-step related issues</td><td>21</td></tr><tr><td>3.2.2</td><td>Flexibility related issues</td><td>22</td></tr><tr><td>3.2.3</td><td>Updated directions for surrogate models</td><td>22</td></tr><tr><td>3.3</td><td>Steam generator surrogate modeling</td><td>23</td></tr><tr><td>3.3.1</td><td>Identifying inputs and outputs</td><td>23</td></tr><tr><td>3.3.2</td><td>Building surrogate model</td><td>25</td></tr><tr><td>3.3.3</td><td>Training surrogate model</td><td>27</td></tr><tr><td>3.3.4</td><td>Oscillations, averaging, improvements</td><td>32</td></tr></table>
# Contents

## 1 ASTEC 6

<table><tr><td>1.1</td><td>ODESSA</td><td>7</td></tr><tr><td>1.2</td><td>Material Data Bank (MDB)</td><td>8</td></tr><tr><td>1.3</td><td>Numerical aspects in ASTEC</td><td>9</td></tr><tr><td>1.4</td><td>Modules description</td><td>10</td></tr><tr><td>1.5</td><td>CESAR-ICARE</td><td>11</td></tr></table>

## 2 ASSAS 12

<table><tr><td>2.1</td><td>Input deck</td><td>13</td></tr><tr><td>2.2</td><td>Surrogate models</td><td>14</td></tr><tr><td>2.3</td><td>Surrogate models, ASTEC considerations</td><td>16</td></tr></table>

## 3 Advances and perspectives 19

<table><tr><td>3.1</td><td>Input-Output identification</td><td>19</td></tr><tr><td>3.2</td><td>Directions for surrogate models</td><td>21</td></tr><tr><td>3.2.1</td><td>Time-step related issues</td><td>21</td></tr><tr><td>3.2.2</td><td>Flexibility related issues</td><td>22</td></tr><tr><td>3.2.3</td><td>Updated directions for surrogate models</td><td>22</td></tr><tr><td>3.3</td><td>Steam generator surrogate modeling</td><td>23</td></tr><tr><td>3.3.1</td><td>Identifying inputs and outputs</td><td>23</td></tr><tr><td>3.3.2</td><td>Building surrogate model</td><td>25</td></tr><tr><td>3.3.3</td><td>Training surrogate model</td><td>27</td></tr><tr><td>3.3.4</td><td>Oscillations, averaging, improvements</td><td>32</td></tr></table>
List of Figures

<table><tr><td>2</td><td>General organisation of ASTEC code</td><td>7</td></tr><tr><td>3</td><td>Time steps management in ASTEC</td><td>9</td></tr><tr><td>4</td><td>CESAR-ICARE coupling</td><td>11</td></tr><tr><td>5</td><td>Ratio between calculation time and physical time for LOCA in cold leg</td><td>12</td></tr><tr><td>6</td><td>ASSAS partners anticipated workload</td><td>13</td></tr><tr><td>7</td><td>Simplified input-deck mesh, with two out of four branches</td><td>14</td></tr><tr><td>8</td><td>A single neuron</td><td>15</td></tr><tr><td>9</td><td>A neural network with two dense layers (blue and yellow)</td><td>15</td></tr><tr><td>10</td><td>Modules CPU usage during SBO (left) and small LOCA (right)</td><td>17</td></tr><tr><td>11</td><td>Validation process</td><td>20</td></tr><tr><td>12</td><td>LSTM internal structure</td><td>26</td></tr><tr><td>13</td><td>Baseline, SLO/LLO and MLS surrogate model structure</td><td>27</td></tr><tr><td>14</td><td>Computation graph for the LLO model</td><td>28</td></tr><tr><td>15</td><td>Underfitting and overfitting phenomena</td><td>30</td></tr><tr><td>16</td><td>Surrogate model training/validation MSE-losses for 100 epochs.</td><td>30</td></tr><tr><td>17</td><td>Comparison of validation losses for all models.</td><td>31</td></tr><tr><td>18</td><td>Steam generator water level (%) in assisted simulation mode</td><td>32</td></tr><tr><td>19</td><td>H2 pressure (Pa) in VOLUME TUX_V001</td><td>32</td></tr><tr><td>20</td><td>Gas speed in the junction cold-box - cold-leg</td><td>33</td></tr><tr><td>21</td><td>New LLO losses, comparison with old LLO</td><td>34</td></tr><tr><td>22</td><td>Losses for new LLO</td><td>34</td></tr></table>
List of Figures

<table><tr><td>2</td><td>General organisation of ASTEC code</td><td>7</td></tr><tr><td>3</td><td>Time steps management in ASTEC</td><td>9</td></tr><tr><td>4</td><td>CESAR-ICARE coupling</td><td>11</td></tr><tr><td>5</td><td>Ratio between calculation time and physical time for LOCA in cold leg</td><td>12</td></tr><tr><td>6</td><td>ASSAS partners anticipated workload</td><td>13</td></tr><tr><td>7</td><td>Simplified input-deck mesh, with two out of four branches</td><td>14</td></tr><tr><td>8</td><td>A single neuron</td><td>15</td></tr><tr><td>9</td><td>A neural network with two dense layers (blue and yellow)</td><td>15</td></tr><tr><td>10</td><td>Modules CPU usage during SBO (left) and small LOCA (right)</td><td>17</td></tr><tr><td>11</td><td>Validation process</td><td>20</td></tr><tr><td>12</td><td>LSTM internal structure</td><td>26</td></tr><tr><td>13</td><td>Baseline, SLO/LLO and MLS surrogate model structure</td><td>27</td></tr><tr><td>14</td><td>Computation graph for the LLO model</td><td>28</td></tr><tr><td>15</td><td>Underfitting and overfitting phenomena</td><td>30</td></tr><tr><td>16</td><td>Surrogate model training/validation MSE-losses for 100 epochs.</td><td>30</td></tr><tr><td>17</td><td>Comparison of validation losses for all models.</td><td>31</td></tr><tr><td>18</td><td>Steam generator water level (%) in assisted simulation mode</td><td>32</td></tr><tr><td>19</td><td>H2 pressure (Pa) in VOLUME TUX_V001</td><td>32</td></tr><tr><td>20</td><td>Gas speed in the junction cold-box - cold-leg</td><td>33</td></tr><tr><td>21</td><td>New LLO losses, comparison with old LLO</td><td>34</td></tr><tr><td>22</td><td>Losses for new LLO</td><td>34</td></tr></table>
# Introduction

Artificial intelligence for Simulation of Severe AccidentS (ASSAS) project is a european cooperation between 14 partners, focusing on Artificial Intelligence (AI) in the field of Severe Accident Management (SAM). It aims at producing a proof of concept for a Severe Accident (SA) simulator, that could be used to train nuclear power plant operators and assess SA procedures. The core of the simulator will be the Accident Source Term Evaluation Code (ASTEC), that has become a reference in the field of SA simulation.

Because it is not fast enough, ASTEC needs to be accelerated. Numerical schemas and spatial discretisation are reaching their intrinsic limits, so new methods have to be explored. Surrogate modeling is one of them, especially with the use of AI. It consists in replacing physical models by neural networks that are expected to be quicker, even though less precise. The great diversity of phenomenas and systems involved in the management of a SA provide multiple options to do so. Selecting the most promising ones is the first task of the ASSAS project. Following them is the second.

This internship takes place at the very beginning of the project, that will last 4 years.
Therefore, it consists mainly in exploring options rather than providing a production-ready
solution to the original problem.

This report will be split in three parts. First, the structure of ASTEC and the tools
it uses is detailed, in order to provide deeper understanding of what surrogate models will
need to handle. Then, specific concerns of the ASSAS project are tackled, especially general
ideas about surrogate modeling and machine learning. The work accomplished during this
internship is eventually described: the writing of a "filter" that focuses on the core of an ASTEC
simulation, and a surrogate model attempt for Steam Generator (SG).
# Introduction

Artificial intelligence for Simulation of Severe AccidentS (ASSAS) project is a european cooperation between 14 partners, focusing on Artificial Intelligence (AI) in the field of Severe Accident Management (SAM). It aims at producing a proof of concept for a Severe Accident (SA) simulator, that could be used to train nuclear power plant operators and assess SA procedures. The core of the simulator will be the Accident Source Term Evaluation Code (ASTEC), that has become a reference in the field of SA simulation.

Because it is not fast enough, ASTEC needs to be accelerated. Numerical schemas and spatial discretisation are reaching their intrinsic limits, so new methods have to be explored. Surrogate modeling is one of them, especially with the use of AI. It consists in replacing physical models by neural networks that are expected to be quicker, even though less precise. The great diversity of phenomenas and systems involved in the management of a SA provide multiple options to do so. Selecting the most promising ones is the first task of the ASSAS project. Following them is the second.

This internship takes place at the very beginning of the project, that will last 4 years.
Therefore, it consists mainly in exploring options rather than providing a production-ready
solution to the original problem.

This report will be split in three parts. First, the structure of ASTEC and the tools
it uses is detailed, in order to provide deeper understanding of what surrogate models will
need to handle. Then, specific concerns of the ASSAS project are tackled, especially general
ideas about surrogate modeling and machine learning. The work accomplished during this
internship is eventually described: the writing of a "filter" that focuses on the core of an ASTEC
simulation, and a surrogate model attempt for Steam Generator (SG).
# 1 ASTEC

The Accident Source Term Evaluation Code (ASTEC) [?] developed by IRSN aims at simulating an entire Severe Accident (SA) sequence in a nuclear facility, and particularly in a water-cooled reactor, from the initiating event through the release of radioactive elements out of the containment, including the behaviour of engineered safety systems and procedures used in Severe Accident Management (SAM). The main applications are:

* Source term determination studies.

* Probabilistic Safety Assessment level 2 (PSA-2) studies including the determination of uncertainties.

* Accident management studies.

* Physical analyses of experiments to improve the understanding of the phenomenology.

The code has the following requirements:

* Sufficient validation to cover the main physical phenomena;

* Account for safety systems and procedures;

* User-friendly to easily perform sensitivity analyses;

* Equipped with tools for pre-processing, on-line visualisation, and post-processing;

* Fast running code.

ASTEC is a modular code, each module simulating a reactor zone or a set of physical phenomena. Those modules are independent of each other, with the notable exception of ICARE and CESAR (see 1.5). They interact indirectly via a centralized state management tool called an ODESSA base. Fig 2 shows this module structure.

An ASTEC calculation is split in three steps:

1. Initialisation: a calculation can start from two sources:

* An input deck: a set of files describing the context of the simulation: mesh, systems, initial values...

* A restart from a previous calculation: during an ASTEC calculation, it is possible to save a snapshot of the state of the system. A new computation can restart from that state. In ASTEC, restart is "perfect", meaning there is no difference between the original calculation and the restarted calculation. Even though this seems necessary, it requires a lot of care during the design of each module and their interaction.
# 1 ASTEC

The Accident Source Term Evaluation Code (ASTEC) [?] developed by IRSN aims at simulating an entire Severe Accident (SA) sequence in a nuclear facility, and particularly in a water-cooled reactor, from the initiating event through the release of radioactive elements out of the containment, including the behaviour of engineered safety systems and procedures used in Severe Accident Management (SAM). The main applications are:

* Source term determination studies.

* Probabilistic Safety Assessment level 2 (PSA-2) studies including the determination of uncertainties.

* Accident management studies.

* Physical analyses of experiments to improve the understanding of the phenomenology.

The code has the following requirements:

* Sufficient validation to cover the main physical phenomena;

* Account for safety systems and procedures;

* User-friendly to easily perform sensitivity analyses;

* Equipped with tools for pre-processing, on-line visualisation, and post-processing;

* Fast running code.

ASTEC is a modular code, each module simulating a reactor zone or a set of physical phenomena. Those modules are independent of each other, with the notable exception of ICARE and CESAR (see 1.5). They interact indirectly via a centralized state management tool called an ODESSA base. Fig 2 shows this module structure.

An ASTEC calculation is split in three steps:

1. Initialisation: a calculation can start from two sources:

* An input deck: a set of files describing the context of the simulation: mesh, systems, initial values...

* A restart from a previous calculation: during an ASTEC calculation, it is possible to save a snapshot of the state of the system. A new computation can restart from that state. In ASTEC, restart is "perfect", meaning there is no difference between the original calculation and the restarted calculation. Even though this seems necessary, it requires a lot of care during the design of each module and their interaction.
<figure><img src="image_3.png" /><figcaption>Figure 2: General organisation of ASTEC code</figcaption></figure>

2. Execution: because modules are independent of each other, they can just be called sequentially. Their coordination is implicit. The modules are RUPUICUV, READBASE, CESAR-ICARE, DROPLET, RCSMESH, CORIUM, MEDICIS, ASCAVI, THC, CPA, PH, SOPHAEROS, SAFARI, DOSE, COVI and ISODOP.

3. Postprocessing: producing reports, graphics, curves..., defined during the initialisation phase.

## 1.1 ODESSA

ODESSA is a set of tools aiming at easing the development of scientific codes at IRSN. Some of those tools are:

1. A database management system: an "ODESSA base" is a hierarchical database. It is a tree graph where nodes are called structures (written STRU) and leaves are one of the following elements:

* R0, R1, R2, R3: floating point numbers in 0D (a single value), 1D, 2D and 3D respectively

* I0, I1, I2: integer numbers in 0D (a single value), 1D and 2D respectively (no need for 3D for integers)

* C0, C1: string in 0D (a single word) or 1D (no need for 2D or 3D), limited to 8 characters.

* RG and IG (respectively floating point and integer groups): a mapping between identifiers (string) and values (respectively floating point and integers)

* T: a text without limitation on length

Nodes, "structures" are made of families. Families are arrays of leaves or structures.
<figure><img src="image_3.png" /><figcaption>Figure 2: General organisation of ASTEC code</figcaption></figure>

2. Execution: because modules are independent of each other, they can just be called sequentially. Their coordination is implicit. The modules are RUPUICUV, READBASE, CESAR-ICARE, DROPLET, RCSMESH, CORIUM, MEDICIS, ASCAVI, THC, CPA, PH, SOPHAEROS, SAFARI, DOSE, COVI and ISODOP.

3. Postprocessing: producing reports, graphics, curves..., defined during the initialisation phase.

## 1.1 ODESSA

ODESSA is a set of tools aiming at easing the development of scientific codes at IRSN. Some of those tools are:

1. A database management system: an "ODESSA base" is a hierarchical database. It is a tree graph where nodes are called structures (written STRU) and leaves are one of the following elements:

* R0, R1, R2, R3: floating point numbers in 0D (a single value), 1D, 2D and 3D respectively

* I0, I1, I2: integer numbers in 0D (a single value), 1D and 2D respectively (no need for 3D for integers)

* C0, C1: string in 0D (a single word) or 1D (no need for 2D or 3D), limited to 8 characters.

* RG and IG (respectively floating point and integer groups): a mapping between identifiers (string) and values (respectively floating point and integers)

* T: a text without limitation on length

Nodes, "structures" are made of families. Families are arrays of leaves or structures.
2. A readable data format (.dat), and a parser to convert it to an ODESSA base. It is similar to json, xml and yaml data formats.

3. A binary format (.bin): a raw "saving" format that minimizes space. An ODESSA base can be dumped and loaded from and to that format.

4. A programming language (Turing complete): analyzer. It enables any behaviour to be attached to an ODESSA base.

ODESSA is used by ASTEC during the three calculation phases.

1. During initialisation, the state is loaded from an input deck (.dat format) or a binary saving (.bin format) into an ODESSA base.

2. During calculation, modules read and write values in the ODESSA base. It is their only way to interact, as they can't "call" each other.

3. During postprocessing, most produced output are described by the user during the initialisation phase and stored in the ODESSA base.

ODESSA has a C, a C++ and a Fortran interface. The C interface is wrapped by a tool called Swig to a Python interface that provides type safety and interoperability with basic C, especially pointers.

As any library, ODESSA has no coupling with applications that use it. ODESSA provides functions, ASTEC (or other) use them the way it needs. In particular, there is no constraint on the type of leaf ASTEC uses to store a value. For instance, to store a single scalar value $v$, ASTEC can use:

* A R0, containing the scalar value

* A R1 of size 2, in the format $(time, v(time))$, to remember at what time $v$ was computed

* A R1 of size $n$, in the format $(v(0), \dots, v(n))$, to remember all previous values of $v$

Those different choices are used in different part of the ASTEC code, depending on the role of the variable, the programmer's taste...

## 1.2 Material Data Bank (MDB)

MDB, is a physical database containing physical and chemical properties for many elements and species. It aggregates data from different sources: experimentations, calculations.... ASTEC uses it, especially for the thermal-hydraulics properties of water, the thermodynamic properties of mixtures of materials (modules ICARE, MEDICIS) and the chemical reactions (module SOPHAEROS).
2. A readable data format (.dat), and a parser to convert it to an ODESSA base. It is similar to json, xml and yaml data formats.

3. A binary format (.bin): a raw "saving" format that minimizes space. An ODESSA base can be dumped and loaded from and to that format.

4. A programming language (Turing complete): analyzer. It enables any behaviour to be attached to an ODESSA base.

ODESSA is used by ASTEC during the three calculation phases.

1. During initialisation, the state is loaded from an input deck (.dat format) or a binary saving (.bin format) into an ODESSA base.

2. During calculation, modules read and write values in the ODESSA base. It is their only way to interact, as they can't "call" each other.

3. During postprocessing, most produced output are described by the user during the initialisation phase and stored in the ODESSA base.

ODESSA has a C, a C++ and a Fortran interface. The C interface is wrapped by a tool called Swig to a Python interface that provides type safety and interoperability with basic C, especially pointers.

As any library, ODESSA has no coupling with applications that use it. ODESSA provides functions, ASTEC (or other) use them the way it needs. In particular, there is no constraint on the type of leaf ASTEC uses to store a value. For instance, to store a single scalar value $v$, ASTEC can use:

* A R0, containing the scalar value

* A R1 of size 2, in the format $(time, v(time))$, to remember at what time $v$ was computed

* A R1 of size $n$, in the format $(v(0), \dots, v(n))$, to remember all previous values of $v$

Those different choices are used in different part of the ASTEC code, depending on the role of the variable, the programmer's taste...

## 1.2 Material Data Bank (MDB)

MDB, is a physical database containing physical and chemical properties for many elements and species. It aggregates data from different sources: experimentations, calculations.... ASTEC uses it, especially for the thermal-hydraulics properties of water, the thermodynamic properties of mixtures of materials (modules ICARE, MEDICIS) and the chemical reactions (module SOPHAEROS).
1.3 Numerical aspects in ASTEC

Every ASTEC module is a deterministic code. It solves time-space differential equations on
the subset of the system the module is responsible for. For instance:

1. CESAR handles thermohydraulics variables for the primary and the secondary circuit.

2. ICARE handles core-degradation variables for the vessel.

3. SOPHAEROS handles fission products variables outside the vessel.

The space-discretisation is done at the input-deck level. The ODESSA base already
contains space-discrete variables.

The time-discretisation has a specific behaviour. Each module has its own time step and is responsible for updating it. To coordinate all modules, ASTEC itself has a time-step that is called macro-time-step. All modules have a "meeting point" at that macro-time-step. It is an upper bound for their internal time-step. As fig 3 shows, CESAR and ICARE are an exception to that general behaviour, because they have "meeting-points" more often than ASTEC macro-time-step. More details will be provided in section 1.5.

<figure><img src="image_4.png" /><figcaption>Figure 3: Time steps management in ASTEC</figcaption></figure>

The choice of this behaviour for ASTEC is an intermediate solution between two extremes:

1. Every module share the same time-step. The time-steps needs to be that of the "slowest" module (in terms of time-step length), which degrades performance

2. Every module has its own time step, and they are independent. That could lead to convergence issues, because variables of fast-processing modules would evolve too quickly with respect to those of slow-processing modules.

Most of the modules use an Euler-implicit time integration scheme solved with the Newton-Raphson numerical schema. It is a first-order, implicit schema. Modules don't rely on the same implementation of the method as each one is optimized for the specific problem structure, especially when it comes to assembling the Jacobian matrix.
## 1.3 Numerical aspects in ASTEC

Every ASTEC module is a deterministic code. It solves time-space differential equations on the subset of the system the module is responsible for. For instance:

1. CESAR handles thermohydraulics variables for the primary and the secondary circuit.

2. ICARE handles core-degradation variables for the vessel.

3. SOPHAEROS handles fission products variables outside the vessel.

The space-discretisation is done at the input-deck level. The ODESSA base already contains space-discrete variables.

The time-discretisation has a specific behaviour. Each module has its own time step and is responsible for updating it. To coordinate all modules, ASTEC itself has a time-step that is called macro-time-step. All modules have a "meeting point" at that macro-time-step. It is an upper bound for their internal time-step. As fig 3 shows, CESAR and ICARE are an exception to that general behaviour, because they have "meeting-points" more often than ASTEC macro-time-step. More details will be provided in section 1.5.

<figure><img src="image_4.png" /><figcaption>Figure 3: Time steps management in ASTEC</figcaption></figure>

The choice of this behaviour for ASTEC is an intermediate solution between two extremes:

1. Every module share the same time-step. The time-steps needs to be that of the "slowest" module (in terms of time-step length), which degrades performance

2. Every module has its own time step, and they are independent. That could lead to convergence issues, because variables of fast-processing modules would evolve too quickly with respect to those of slow-processing modules.

Most of the modules use an Euler-implicit time integration scheme solved with the Newton-Raphson numerical schema. It is a first-order, implicit schema. Modules don't rely on the same implementation of the method as each one is optimized for the specific problem structure, especially when it comes to assembling the Jacobian matrix.
## 1.4 Modules description

ASTEC is a general-purpose code, but this report mainly focuses on nuclear power-plants, especially PWR. For these kinds of facilities, ODESSA base is split in domains:

1. VESSEL: the vessel of the reactor

2. PRIMARY: the primary circuit, without the VESSEL domain

3. SECONDAR: the secondary circuit

4. CONTAINM: the containment

5. SYSTEMS: systems like pumps, accumulators, valves...

6. SENSORS: variables computed based on the state of the plant. They are used mostly for postprocessing and triggering events.

7. EVENTS: "things that can happen". For instance, SCRAM, vessel rupture...

8. CONNECTI: links between domains. They can be seen as boundary conditions for other domains. For instance, vessel and primary can exchange mass and energy through CONNECTIs. CONNECTIs also help model events like breaches. A Loss Of Coolant Accident (LOCA) can be modeled by a CONNECTI between PRIMARY and CONTAINM domains, that can be opened.

Modules are defined by the category of variables inside the ODESSA base they work on.

CESAR computes thermohydraulics. On most nuclear power plants input decks, thermohydraulics is computed in SECONDAR, PRIMARY and VESSEL domains. CESAR has a space-discretisation made of three type of elements:

1. VOLUMEs: with mostly temperatures, partial pressures and void fraction.

2. JUNCTIONs: between volumes, with mostly quantities of movement

3. WALLs: linked to volumes, with mostly temperatures.

ICARE models the core degradation in the vessel, including the oxydation process, the material melting and relocation, the thermal interaction and the release of fission products. It happens in the VESSEL domain.

SOPHAEROS computes fission products behaviour. fission products have an initial inventory that evolves through decay and chemical processes. SOPHAEROS is a very important ASTEC module, because it does the "source term evaluation". But its coupling with other modules is weak. It uses thermohydraulics output to transport the fission products, and computes a "fp_power" (fission product power) that is used by thermohydraulics.
## 1.4 Modules description

ASTEC is a general-purpose code, but this report mainly focuses on nuclear power-plants, especially PWR. For these kinds of facilities, ODESSA base is split in domains:

1. VESSEL: the vessel of the reactor

2. PRIMARY: the primary circuit, without the VESSEL domain

3. SECONDAR: the secondary circuit

4. CONTAINM: the containment

5. SYSTEMS: systems like pumps, accumulators, valves...

6. SENSORS: variables computed based on the state of the plant. They are used mostly for postprocessing and triggering events.

7. EVENTS: "things that can happen". For instance, SCRAM, vessel rupture...

8. CONNECTI: links between domains. They can be seen as boundary conditions for other domains. For instance, vessel and primary can exchange mass and energy through CONNECTIs. CONNECTIs also help model events like breaches. A Loss Of Coolant Accident (LOCA) can be modeled by a CONNECTI between PRIMARY and CONTAINM domains, that can be opened.

Modules are defined by the category of variables inside the ODESSA base they work on.

CESAR computes thermohydraulics. On most nuclear power plants input decks, thermohydraulics is computed in SECONDAR, PRIMARY and VESSEL domains. CESAR has a space-discretisation made of three type of elements:

1. VOLUMEs: with mostly temperatures, partial pressures and void fraction.

2. JUNCTIONs: between volumes, with mostly quantities of movement

3. WALLs: linked to volumes, with mostly temperatures.

ICARE models the core degradation in the vessel, including the oxydation process, the material melting and relocation, the thermal interaction and the release of fission products. It happens in the VESSEL domain.

SOPHAEROS computes fission products behaviour. fission products have an initial inventory that evolves through decay and chemical processes. SOPHAEROS is a very important ASTEC module, because it does the "source term evaluation". But its coupling with other modules is weak. It uses thermohydraulics output to transport the fission products, and computes a "fp_power" (fission product power) that is used by thermohydraulics.
CPA computes thermohydraulics inside the CONTAINM domain (buildings).

SYSINT computes systems behaviour.

MEDICIS computes concrete-corium interaction.

RUPUICUV computes corium-containment interaction.

## 1.5 CESAR-ICARE

CESAR [?] and ICARE [?] modules don't behave like other modules. Core degradation and thermohydraulics are very coupled phenomena (especially oxydation processes and thermal exchanges), so they need to be computed for very small time steps, much lower than ASTEC macro-time-step. The main module is ICARE. It works in three steps:

1. Prediction: ICARE predicts its values given previous thermohydraulics values

2. CESAR: ICARE calls CESAR to compute thermohydraulics given ICARE predictions. CESAR has its own internal time-step, and keeps stepping until it has reached ICARE time-step.

3. Correction: ICARE corrects its prediction given the "true" thermohydraulics values.

One could say that ICARE uses an semi-implicit schema with respect to thermohydraulics variables, as fig 4 shows.

<figure><img src="image_5.png" /><figcaption>Figure 4: CESAR-ICARE coupling</figcaption></figure>
CPA computes thermohydraulics inside the CONTAINM domain (buildings).

SYSINT computes systems behaviour.

MEDICIS computes concrete-corium interaction.

RUPUICUV computes corium-containment interaction.

## 1.5 CESAR-ICARE

CESAR [?] and ICARE [?] modules don't behave like other modules. Core degradation and thermohydraulics are very coupled phenomena (especially oxydation processes and thermal exchanges), so they need to be computed for very small time steps, much lower than ASTEC macro-time-step. The main module is ICARE. It works in three steps:

1. Prediction: ICARE predicts its values given previous thermohydraulics values

2. CESAR: ICARE calls CESAR to compute thermohydraulics given ICARE predictions. CESAR has its own internal time-step, and keeps stepping until it has reached ICARE time-step.

3. Correction: ICARE corrects its prediction given the "true" thermohydraulics values.

One could say that ICARE uses an semi-implicit schema with respect to thermohydraulics variables, as fig 4 shows.

<figure><img src="image_5.png" /><figcaption>Figure 4: CESAR-ICARE coupling</figcaption></figure>
## 2 ASSAS

Artificial intelligence for Simulation of Severe AccidentS (ASSAS) is a european project aiming at producing a proof of concept of a simulator of severe accidents. It would use a version of ASTEC enhanced by AI capabilities through surrogate models (see 2.2) as a backend.

AI algorithms are used for two reasons

1. To enhance ASTEC calculation speed: during some phases of the simulation, especially the beginning of the core degradation, ASTEC can sometimes be much slower than real time. This is acceptable in common use cases because it is faster in other phases, but not for a simulator. Fig 5 shows the ratio between calculation time and physical time for a LOCA scenario. A high ratio indicates a fast computation. A ratio of 1 indicates that ASTEC calculation is as fast as real time. The target is to increase that ratio at least above 1 for the whole simulation. AI algorithms could improve that speed, sacrificing only a limited amount of precision.

2. As a goal in itself: trying to model numerical differential solving with complex structure by IA algorithms is a true challenge, that can be taken up by data-scientist partners

<figure><img src="image_6.png" /><figcaption>Figure 5: Ratio between calculation time and physical time for LOCA in cold leg</figcaption></figure>

The project is divided in 5 Work-package (WP)s.

1. WP1 coordination: coordinate the other 5 work-packages.

2. WP2 methodology: define the strategy to improve calculation speed and validate it.

3. WP3 database: produce a database of ASTEC calculation for different input conditions and sampling strategies.

4. WP4 surrogate models: create and validate surrogate models following the strategy defined by WP2 and using data from WP3.
## 2 ASSAS

Artificial intelligence for Simulation of Severe AccidentS (ASSAS) is a european project aiming at producing a proof of concept of a simulator of severe accidents. It would use a version of ASTEC enhanced by AI capabilities through surrogate models (see 2.2) as a backend.

AI algorithms are used for two reasons

1. To enhance ASTEC calculation speed: during some phases of the simulation, especially the beginning of the core degradation, ASTEC can sometimes be much slower than real time. This is acceptable in common use cases because it is faster in other phases, but not for a simulator. Fig 5 shows the ratio between calculation time and physical time for a LOCA scenario. A high ratio indicates a fast computation. A ratio of 1 indicates that ASTEC calculation is as fast as real time. The target is to increase that ratio at least above 1 for the whole simulation. AI algorithms could improve that speed, sacrificing only a limited amount of precision.

2. As a goal in itself: trying to model numerical differential solving with complex structure by IA algorithms is a true challenge, that can be taken up by data-scientist partners

<figure><img src="image_6.png" /><figcaption>Figure 5: Ratio between calculation time and physical time for LOCA in cold leg</figcaption></figure>

The project is divided in 5 Work-package (WP)s.

1. WP1 coordination: coordinate the other 5 work-packages.

2. WP2 methodology: define the strategy to improve calculation speed and validate it.

3. WP3 database: produce a database of ASTEC calculation for different input conditions and sampling strategies.

4. WP4 surrogate models: create and validate surrogate models following the strategy defined by WP2 and using data from WP3.
5. WP5 optimization: improve ASTEC speed without AI algorithms, thanks to parallelization and classical optimization.

6. WP6 simulator: connect the improved version of ASTEC to a simulator front-end.

Fig 6 describes the anticipated workload for each ASSAS partner:

<figure><img src="image_7.png" /><figcaption>Figure 6: ASSAS partners anticipated workload</figcaption></figure>

## 2.1 Input deck

The work of all WPs will be directed towards a single input deck. It is a simplified version of the real input deck of the French PWR 1300. Simplifying the input deck enables faster calculations and simpler models, with only small losses on precision.

An exception to the use of a single input deck is the partner Energorisk that will work on a simulator for a VVER 1000 reactor. The partner KTH will also use US code MELCOR, therefore with a different input deck.

Fig 7 shows roughly the shape of the simplified input deck, with only two branches (out of 4), and with the following color correspondence:

* Green mesh is the secondary circuit

* Yellow mesh is the primary circuit plus the part of the VESSEL only managed by CESAR

* Blue mesh is the VESSEL managed by CESAR and ICARE

* Light blue arrows are valves

- Pressurizer valve

- GCT(A/C) valves

- Steam line valve
5. WP5 optimization: improve ASTEC speed without AI algorithms, thanks to parallelization and classical optimization.

6. WP6 simulator: connect the improved version of ASTEC to a simulator front-end.

Fig 6 describes the anticipated workload for each ASSAS partner:

<figure><img src="image_7.png" /><figcaption>Figure 6: ASSAS partners anticipated workload</figcaption></figure>

## 2.1 Input deck

The work of all WPs will be directed towards a single input deck. It is a simplified version of the real input deck of the French PWR 1300. Simplifying the input deck enables faster calculations and simpler models, with only small losses on precision.

An exception to the use of a single input deck is the partner Energorisk that will work on a simulator for a VVER 1000 reactor. The partner KTH will also use US code MELCOR, therefore with a different input deck.

Fig 7 shows roughly the shape of the simplified input deck, with only two branches (out of 4), and with the following color correspondence:

* Green mesh is the secondary circuit

* Yellow mesh is the primary circuit plus the part of the VESSEL only managed by CESAR

* Blue mesh is the VESSEL managed by CESAR and ICARE

* Light blue arrows are valves

- Pressurizer valve

- GCT(A/C) valves

- Steam line valve
* Dark blue arrows are potential cold water flows

- ARE for steam generators

- RIS for primary circuit

* Red arrows are primary coolant flows

- Steam Generator Tube Rupture (SGTR), for steam generators

- Primary tube rupture (PTR), for primary circuits

- PRIMARY-VESSEL usual flow, for hot and cold leg. This is a purely numerical object.

* Green arrows are primary pumps

<figure><img src="image_8.png" /><figcaption>Figure 7: Simplified input-deck mesh, with two out of four branches</figcaption></figure>

## 2.2 Surrogate models

WP2 and WP4 especially focus on developing surrogate models. A surrogate model behaves like its reference, but without reproducing its internal logic. Using neural networks is a common way to produce surrogate models, especially when non-linear behaviour is expected.

An artificial neuron is a function $\mathbb{R}^n \to \mathbb{R}$, with several parameters:

* weights: $w \in \mathbb{R}^n$

* bias: $b \in \mathbb{R}$

* activation: $f \in \mathbb{F}(\mathbb{R} \to \mathbb{R})$. It is often not considered as a parameter but as a characteristic of the neuron itself (it doesn't change).
* Dark blue arrows are potential cold water flows

- ARE for steam generators

- RIS for primary circuit

* Red arrows are primary coolant flows

- Steam Generator Tube Rupture (SGTR), for steam generators

- Primary tube rupture (PTR), for primary circuits

- PRIMARY-VESSEL usual flow, for hot and cold leg. This is a purely numerical object.

* Green arrows are primary pumps

<figure><img src="image_8.png" /><figcaption>Figure 7: Simplified input-deck mesh, with two out of four branches</figcaption></figure>

## 2.2 Surrogate models

WP2 and WP4 especially focus on developing surrogate models. A surrogate model behaves like its reference, but without reproducing its internal logic. Using neural networks is a common way to produce surrogate models, especially when non-linear behaviour is expected.

An artificial neuron is a function $\mathbb{R}^n \to \mathbb{R}$, with several parameters:

* weights: $w \in \mathbb{R}^n$

* bias: $b \in \mathbb{R}$

* activation: $f \in \mathbb{F}(\mathbb{R} \to \mathbb{R})$. It is often not considered as a parameter but as a characteristic of the neuron itself (it doesn't change).
<figure><img src="image_9.png" /><figcaption>Figure 8: A single neuron</figcaption></figure>

With the following definitions, the neuron is the function 1, shown in fig 8.

$$neuron(x) = f(b + w \cdot x) \qquad (1)$$

Multiple neurons can be grouped together to form a neural network. Any layout of neurons can be a neural network, but a common practice is to group them in layers and group layers in networks, like in fig 9. The most common layer is the dense layer: it has *n* inputs, *m* outputs, *m* neurons (one for each output) and all neurons share the same input.

<figure><img src="image_10.png" /><figcaption>Figure 9: A neural network with two dense layers (blue and yellow)</figcaption></figure>

Building a surrogate model with a neural networks consists in three steps:

1. Identifying inputs and outputs. That means identifying variables that need to be predicted by the surrogate model (the output) and variables that could/should influence the output (input). It is also requires building pre- and post-processing: it is unusual that all variables are floating point numbers, with 0-mean and 1-variance. Categorical data, characters, inconsistent data... should be processed in and out of the neural network.

2. Creating the neural network: choosing one parametric function in the set of all neural networks. This is merely a choice guided by academic feedback and quite often, intuition (so-called experience).
<figure><img src="image_9.png" /><figcaption>Figure 8: A single neuron</figcaption></figure>

With the following definitions, the neuron is the function 1, shown in fig 8.

$$neuron(x) = f(b + w \cdot x) \qquad (1)$$

Multiple neurons can be grouped together to form a neural network. Any layout of neurons can be a neural network, but a common practice is to group them in layers and group layers in networks, like in fig 9. The most common layer is the dense layer: it has *n* inputs, *m* outputs, *m* neurons (one for each output) and all neurons share the same input.

<figure><img src="image_10.png" /><figcaption>Figure 9: A neural network with two dense layers (blue and yellow)</figcaption></figure>

Building a surrogate model with a neural networks consists in three steps:

1. Identifying inputs and outputs. That means identifying variables that need to be predicted by the surrogate model (the output) and variables that could/should influence the output (input). It is also requires building pre- and post-processing: it is unusual that all variables are floating point numbers, with 0-mean and 1-variance. Categorical data, characters, inconsistent data... should be processed in and out of the neural network.

2. Creating the neural network: choosing one parametric function in the set of all neural networks. This is merely a choice guided by academic feedback and quite often, intuition (so-called experience).
3. Finding the best parameters for that neural network. This is called the training process.

Why should one use neural networks to build surrogate models? There are two main reasons for this:

1. Universal approximation theorem: any continuous function of $\mathbb{R}^n \to \mathbb{R}^m$ can be uniformly approximated with a dense layer of sufficient width. This theorem implies that looking for a function inside the set of neural network instead of a more general set of function is not a restrictive decision.

2. Backwards propagation algorithm: given a neural network with its current parameters, an input, an expected output and an actual output, the backwards propagation algorithm suggests corrections for the network parameters so that the actual output would better match the expected output if the same input was fed inside the updated network. This algorithm drives the previously mentioned third phase. Given a set of actual input and outputs, the following process (called a training loop) "improves" the parameters of the network.

* Start with any parameters (there are clever initialization methods)

* For each input, compute the output, and apply the backwards propagation algorithm.

These two reasons should not conceal that neural networks are not always an efficient solutions. For small models, sometimes a linear regression or logistic regression can be sufficient, and should be preferred. However, when the model is highly non-linear, and/or when it can't be simplified, neural networks remain the preferred solution.

## 2.3 Surrogate models, ASTEC considerations

Among the three phases mentioned of surrogate model development (2.2), the first one might be the most determining one. Because surrogate model don't reuse the internal logic of the reference model, there are a lot of degrees of freedom around what should be modeled, and therefore around the inputs and outputs of surrogate models. Given how broad the range of options is, not all of them can be explored. The goal of WP2 is to identify the most promising directions as early as possible, to ease the work of data-scientist and severe accidents specialist in WP4.

Several directions had been identified at the beginning of the project:

1. Model at the time-step scale: the surrogate model predicts the state at $t + dt$ given the state at $t$ and $dt$

2. Model at the global scale: predict the time and state at the end of the computation given the state at the beginning and/or an intermediate time.
3. Finding the best parameters for that neural network. This is called the training process.

Why should one use neural networks to build surrogate models? There are two main reasons for this:

1. Universal approximation theorem: any continuous function of $\mathbb{R}^n \to \mathbb{R}^m$ can be uniformly approximated with a dense layer of sufficient width. This theorem implies that looking for a function inside the set of neural network instead of a more general set of function is not a restrictive decision.

2. Backwards propagation algorithm: given a neural network with its current parameters, an input, an expected output and an actual output, the backwards propagation algorithm suggests corrections for the network parameters so that the actual output would better match the expected output if the same input was fed inside the updated network. This algorithm drives the previously mentioned third phase. Given a set of actual input and outputs, the following process (called a training loop) "improves" the parameters of the network.

* Start with any parameters (there are clever initialization methods)

* For each input, compute the output, and apply the backwards propagation algorithm.

These two reasons should not conceal that neural networks are not always an efficient solutions. For small models, sometimes a linear regression or logistic regression can be sufficient, and should be preferred. However, when the model is highly non-linear, and/or when it can't be simplified, neural networks remain the preferred solution.

## 2.3 Surrogate models, ASTEC considerations

Among the three phases mentioned of surrogate model development (2.2), the first one might be the most determining one. Because surrogate model don't reuse the internal logic of the reference model, there are a lot of degrees of freedom around what should be modeled, and therefore around the inputs and outputs of surrogate models. Given how broad the range of options is, not all of them can be explored. The goal of WP2 is to identify the most promising directions as early as possible, to ease the work of data-scientist and severe accidents specialist in WP4.

Several directions had been identified at the beginning of the project:

1. Model at the time-step scale: the surrogate model predicts the state at $t + dt$ given the state at $t$ and $dt$

2. Model at the global scale: predict the time and state at the end of the computation given the state at the beginning and/or an intermediate time.
3. Model a module: the surrogate model would replace a whole module, being transparent for other modules

4. Model the environment of a module: the surrogate model would replace everything but a module, being transparent for that module

5. Model a component or sub-component: the surrogate model would handle a specific part of the plant (PRIMARY or SECONDARY for instance).

6. Combinations of previous directions: for instance, handling thermohydraulics (CESAR) in the SECONDARY component at the time-step scale.

A "promising" direction is a good compromise between the following criteria:

* Expected performance: if a surrogate model replaces a part of ASTEC that uses few resources, even if the result is highly efficient, the gain will be low.

* Expected precision: if the surrogate replaces a part of ASTEC driven by complex physical and chemical processes, having a sufficient precision will be tougher

* Expected flexibility: how much work will be needed to plug the surrogate model to ASTEC? How much work to plug in to the simulator (WP6)?

Among those criteria, expected performance is the only one that can be accurately estimated beforehand, as it mainly depends on ASTEC current performance. The Fig 10 shows the repartition of computing times during an ASTEC computation for two different scenarios.

<figure><img src="image_11.png" /><figcaption>Figure 10: Modules CPU usage during SBO (left) and small LOCA (right)</figcaption></figure>

TRUPT is the time of the vessel rupture. It is a determining event in ASTEC, because it triggers the deactivation of CESAR and ICARE modules. Surrogate models of CESAR and/or ICARE would only be used during TRUPT, but that phase uses most of the computing time. The complex processes that happened during that phase make it practically impossible to model the whole phase by a single call to a surrogate model. The preferred direction would be to make the surrogate model compute one time-step at a time.
3. Model a module: the surrogate model would replace a whole module, being transparent for other modules

4. Model the environment of a module: the surrogate model would replace everything but a module, being transparent for that module

5. Model a component or sub-component: the surrogate model would handle a specific part of the plant (PRIMARY or SECONDARY for instance).

6. Combinations of previous directions: for instance, handling thermohydraulics (CESAR) in the SECONDARY component at the time-step scale.

A "promising" direction is a good compromise between the following criteria:

* Expected performance: if a surrogate model replaces a part of ASTEC that uses few resources, even if the result is highly efficient, the gain will be low.

* Expected precision: if the surrogate replaces a part of ASTEC driven by complex physical and chemical processes, having a sufficient precision will be tougher

* Expected flexibility: how much work will be needed to plug the surrogate model to ASTEC? How much work to plug in to the simulator (WP6)?

Among those criteria, expected performance is the only one that can be accurately estimated beforehand, as it mainly depends on ASTEC current performance. The Fig 10 shows the repartition of computing times during an ASTEC computation for two different scenarios.

<figure><img src="image_11.png" /><figcaption>Figure 10: Modules CPU usage during SBO (left) and small LOCA (right)</figcaption></figure>

TRUPT is the time of the vessel rupture. It is a determining event in ASTEC, because it triggers the deactivation of CESAR and ICARE modules. Surrogate models of CESAR and/or ICARE would only be used during TRUPT, but that phase uses most of the computing time. The complex processes that happened during that phase make it practically impossible to model the whole phase by a single call to a surrogate model. The preferred direction would be to make the surrogate model compute one time-step at a time.
Because the main contributors (CESAR and ICARE) are deactivated, the post-rupture phase is very quick. Expected performance of surrogate models that do the computation time-step by time-step is low. That phase would be preferably modeled by a surrogate model that "finishes" the computation in a single shot.

Given the state $X_t$ at time $t$ and the surrogate model function $f$, the properties of the two directions are shown in table 1.

<table><caption>Table 1: Properties of surrogate models following two directions</caption><thead><tr><th>Before TRUPT</th><th>After TRUPT</th></tr></thead><tbody><tr><td>$f: X_t \rightarrow X_{t=t+dt}$</td><td>$f: X_{t=TRUPT} \rightarrow X_{t=end}$</td></tr><tr><td>Call $f$ $n$ times to compute $t \rightarrow t + n * dt$</td><td>Call $f$ once to compute TRUPT $\rightarrow END$</td></tr><tr><td>One time-step is one data point</td><td>One simulation is on one data point</td></tr></tbody></table>

As for the part of the system the surrogate model would focus on, ICARE and CESAR obviously carry our main focus. The following options have taken the edge:

1. Replacing CESAR in the PRIMARY component.

2. Replacing CESAR in the SECONDAR component.

3. Replacing CESAR in the VESSEL component.

4. Replacing ICARE (in the VESSEL component).

5. Replacing CESAR and ICARE in the vessel component.

The expected properties of the aforementioned directions are shown in table 2.

<table><caption>Table 2: Expectations of directions along three criteria</caption><thead><tr><th>Direction</th><th>Expected performance</th><th>Expected precision</th><th>Expected flexibility</th></tr></thead><tbody><tr><td>CESAR in PRIMARY and<br>CESAR in SECONDAR</td><td>medium</td><td>medium</td><td>good</td></tr><tr><td>CESAR in VESSEL</td><td>good</td><td>low</td><td>low</td></tr><tr><td>ICARE in VESSEL</td><td>very good</td><td>low</td><td>low</td></tr><tr><td>CESAR-ICARE in VESSEL</td><td>excellent</td><td>very low</td><td>good</td></tr></tbody></table>

Very shallow and very broad surrogate model could have a high flexibility, conversely to intermediate solutions. Expected precision is inversely proportional to the complexity of the underlying physics, and therefore to the proportion of ASTEC replaced by the surrogate model. Conversely, expected performance is proportional to the complexity.
Because the main contributors (CESAR and ICARE) are deactivated, the post-rupture phase is very quick. Expected performance of surrogate models that do the computation time-step by time-step is low. That phase would be preferably modeled by a surrogate model that "finishes" the computation in a single shot.

Given the state $X_t$ at time $t$ and the surrogate model function $f$, the properties of the two directions are shown in table 1.

<table><caption>Table 1: Properties of surrogate models following two directions</caption><thead><tr><th>Before TRUPT</th><th>After TRUPT</th></tr></thead><tbody><tr><td>$f: X_t \rightarrow X_{t=t+dt}$</td><td>$f: X_{t=TRUPT} \rightarrow X_{t=end}$</td></tr><tr><td>Call $f$ $n$ times to compute $t \rightarrow t + n * dt$</td><td>Call $f$ once to compute TRUPT $\rightarrow END$</td></tr><tr><td>One time-step is one data point</td><td>One simulation is on one data point</td></tr></tbody></table>

As for the part of the system the surrogate model would focus on, ICARE and CESAR obviously carry our main focus. The following options have taken the edge:

1. Replacing CESAR in the PRIMARY component.

2. Replacing CESAR in the SECONDAR component.

3. Replacing CESAR in the VESSEL component.

4. Replacing ICARE (in the VESSEL component).

5. Replacing CESAR and ICARE in the vessel component.

The expected properties of the aforementioned directions are shown in table 2.

<table><caption>Table 2: Expectations of directions along three criteria</caption><thead><tr><th>Direction</th><th>Expected performance</th><th>Expected precision</th><th>Expected flexibility</th></tr></thead><tbody><tr><td>CESAR in PRIMARY and<br>CESAR in SECONDAR</td><td>medium</td><td>medium</td><td>good</td></tr><tr><td>CESAR in VESSEL</td><td>good</td><td>low</td><td>low</td></tr><tr><td>ICARE in VESSEL</td><td>very good</td><td>low</td><td>low</td></tr><tr><td>CESAR-ICARE in VESSEL</td><td>excellent</td><td>very low</td><td>good</td></tr></tbody></table>

Very shallow and very broad surrogate model could have a high flexibility, conversely to intermediate solutions. Expected precision is inversely proportional to the complexity of the underlying physics, and therefore to the proportion of ASTEC replaced by the surrogate model. Conversely, expected performance is proportional to the complexity.
# 3 Advances and perspectives

Progress on several fields have been made during the internship.

## 3.1 Input-Output identification

As seen in 2.2, developing surrogate models requires the identification of input and output variables. Output variables have been defined as variables the surrogate model should predict. When replacing a module like CESAR, it is not necessary to predict everything CESAR previously predicted. There are several categories of output variables:

* Variables needed by other modules are required. For instance, a CESAR surrogate model needs to compute momentums because SOPHAEROS uses them to move fission products.

* Variables that carry meaningful information the surrogate model can learn should be included. For instance, walls temperatures for CESAR.

* Variables that can be recomputed from other more "fundamental" variables should be excluded. For instance, a CESAR surrogate model should not include pressure in volumes as it can be recomputed from partial pressures.

Input variables have been defined as variables needed to predict output variables. There are also several categories of such variables:

* Boundary conditions are required. Whether it is an output of another module or some driving (open or closed valve, on or off pump...) information, it carries information that influences the output so must be included in the input.

* Output variables themselves that are not pure postprocessing are recommended. Predict a variable at $t + dt$ is easier knowing the value of the variable at $t$. Moreover, as we specifically chose output variables as "meaningful" variables, it is logical to add them to the input.

Both definitions of input and output variables are not strict, especially when it comes to being "meaningful", or "depending on". Evaluating those criteria also needs to take into account the total amount of data collected. Including more variables means greater model complexity, but also more storage space needed. Conversely, including less variables might lead to "forgotten variables" that could reduce model precision.

The WP3 consists in building a large database of ASTEC calculation. The binary ODESSA bases that would be collected are too large to be fully exploited. A better understanding of each variable role in the calculation is needed to reduce the amount of data considered. It is expected that a relatively small subset of all variables is sufficient to drive the entire simulation, while other variables could theoretically be recomputed from that subset. This subset is defined as a
# 3 Advances and perspectives

Progress on several fields have been made during the internship.

## 3.1 Input-Output identification

As seen in 2.2, developing surrogate models requires the identification of input and output variables. Output variables have been defined as variables the surrogate model should predict. When replacing a module like CESAR, it is not necessary to predict everything CESAR previously predicted. There are several categories of output variables:

* Variables needed by other modules are required. For instance, a CESAR surrogate model needs to compute momentums because SOPHAEROS uses them to move fission products.

* Variables that carry meaningful information the surrogate model can learn should be included. For instance, walls temperatures for CESAR.

* Variables that can be recomputed from other more "fundamental" variables should be excluded. For instance, a CESAR surrogate model should not include pressure in volumes as it can be recomputed from partial pressures.

Input variables have been defined as variables needed to predict output variables. There are also several categories of such variables:

* Boundary conditions are required. Whether it is an output of another module or some driving (open or closed valve, on or off pump...) information, it carries information that influences the output so must be included in the input.

* Output variables themselves that are not pure postprocessing are recommended. Predict a variable at $t + dt$ is easier knowing the value of the variable at $t$. Moreover, as we specifically chose output variables as "meaningful" variables, it is logical to add them to the input.

Both definitions of input and output variables are not strict, especially when it comes to being "meaningful", or "depending on". Evaluating those criteria also needs to take into account the total amount of data collected. Including more variables means greater model complexity, but also more storage space needed. Conversely, including less variables might lead to "forgotten variables" that could reduce model precision.

The WP3 consists in building a large database of ASTEC calculation. The binary ODESSA bases that would be collected are too large to be fully exploited. A better understanding of each variable role in the calculation is needed to reduce the amount of data considered. It is expected that a relatively small subset of all variables is sufficient to drive the entire simulation, while other variables could theoretically be recomputed from that subset. This subset is defined as a
"filter" file that can be passed as an argument to ASTEC to only save part of the ODESSA base at each time-step.

A filter with two levels of precision has been produced:

1. Full filter: the smallest subset that is large enough to reproduce an *exact* ASTEC calculation. It excludes all post-processing variables. It can be validated with an application test, see 11

2. Reduced filter: subset of the previous, that excludes variables that are not considered "meaningful" enough. This of course is a subjective definition and can only be validated empirically.

<figure><img src="image_12.png" /><figcaption>Figure 11: Validation process</figcaption></figure>

A variable can be both "mandatory to reproduce *exact* ASTEC calculation" and not meaningful for two main reasons.

* It could be easily recomputed but is currently not. If it were, it wouldn't be mandatory anymore. It is reasonable to exclude it from surrogate model considerations. Once the surrogate model is trained and tested, slight adjustment to ASTEC source code will be necessary to recompute such variables.

* It is indirectly used. For instance, SENSORS are global variables that can be used in postprocessing and/or triggering EVENTS. Because SENSORS can rely on any variable, even post-processing variables are mandatory to restart an exact ASTEC calculation. Reordering calculations and maybe rewriting some sensors should be sufficient to remove those "indirectly used" variables from the reduced filter.

Those two filters, and especially the reduced one are a prerequisite for the work of WP3. Maintaining consistency among the data from different calculations in the constituted database requires keeping it constant. An application test validating the full filter is now set up in ASTEC code base, and the filter has been sent to all partners.
"filter" file that can be passed as an argument to ASTEC to only save part of the ODESSA base at each time-step.

A filter with two levels of precision has been produced:

1. Full filter: the smallest subset that is large enough to reproduce an *exact* ASTEC calculation. It excludes all post-processing variables. It can be validated with an application test, see 11

2. Reduced filter: subset of the previous, that excludes variables that are not considered "meaningful" enough. This of course is a subjective definition and can only be validated empirically.

<figure><img src="image_12.png" /><figcaption>Figure 11: Validation process</figcaption></figure>

A variable can be both "mandatory to reproduce *exact* ASTEC calculation" and not meaningful for two main reasons.

* It could be easily recomputed but is currently not. If it were, it wouldn't be mandatory anymore. It is reasonable to exclude it from surrogate model considerations. Once the surrogate model is trained and tested, slight adjustment to ASTEC source code will be necessary to recompute such variables.

* It is indirectly used. For instance, SENSORS are global variables that can be used in postprocessing and/or triggering EVENTS. Because SENSORS can rely on any variable, even post-processing variables are mandatory to restart an exact ASTEC calculation. Reordering calculations and maybe rewriting some sensors should be sufficient to remove those "indirectly used" variables from the reduced filter.

Those two filters, and especially the reduced one are a prerequisite for the work of WP3. Maintaining consistency among the data from different calculations in the constituted database requires keeping it constant. An application test validating the full filter is now set up in ASTEC code base, and the filter has been sent to all partners.
## 3.2 Directions for surrogate models

Different criteria have been established in section 2.3, and some directions have been discussed. The work on identification of input and output data in section 3.1 has, indirectly, highlighted several issues that could influence the considered directions. CESAR and ICARE are the main considered modules, according to the performance criteria mentioned previously.

The following parts focuses on surrogate models of those modules, but other modules (especially SOPHAEROS) are also considered because of how they influence the structure of the surrogate model. Issues that have been raised can be split in two categories: those that are related to time-steps and those that are related to the flexibility criteria mentioned previously.

### 3.2.1 Time-step related issues

Time step management is a topic in itself for ASTEC. Different modules only interact with each-other every macro-time-step. However, it is not the case for CESAR and ICARE modules, as detailed previously.

Developing surrogate models of CESAR alone and ICARE alone appears to be too complicated. For ICARE, training such model would require saving input and output variables every ICARE internal time-step. This is not currently possible. It would require a significant amount of work from ASTEC developers, with a short deadline (end of year ASTEC-release). For CESAR, there are two slight differences. Unlike ICARE, it is currently being implemented and could be available in a near future. But CESAR time-step is lower that ICARE time-step (CESAR computation appends during an ICARE time-step). Saving all CESAR data at such a small time-step would produce unmanageable amounts of data.

ASTEC macro-time-step is an aspect that requires the surrogate-model designer to make a decision: should it be a constant or a model parameter ?

1. A parameterized macro-time-step *dt* would be included in input data of the model. The model would be trained to predict output variables at *t* + *dt*. This increases the complexity of the model, because it increases the non-linearity relations between input and output parameters. With an adaptable macro-time-step, ASTEC needs feedback from modules to choose whether keeping it, increasing it or decreasing it. A surrogate model should also provide that feedback to ASTEC, most likely with an output variable indicating the degree of uncertainty of the prediction. That kind of variable is hard to predict.

2. A constant macro-time-step consists in launching ASTEC calculations with a fixed macro-time-step (this is a calculation option). Typical values of such constant macro-time-step is 1 second. When activated, adaptive macro-time-step usually oscillates around that value. Fixed macro-time-step slow down the calculation during steadier phases and degrade precision during fast-evolving phases.
## 3.2 Directions for surrogate models

Different criteria have been established in section 2.3, and some directions have been discussed. The work on identification of input and output data in section 3.1 has, indirectly, highlighted several issues that could influence the considered directions. CESAR and ICARE are the main considered modules, according to the performance criteria mentioned previously.

The following parts focuses on surrogate models of those modules, but other modules (especially SOPHAEROS) are also considered because of how they influence the structure of the surrogate model. Issues that have been raised can be split in two categories: those that are related to time-steps and those that are related to the flexibility criteria mentioned previously.

### 3.2.1 Time-step related issues

Time step management is a topic in itself for ASTEC. Different modules only interact with each-other every macro-time-step. However, it is not the case for CESAR and ICARE modules, as detailed previously.

Developing surrogate models of CESAR alone and ICARE alone appears to be too complicated. For ICARE, training such model would require saving input and output variables every ICARE internal time-step. This is not currently possible. It would require a significant amount of work from ASTEC developers, with a short deadline (end of year ASTEC-release). For CESAR, there are two slight differences. Unlike ICARE, it is currently being implemented and could be available in a near future. But CESAR time-step is lower that ICARE time-step (CESAR computation appends during an ICARE time-step). Saving all CESAR data at such a small time-step would produce unmanageable amounts of data.

ASTEC macro-time-step is an aspect that requires the surrogate-model designer to make a decision: should it be a constant or a model parameter ?

1. A parameterized macro-time-step *dt* would be included in input data of the model. The model would be trained to predict output variables at *t* + *dt*. This increases the complexity of the model, because it increases the non-linearity relations between input and output parameters. With an adaptable macro-time-step, ASTEC needs feedback from modules to choose whether keeping it, increasing it or decreasing it. A surrogate model should also provide that feedback to ASTEC, most likely with an output variable indicating the degree of uncertainty of the prediction. That kind of variable is hard to predict.

2. A constant macro-time-step consists in launching ASTEC calculations with a fixed macro-time-step (this is a calculation option). Typical values of such constant macro-time-step is 1 second. When activated, adaptive macro-time-step usually oscillates around that value. Fixed macro-time-step slow down the calculation during steadier phases and degrade precision during fast-evolving phases.
Fixed macro-time-step seems to be the most realistic option to develop surrogate models.
This is yet another argument in disfavour of ICARE-only and CESAR (VESSEL-component)
only: CESAR and ICARE internal time-steps are variable, and can't reasonably be set constant.

### 3.2.2 Flexibility related issues

ICARE-only and CESAR-only surrogate models also have issues related to the flexibility criteria and the precision criteria. During the computation, especially during the core degradation phase, the geometry evolves due to material relocation in particular. As components of the vessel degrade, melt, mix together in corium, water and steam flow differently through the vessel. If one of the two modules is replaced by a surrogate model, it needs to include as input or output variables respectively the state of the mesh, which greatly increases model size. But this state is an information that is difficult to encode in a fixed-sized array of floating-point variables. Most techniques tend to use sparse storage, that are difficult to feed into a neural network, or full storage, that produce very large files.

### 3.2.3 Updated directions for surrogate models

Compared to what was expected at the beginning of the project, new decisions have been
made about what directions look the most favourable.

* Input and output variables should be present in the reduced filter.

* The size of input and output is a compromise between -

- Storage space, IO cost and model complexity for greater size

- Model precision for lower size

* ICARE-only and CESAR-only in the VESSEL component appear too complicated.

* Variables should be saved at every macro-time-step, the macro-time-step should be constant.
Fixed macro-time-step seems to be the most realistic option to develop surrogate models. This is yet another argument in disfavour of ICARE-only and CESAR (VESSEL-component) only: CESAR and ICARE internal time-steps are variable, and can't reasonably be set constant.

### 3.2.2 Flexibility related issues

ICARE-only and CESAR-only surrogate models also have issues related to the flexibility criteria and the precision criteria. During the computation, especially during the core degradation phase, the geometry evolves due to material relocation in particular. As components of the vessel degrade, melt, mix together in corium, water and steam flow differently through the vessel. If one of the two modules is replaced by a surrogate model, it needs to include as input or output variables respectively the state of the mesh, which greatly increases model size. But this state is an information that is difficult to encode in a fixed-sized array of floating-point variables. Most techniques tend to use sparse storage, that are difficult to feed into a neural network, or full storage, that produce very large files.

### 3.2.3 Updated directions for surrogate models

Compared to what was expected at the beginning of the project, new decisions have been made about what directions look the most favourable.

* Input and output variables should be present in the reduced filter.

* The size of input and output is a compromise between -

- Storage space, IO cost and model complexity for greater size

- Model precision for lower size

* ICARE-only and CESAR-only in the VESSEL component appear too complicated.

* Variables should be saved at every macro-time-step, the macro-time-step should be constant.
## 3.3 Steam generator surrogate modeling

Steam generators are a subset of the system a surrogate model could handle, following the previously stated criteria. They have several advantages:

* They have few boundary conditions:

- Hot and cold legs in the primary circuit

- ARE and steam line in the secondary circuit

- Safety systems and potential breaches (one CONNECTI for each): ASG, APG and RTGV.

* There are four identical of steam generators. A single surrogate model would have a quadrupled impact.

* Only CESAR and SOPHAEROS are involved in computation in the steam generators.

For those reasons, a surrogate model of steam generators has been built, following the three steps mentioned in section 2.2, plus a last one: plugging it in back in ASTEC.

### 3.3.1 Identifying inputs and outputs

Primary and secondary circuit are independent components in ASTEC mesh. They can interact through two means:

* Heat exchange through the U-tube

* Mass and energy exchange through an hypothetical RTGV, modeled by a CONNECTI.

Boundaries of the steam generator are defined (arbitrary) as:

* Hot box: first mesh element of the PRIMARY side of the steam generator to which the hot leg flows.

* Cold box: last mesh element of the PRIMARY side of the steam generator, from which the cold leg flows.

* Steam line: last mesh element of the SECONDARY side of the steam generator, from which the steam line flows.

* ARE: CONNECTI modelling normal conditions feedwater line.

* ASG: CONNECTI modelling abnormal conditions feedwater line.

* APG: CONNECTI modelling normal and abnormal conditions purging line.
## 3.3 Steam generator surrogate modeling

Steam generators are a subset of the system a surrogate model could handle, following the previously stated criteria. They have several advantages:

* They have few boundary conditions:

- Hot and cold legs in the primary circuit

- ARE and steam line in the secondary circuit

- Safety systems and potential breaches (one CONNECTI for each): ASG, APG and RTGV.

* There are four identical of steam generators. A single surrogate model would have a quadrupled impact.

* Only CESAR and SOPHAEROS are involved in computation in the steam generators.

For those reasons, a surrogate model of steam generators has been built, following the three steps mentioned in section 2.2, plus a last one: plugging it in back in ASTEC.

### 3.3.1 Identifying inputs and outputs

Primary and secondary circuit are independent components in ASTEC mesh. They can interact through two means:

* Heat exchange through the U-tube

* Mass and energy exchange through an hypothetical RTGV, modeled by a CONNECTI.

Boundaries of the steam generator are defined (arbitrary) as:

* Hot box: first mesh element of the PRIMARY side of the steam generator to which the hot leg flows.

* Cold box: last mesh element of the PRIMARY side of the steam generator, from which the cold leg flows.

* Steam line: last mesh element of the SECONDARY side of the steam generator, from which the steam line flows.

* ARE: CONNECTI modelling normal conditions feedwater line.

* ASG: CONNECTI modelling abnormal conditions feedwater line.

* APG: CONNECTI modelling normal and abnormal conditions purging line.
* RTGV: even though it models internal behaviour of the steam generator, it is triggered by events, user actions or induced breaches, therefore externally.

There are four types of mesh elements inside the steam generator (VOLUME, JUNCTION, WALL and CONNECTI), each one providing several variables, and SENSORS providing a single value. After applying criteria discussed in section 3.1, the following table can be established:

<table><caption>Table 3: Input and output variables of a steam generator</caption><thead><tr><th>Variable name</th><th>Description</th><th>Is input</th><th>Is output</th></tr></thead><tbody><tr><td>VOLUME: P_h2</td><td>H2 partial pressure</td><td>Yes</td><td>Yes</td></tr><tr><td>VOLUME: P_n2</td><td>N2 partial pressure</td><td>Yes</td><td>Yes</td></tr><tr><td>VOLUME: P_bho2</td><td>BHO2 partial pressure</td><td>Yes</td><td>Yes</td></tr><tr><td>VOLUME: P_co2</td><td>CO2 partial pressure</td><td>Yes</td><td>Yes</td></tr><tr><td>VOLUME: T_gas</td><td>gas temperature</td><td>Yes</td><td>Yes</td></tr><tr><td>VOLUME: T_liq</td><td>liquid temperature</td><td>Yes</td><td>Yes</td></tr><tr><td>VOLUME: P_steam</td><td>steam partial pressure</td><td>Yes</td><td>Yes</td></tr><tr><td>VOLUME: x_alfa</td><td>liquid mass fraction</td><td>Yes</td><td>Yes</td></tr><tr><td>VOLUME: x_alfa1</td><td>liquid mass fraction for two phases volumes</td><td>Yes</td><td>Yes</td></tr><tr><td>VOLUME: fp_power</td><td>fission products power</td><td>Yes</td><td>No</td></tr><tr><td>JUNCTION: CLOSE</td><td>whether the junction is closed or not (categorical)</td><td>Yes</td><td>No</td></tr><tr><td>JUNCTION: v_gas</td><td>gas speed</td><td>Yes</td><td>Yes</td></tr><tr><td>JUNCTION: v_liq</td><td>liquid speed</td><td>Yes</td><td>Yes</td></tr><tr><td>WALL: T_wall</td><td>temperature of the wall</td><td>Yes</td><td>Yes</td></tr><tr><td>CONNECTI: FLOW[1]</td><td>mass flow</td><td>Yes</td><td>Yes</td></tr><tr><td>CONNECTI: FLOW[2]</td><td>energy flow</td><td>Yes</td><td>Yes</td></tr><tr><td>CONNECTI: SECT</td><td>section of the connecti</td><td>Yes</td><td>No</td></tr><tr><td>CONNECTI: STAT</td><td>status of the connecti ('ON' or 'OFF')</td><td>Yes</td><td>No</td></tr><tr><td>SENSORS: TX_GV</td><td>SG recirculation rate</td><td>No</td><td>Yes</td></tr><tr><td>SENSORS: NGE_GV</td><td>SG level (narrow band)</td><td>No</td><td>Yes</td></tr><tr><td>SENSORS: NGL_GV</td><td>SG level (wide band)</td><td>No</td><td>Yes</td></tr><tr><td>SENSORS: ML_GV</td><td>liquid mass in the SG</td><td>No</td><td>Yes</td></tr><tr><td>SENSORS: MV_GV</td><td>steam mass in the SG</td><td>No</td><td>Yes</td></tr><tr><td>SENSORS: PUIS_GV</td><td>SG thermal power</td><td>No</td><td>Yes</td></tr><tr><td>SENSORS: QEGV</td><td>input water flow rate to the SG</td><td>No</td><td>Yes</td></tr><tr><td>SENSORS: QSGV</td><td>output water flow rate from the SG</td><td>No</td><td>Yes</td></tr><tr><td>SENSORS: P_GV</td><td>pressure in the SG</td><td>No</td><td>Yes</td></tr><tr><td>SENSORS: PGV_TBF</td><td>transformation of SG pressure with cold leg temperature</td><td>No</td><td>Yes</td></tr><tr><td>SENSORS: PGV_STA</td><td>transformation of SG pressure with temperature stabilisation</td><td>No</td><td>Yes</td></tr></tbody></table>

There are 373 total input variables, and 313 total output variables.

Now the input and output variables are strictly identified, pre-processing and post-processing have to be defined.
* RTGV: even though it models internal behaviour of the steam generator, it is triggered by events, user actions or induced breaches, therefore externally.

There are four types of mesh elements inside the steam generator (VOLUME, JUNCTION, WALL and CONNECTI), each one providing several variables, and SENSORS providing a single value. After applying criteria discussed in section 3.1, the following table can be established:

<table><caption>Table 3: Input and output variables of a steam generator</caption><thead><tr><th>Variable name</th><th>Description</th><th>Is input</th><th>Is output</th></tr></thead><tbody><tr><td>VOLUME: P_h2</td><td>H2 partial pressure</td><td>Yes</td><td>Yes</td></tr><tr><td>VOLUME: P_n2</td><td>N2 partial pressure</td><td>Yes</td><td>Yes</td></tr><tr><td>VOLUME: P_bho2</td><td>BHO2 partial pressure</td><td>Yes</td><td>Yes</td></tr><tr><td>VOLUME: P_co2</td><td>CO2 partial pressure</td><td>Yes</td><td>Yes</td></tr><tr><td>VOLUME: T_gas</td><td>gas temperature</td><td>Yes</td><td>Yes</td></tr><tr><td>VOLUME: T_liq</td><td>liquid temperature</td><td>Yes</td><td>Yes</td></tr><tr><td>VOLUME: P_steam</td><td>steam partial pressure</td><td>Yes</td><td>Yes</td></tr><tr><td>VOLUME: x_alfa</td><td>liquid mass fraction</td><td>Yes</td><td>Yes</td></tr><tr><td>VOLUME: x_alfa1</td><td>liquid mass fraction for two phases volumes</td><td>Yes</td><td>Yes</td></tr><tr><td>VOLUME: fp_power</td><td>fission products power</td><td>Yes</td><td>No</td></tr><tr><td>JUNCTION: CLOSE</td><td>whether the junction is closed or not (categorical)</td><td>Yes</td><td>No</td></tr><tr><td>JUNCTION: v_gas</td><td>gas speed</td><td>Yes</td><td>Yes</td></tr><tr><td>JUNCTION: v_liq</td><td>liquid speed</td><td>Yes</td><td>Yes</td></tr><tr><td>WALL: T_wall</td><td>temperature of the wall</td><td>Yes</td><td>Yes</td></tr><tr><td>CONNECTI: FLOW[1]</td><td>mass flow</td><td>Yes</td><td>Yes</td></tr><tr><td>CONNECTI: FLOW[2]</td><td>energy flow</td><td>Yes</td><td>Yes</td></tr><tr><td>CONNECTI: SECT</td><td>section of the connecti</td><td>Yes</td><td>No</td></tr><tr><td>CONNECTI: STAT</td><td>status of the connecti ('ON' or 'OFF')</td><td>Yes</td><td>No</td></tr><tr><td>SENSORS: TX_GV</td><td>SG recirculation rate</td><td>No</td><td>Yes</td></tr><tr><td>SENSORS: NGE_GV</td><td>SG level (narrow band)</td><td>No</td><td>Yes</td></tr><tr><td>SENSORS: NGL_GV</td><td>SG level (wide band)</td><td>No</td><td>Yes</td></tr><tr><td>SENSORS: ML_GV</td><td>liquid mass in the SG</td><td>No</td><td>Yes</td></tr><tr><td>SENSORS: MV_GV</td><td>steam mass in the SG</td><td>No</td><td>Yes</td></tr><tr><td>SENSORS: PUIS_GV</td><td>SG thermal power</td><td>No</td><td>Yes</td></tr><tr><td>SENSORS: QEGV</td><td>input water flow rate to the SG</td><td>No</td><td>Yes</td></tr><tr><td>SENSORS: QSGV</td><td>output water flow rate from the SG</td><td>No</td><td>Yes</td></tr><tr><td>SENSORS: P_GV</td><td>pressure in the SG</td><td>No</td><td>Yes</td></tr><tr><td>SENSORS: PGV_TBF</td><td>transformation of SG pressure with cold leg temperature</td><td>No</td><td>Yes</td></tr><tr><td>SENSORS: PGV_STA</td><td>transformation of SG pressure with temperature stabilisation</td><td>No</td><td>Yes</td></tr></tbody></table>

There are 373 total input variables, and 313 total output variables.

Now the input and output variables are strictly identified, pre-processing and post-processing have to be defined.
Pre-processing consists in several steps:

1. Loading binary savings of ODESSA bases (having the reduced filter applied)

2. Writing the content of the previously mentioned variables for the ODESSA base to a DataFrame (Python object from pandas [?] library) A Python library called "fluent" has been developed to ease that process.

3. DataFrames are stored to files with a pickle (Python binary format) compressed format. That intermediate storage format is completely independent from ASTEC, so Python is the only mandatory tool. It also reduces IO cost, as the files only contains useful variables, as opposed to the ODESSA binary format.

4. When working on surrogate models, DataFrames are loaded

5. Categorical data (strings 'ON'/'OFF' and 'OPEN'/'CLOSE') are converted to integer (0-1)

6. DataFrames are normalized (to 0-mean and 1-standard deviation).

7. Some oscillating variables are smoothed, thanks to a rolling-mean computation.

8. DataFrames are converted to Tensor format (Python object from Tensorflow library)

9. Input and output variables are separated, to two separate Tensors.

10. Input tensor is windowed

Post-processing consists in reversing all previous pre-processing steps. The only difference is that the intermediate DataFrame format is used, data is passed from Tensors to ASTEC directly. This post-processing step is not necessary to build and train surrogate model. It is only mandatory when the surrogate model is put back in ASTEC.

### 3.3.2 Building surrogate model

The surrogate model *M* is a neural network with the following dimensions:

$$ \left\{ \begin{array}{ll} M: & \mathbb{R}^{n_w \times n_i} \rightarrow \mathbb{R}^{n_o} \\ n_w: & \text{window size} = 5 \\ n_i: & \text{input size} = 373 \\ n_o: & \text{output size} = 313 \end{array} \right. \qquad (2) $$

The number and type of internal layers, their size, their connexions are up to the surrogate model designer.

Time series prediction has been a hot topic in machine learning, especially in the financial field. Sequential input processing has also been a hot topic recently, especially in the text processing field with Large Language Model (LLM).
Pre-processing consists in several steps:

1. Loading binary savings of ODESSA bases (having the reduced filter applied)

2. Writing the content of the previously mentioned variables for the ODESSA base to a DataFrame (Python object from pandas [?] library) A Python library called "fluent" has been developed to ease that process.

3. DataFrames are stored to files with a pickle (Python binary format) compressed format. That intermediate storage format is completely independent from ASTEC, so Python is the only mandatory tool. It also reduces IO cost, as the files only contains useful variables, as opposed to the ODESSA binary format.

4. When working on surrogate models, DataFrames are loaded

5. Categorical data (strings 'ON'/'OFF' and 'OPEN'/'CLOSE') are converted to integer (0-1)

6. DataFrames are normalized (to 0-mean and 1-standard deviation).

7. Some oscillating variables are smoothed, thanks to a rolling-mean computation.

8. DataFrames are converted to Tensor format (Python object from Tensorflow library)

9. Input and output variables are separated, to two separate Tensors.

10. Input tensor is windowed

Post-processing consists in reversing all previous pre-processing steps. The only difference is that the intermediate DataFrame format is used, data is passed from Tensors to ASTEC directly. This post-processing step is not necessary to build and train surrogate model. It is only mandatory when the surrogate model is put back in ASTEC.

### 3.3.2 Building surrogate model

The surrogate model *M* is a neural network with the following dimensions:

$$ \left\{ \begin{array}{ll} M: & \mathbb{R}^{n_w \times n_i} \rightarrow \mathbb{R}^{n_o} \\ n_w: & \text{window size} = 5 \\ n_i: & \text{input size} = 373 \\ n_o: & \text{output size} = 313 \end{array} \right. \qquad (2) $$

The number and type of internal layers, their size, their connexions are up to the surrogate model designer.

Time series prediction has been a hot topic in machine learning, especially in the financial field. Sequential input processing has also been a hot topic recently, especially in the text processing field with Large Language Model (LLM).
<figure><img src="image_13.png" /><figcaption>Figure 12: LSTM internal structure</figcaption></figure>

Fast advances have been made with Recurrent Neural Network (RNN) [?]. RNNs can be seen as neural network with its output wired to its input. They consist in a cell, that is a classical neural network, and a wiring mechanism that holds a state around this cell and processes inputs sequentially. Their ability to process input sequentially makes them good at time-series predicting, when inputs are highly autocorrelated in the forward direction. One of their drawbacks is the exploding/vanishing gradient issue. This issue can impact backpropagation in too deep neural networks, and recurrent neural networks are equivalent to an arbitrarily deep neural network.

Long Short Term Memory (LSTM) [?] neural networks are a type of RNN that avoid this exploding/vanishing gradient issue. Specific internal processing enables gradients to be kept consistent over forward passes of input. Fig 12 shows that internal structure, with:

1. $x_t$ the input time sequence

2. $o_t$ the output time sequence

3. $c_t$ the cell input time sequence, internal to the LSTM

4. $h_t$ the cell output time sequence, internal to the LSTM

LSTMs have outperformed many other architectures in several benchmarks.

Steam generator surrogate model would likely benefit from such properties. Therefore, four surrogate models have been evaluated for a benchmark

* A baseline, as a reference, that consists in a single dense layer with an identity activation function, see fig 13a. It is theoretically equivalent to a linear regression, but treating it as any other neural network enables easier comparison with the three others proposed architectures, especially for training phase.

* A Small LSTM Only (SLO), see Fig 13b "Small" indicates that the output of the LSTM layer has a size of 50 (compared to the 5 × 371 size of the input)
<figure><img src="image_13.png" /><figcaption>Figure 12: LSTM internal structure</figcaption></figure>

Fast advances have been made with Recurrent Neural Network (RNN) [?]. RNNs can be seen as neural network with its output wired to its input. They consist in a cell, that is a classical neural network, and a wiring mechanism that holds a state around this cell and processes inputs sequentially. Their ability to process input sequentially makes them good at time-series predicting, when inputs are highly autocorrelated in the forward direction. One of their drawbacks is the exploding/vanishing gradient issue. This issue can impact backpropagation in too deep neural networks, and recurrent neural networks are equivalent to an arbitrarily deep neural network.

Long Short Term Memory (LSTM) [?] neural networks are a type of RNN that avoid this exploding/vanishing gradient issue. Specific internal processing enables gradients to be kept consistent over forward passes of input. Fig 12 shows that internal structure, with:

1. $x_t$ the input time sequence

2. $o_t$ the output time sequence

3. $c_t$ the cell input time sequence, internal to the LSTM

4. $h_t$ the cell output time sequence, internal to the LSTM

LSTMs have outperformed many other architectures in several benchmarks.

Steam generator surrogate model would likely benefit from such properties. Therefore, four surrogate models have been evaluated for a benchmark

* A baseline, as a reference, that consists in a single dense layer with an identity activation function, see fig 13a. It is theoretically equivalent to a linear regression, but treating it as any other neural network enables easier comparison with the three others proposed architectures, especially for training phase.

* A Small LSTM Only (SLO), see Fig 13b "Small" indicates that the output of the LSTM layer has a size of 50 (compared to the 5 × 371 size of the input)
* A Large LSTM Only (LLO), see Fig 13b "Large" indicates that the output of the LSTM layer has a size of 500 (compared to the 5 × 371 size of the input)

* A Medium LSTM with Shortcut (MLS), see Fig 13c The output of the LSTM layer has a size of 200

For SLO, LLO and MLS, three dense layers are added after the LSTM (or the concatenation layer for MLS), to map the LSTM output to the true output. Expecting the LSTM layer to output the right values directly would overconstrain it, and make the training process harder. It is a common practice to add dense layers on top of a model, because they are very flexible and not very costly. They don't learn complex dynamics however, which is the role of the core of the model: the LSTM layer.

<figure><img src="image_14.png" /><figcaption>Figure 13: Baseline, SLO/LLO and MLS surrogate model structure</figcaption></figure>

Arrows in fig 13 are computational links between operators. Links between layers are chosen by the model designer. Other links are generated by the library Tensorflow [?], especially to collect metrics and prepare backpropagation. Both type of links form the "computational graph".

For reference, the graph in fig 14 shows all the links (chosen by the designer and generated) between all elements involved in the training-testing process. It shows how cost-saving the use of a library like Tensorflow is to automate complex learning process, and only focus on pre-processing, model design, training and testing.

### 3.3.3 Training surrogate model

The training process consists in finding the optimal weights for a given model, a given dataset, and a given loss function. It is divided in several "epochs", ran sequentially, each of them consisting in feeding the entire dataset forward and backwards (backpropagation) through the model. This task will be applied to each of the previous models.
* A Large LSTM Only (LLO), see Fig 13b "Large" indicates that the output of the LSTM layer has a size of 500 (compared to the 5 × 371 size of the input)

* A Medium LSTM with Shortcut (MLS), see Fig 13c The output of the LSTM layer has a size of 200

For SLO, LLO and MLS, three dense layers are added after the LSTM (or the concatenation layer for MLS), to map the LSTM output to the true output. Expecting the LSTM layer to output the right values directly would overconstrain it, and make the training process harder. It is a common practice to add dense layers on top of a model, because they are very flexible and not very costly. They don't learn complex dynamics however, which is the role of the core of the model: the LSTM layer.

<figure><img src="image_14.png" /><figcaption>Figure 13: Baseline, SLO/LLO and MLS surrogate model structure</figcaption></figure>

Arrows in fig 13 are computational links between operators. Links between layers are chosen by the model designer. Other links are generated by the library Tensorflow [?], especially to collect metrics and prepare backpropagation. Both type of links form the "computational graph".

For reference, the graph in fig 14 shows all the links (chosen by the designer and generated) between all elements involved in the training-testing process. It shows how cost-saving the use of a library like Tensorflow is to automate complex learning process, and only focus on pre-processing, model design, training and testing.

### 3.3.3 Training surrogate model

The training process consists in finding the optimal weights for a given model, a given dataset, and a given loss function. It is divided in several "epochs", ran sequentially, each of them consisting in feeding the entire dataset forward and backwards (backpropagation) through the model. This task will be applied to each of the previous models.
<figure><img src="image_15.png" /><figcaption>Figure 14: Computation graph for the LLO model</figcaption></figure>

The loss function will be a mean squared error function. This function is the most commonly used loss function for training processes. Because all output are normalized (during the pre-processing phase), the "square" part of the loss function penalizes equally all output variables. As opposed to absolute mean error, it penalizes more large differences between actual and expected output. This tends to accelerate the initial phase of training, where large differences are more common.

The dataset is the output of the pre-processing phase, applied to 16 different ASTEC calculations. The chosen scenarios are SBO combined with LOCA, with the parameters shown in table 4.

SBO means that the following systems are unavailable, right from the beginning of the scenario:

* Containment spray system (EAS)

* Automatic borication system (FBA)

* Steam Generator safety water supply (ASG)

* Steam Generator regular water supply (ARE)

* Safety injection medium pressure (ISMP)

* Safety injection low pressure (ISBP)
<figure><img src="image_15.png" /><figcaption>Figure 14: Computation graph for the LLO model</figcaption></figure>

The loss function will be a mean squared error function. This function is the most commonly used loss function for training processes. Because all output are normalized (during the pre-processing phase), the "square" part of the loss function penalizes equally all output variables. As opposed to absolute mean error, it penalizes more large differences between actual and expected output. This tends to accelerate the initial phase of training, where large differences are more common.

The dataset is the output of the pre-processing phase, applied to 16 different ASTEC calculations. The chosen scenarios are SBO combined with LOCA, with the parameters shown in table 4.

SBO means that the following systems are unavailable, right from the beginning of the scenario:

* Containment spray system (EAS)

* Automatic borication system (FBA)

* Steam Generator safety water supply (ASG)

* Steam Generator regular water supply (ARE)

* Safety injection medium pressure (ISMP)

* Safety injection low pressure (ISBP)
<table><caption>Table 4: Scenarios used for training phase</caption><thead><tr><td>Scenario</td><td>Time of breach (s)</td><td>Section of LOCA (m²)</td></tr></thead><tbody><tr><td>0</td><td>0</td><td>0.01</td></tr><tr><td>1</td><td>0</td><td>0.05</td></tr><tr><td>2</td><td>0</td><td>0.03</td></tr><tr><td>3</td><td>0</td><td>0.1</td></tr><tr><td>4</td><td>100</td><td>0.01</td></tr><tr><td>5</td><td>100</td><td>0.05</td></tr><tr><td>6</td><td>100</td><td>0.03</td></tr><tr><td>7</td><td>100</td><td>0.1</td></tr><tr><td>8</td><td>150</td><td>0.01</td></tr><tr><td>9</td><td>150</td><td>0.05</td></tr><tr><td>10</td><td>150</td><td>0.03</td></tr><tr><td>11</td><td>150</td><td>0.1</td></tr><tr><td>12</td><td>200</td><td>0.01</td></tr><tr><td>13</td><td>200</td><td>0.05</td></tr><tr><td>14</td><td>200</td><td>0.03</td></tr><tr><td>15</td><td>200</td><td>0.1</td></tr></tbody></table>

Each computation runs for 5000 seconds, with a macro-time-step of 1 second. There is a total of 80000 instants. Each instant provides data from 4 steam generators, so 320000 total data points. With windowing, the *window_size* = 5 first instants are listed, so $16 \times (5-1) \times 4 = 256$ incomplete data points. In total, there are 319734 available data points, each providing an input of size 371 and an output of size 313.

There is a slight adjustment to what has been described in section 3.1 for the pre-processing tasks. The computation of the mean and the standard deviation of all variables is done for all 16 calculations. But the windowing process is done for the data of each calculation separately: the end of the scenario 4 has nothing to do with the beginning of the scenario 5 for instance.

Validation is a very important part of training a surrogate model. It is done by computing metrics during the training phase, on a subset of the input data. The loss function is the default metric, that is always computed, but other metrics can also be computed. Being able to trace the metrics improvement or worsening helps avoid two unwanted phenomena: underfitting and overfitting, see fig 15.

* Underfitting is a state where the model hasn't learned enough from the input data. It is generally characterized by a decreasing validation loss, often on both training and development. Good practice is to keep training, by running more epochs.

* Overfitting is a state where the model learns the input data "too much". Usually, the model doesn't learn the underlying phenomena but the training data itself, which is unwanted. It is generally characterized by an increasing validation loss while training loss keeps increasing. Good practice is to stop learning, and/or to work on the design of the model itself.
<table><caption>Table 4: Scenarios used for training phase</caption><thead><tr><td>Scenario</td><td>Time of breach (s)</td><td>Section of LOCA (m²)</td></tr></thead><tbody><tr><td>0</td><td>0</td><td>0.01</td></tr><tr><td>1</td><td>0</td><td>0.05</td></tr><tr><td>2</td><td>0</td><td>0.03</td></tr><tr><td>3</td><td>0</td><td>0.1</td></tr><tr><td>4</td><td>100</td><td>0.01</td></tr><tr><td>5</td><td>100</td><td>0.05</td></tr><tr><td>6</td><td>100</td><td>0.03</td></tr><tr><td>7</td><td>100</td><td>0.1</td></tr><tr><td>8</td><td>150</td><td>0.01</td></tr><tr><td>9</td><td>150</td><td>0.05</td></tr><tr><td>10</td><td>150</td><td>0.03</td></tr><tr><td>11</td><td>150</td><td>0.1</td></tr><tr><td>12</td><td>200</td><td>0.01</td></tr><tr><td>13</td><td>200</td><td>0.05</td></tr><tr><td>14</td><td>200</td><td>0.03</td></tr><tr><td>15</td><td>200</td><td>0.1</td></tr></tbody></table>

Each computation runs for 5000 seconds, with a macro-time-step of 1 second. There is a total of 80000 instants. Each instant provides data from 4 steam generators, so 320000 total data points. With windowing, the *window_size* = 5 first instants are listed, so $16 \times (5 - 1) \times 4 = 256$ incomplete data points. In total, there are 319734 available data points, each providing an input of size 371 and an output of size 313.

There is a slight adjustment to what has been described in section 3.1 for the pre-processing tasks. The computation of the mean and the standard deviation of all variables is done for all 16 calculations. But the windowing process is done for the data of each calculation separately: the end of the scenario 4 has nothing to do with the beginning of the scenario 5 for instance.

Validation is a very important part of training a surrogate model. It is done by computing metrics during the training phase, on a subset of the input data. The loss function is the default metric, that is always computed, but other metrics can also be computed. Being able to trace the metrics improvement or worsening helps avoid two unwanted phenomena: underfitting and overfitting, see fig 15.

* Underfitting is a state where the model hasn't learned enough from the input data. It is generally characterized by a decreasing validation loss, often on both training and development. Good practice is to keep training, by running more epochs.

* Overfitting is a state where the model learns the input data "too much". Usually, the model doesn't learn the underlying phenomena but the training data itself, which is unwanted. It is generally characterized by an increasing validation loss while training loss keeps increasing. Good practice is to stop learning, and/or to work on the design of the model itself.
<figure><img src="image_16.png" /><figcaption>Figure 15: Underfitting and overfitting phenomena</figcaption></figure>

Avoiding overfitting requires validation data to be independent from training data. At the beginning of the training phase, input data is split in training and validation data, with a ratio of approximately 80%/20%. Increasing that ratio could lead to statistically insignificant validation metrics. Decreasing it reduces the amount of training data, and potentially the precision of the trained model.

The training losses of the four models mentioned in section 3.3.2 are shown in fig 16.

<figure><img src="image_17.png" /><figcaption>(a) Baseline | orange: validation loss | grey: training loss</figcaption></figure>

<figure><img src="image_18.png" /><figcaption>(c) LLO | blue: validation loss | red: training loss</figcaption></figure>

<figure><img src="image_19.png" /><figcaption>(b) SLO | blue: validation loss | orange: training loss</figcaption></figure>

<figure><img src="image_20.png" /><figcaption>(d) MLS | orange: validation loss | grey: training loss</figcaption></figure>

<caption>Figure 16: Surrogate model training/validation MSE-losses for 100 epochs.</caption>

Fig 16 comes from different training phases. The random split of input data between validation and training is different for each step. Y-axis is the Mean Squared Error (MSE) loss on normalized data.

* Baseline: loss in fig 16a seems constant for training and chaotic for validation. Constant training loss indicates that a single epoch is sufficient to train the model. Recall that
<figure><img src="image_16.png" /><figcaption>Figure 15: Underfitting and overfitting phenomena</figcaption></figure>

Avoiding overfitting requires validation data to be independent from training data. At the beginning of the training phase, input data is split in training and validation data, with a ratio of approximately 80%/20%. Increasing that ratio could lead to statistically insignificant validation metrics. Decreasing it reduces the amount of training data, and potentially the precision of the trained model.

The training losses of the four models mentioned in section 3.3.2 are shown in fig 16.

<figure><img src="image_17.png" /><figcaption>(a) Baseline | orange: validation loss | grey: training loss</figcaption></figure>

<figure><img src="image_18.png" /><figcaption>(b) SLO | blue: validation loss | orange: training loss</figcaption></figure>

<figure><img src="image_19.png" /><figcaption>(c) LLO | blue: validation loss | red: training loss</figcaption></figure>

<figure><img src="image_20.png" /><figcaption>(d) MLS | orange: validation loss | grey: training loss</figcaption></figure>

<caption>Figure 16: Surrogate model training/validation MSE-losses for 100 epochs.</caption>

Fig 16 comes from different training phases. The random split of input data between validation and training is different for each step. Y-axis is the Mean Squared Error (MSE) loss on normalized data.

* Baseline: loss in fig 16a seems constant for training and chaotic for validation. Constant training loss indicates that a single epoch is sufficient to train the model. Recall that
baseline is equivalent to a linear regression. Validation loss seems chaotic, most likely
for two reasons:

- Validation data is smaller than training data, leading to greater variance.

- Sudden increases happen in 1 epoch, decreases happen in several epochs. This probably indicates that a few coefficients in the "linear regression" matrix are very significant compared to others. If an input variable varies a lot non-linearly, the baseline model incorrectly predicts it with big impact due to the square in the loss function.

* SLO, LLO and MLS show similar training/validation profiles:

- Validation loss starts lower than training loss: this might be caused by the delay between the computation of both: training loss is evaluated during the epoch, validation is evaluated at the end. The model has made improvement during that delay.

- Training loss then regularly decreases with an exponential profile, which indicates learning-progress by the model.

- Validation loss decreases, then asymptotically oscillates around a convergence value. Decrease indicates precision-progress in the first phases. Asymptotic convergence indicates the begging of overfitting. The fact that the validation loss doesn't increase again like in fig 15 probably indicates that the model is not wide enough to overfit. Faster convergence in LLO compared to SLO (size of model being the only difference) supports that hypothesis.

To compare performance of the four models, it is necessary to compare the absolute values of the validation losses of the four. Fig 17 shows the validation losses on the same plot.

<figure><img src="image_21.png" /><figcaption>Figure 17: Comparison of validation losses for all models.</figcaption></figure>

Comparison shows better performance for LLO model. Unsurprisingly, baseline and SLO models perform worse. The insufficient performance from MLS is surprisingly worse than LLO, despite being wider. What MLS seems to lack is the width of the LSTM layer. Despite being surprising, this is reassuring as it tends to indicate that the dynamics of the time series (that LSTM catches) seems more important than basic regression (Dense layer).
baseline is equivalent to a linear regression. Validation loss seems chaotic, most likely for two reasons:

- Validation data is smaller than training data, leading to greater variance.

- Sudden increases happen in 1 epoch, decreases happen in several epochs. This probably indicates that a few coefficients in the "linear regression" matrix are very significant compared to others. If an input variable varies a lot non-linearly, the baseline model incorrectly predicts it with big impact due to the square in the loss function.

* SLO, LLO and MLS show similar training/validation profiles:

- Validation loss starts lower than training loss: this might be caused by the delay between the computation of both: training loss is evaluated during the epoch, validation is evaluated at the end. The model has made improvement during that delay.

- Training loss then regularly decreases with an exponential profile, which indicates learning-progress by the model.

- Validation loss decreases, then asymptotically oscillates around a convergence value. Decrease indicates precision-progress in the first phases. Asymptotic convergence indicates the begging of overfitting. The fact that the validation loss doesn't increase again like in fig 15 probably indicates that the model is not wide enough to overfit. Faster convergence in LLO compared to SLO (size of model being the only difference) supports that hypothesis.

To compare performance of the four models, it is necessary to compare the absolute values of the validation losses of the four. Fig 17 shows the validation losses on the same plot.

<figure><img src="image_21.png" /><figcaption>Figure 17: Comparison of validation losses for all models.</figcaption></figure>

Comparison shows better performance for LLO model. Unsurprisingly, baseline and SLO models perform worse. The insufficient performance from MLS is surprisingly worse than LLO, despite being wider. What MLS seems to lack is the width of the LSTM layer. Despite being surprising, this is reassuring as it tends to indicate that the dynamics of the time series (that LSTM catches) seems more important than basic regression (Dense layer).
### 3.3.4 Oscillations, averaging, improvements

Once the model has been trained, a way to detect mistakes in input/output wiring (most likely implementation mistakes) is to compare the prediction of the model to the actual value for each time step in an ASTEC computation. This is called assisted simulation, because at each time step, the actual input is fed into the model, not the previously predicted one.

Fig 18 shows the predicted value for the second steam generator water level in the first scenario. "Actual" values are predictions of the model (here, LLO). "Expected" values are raw values from ASTEC.

<figure><img src="image_22.png" /><figcaption>Figure 18: Steam generator water level (%) in assisted simulation mode</figcaption></figure>

Fig 18 shows no mistake in input/output wiring, and sufficient precision.

Looking at other variables however, we find unexpected oscillations like in fig 19, especially around 4000 seconds.

<figure><img src="image_23.png" /><figcaption>Figure 19: H2 pressure (Pa) in VOLUME TUX_V001</figcaption></figure>

This is unexpected because the input variable doesn't oscillate. General tendency seems to have been learned by the model, but those local oscillations with a period of 5-10 seconds has to come from somewhere else. Deeper inspection of input variables shows that some variables, namely the speeds of liquid and gas in junctions actually oscillate (see fig 20). As
### 3.3.4 Oscillations, averaging, improvements

Once the model has been trained, a way to detect mistakes in input/output wiring (most likely implementation mistakes) is to compare the prediction of the model to the actual value for each time step in an ASTEC computation. This is called assisted simulation, because at each time step, the actual input is fed into the model, not the previously predicted one.

Fig 18 shows the predicted value for the second steam generator water level in the first scenario. "Actual" values are predictions of the model (here, LLO). "Expected" values are raw values from ASTEC.

<figure><img src="image_22.png" /><figcaption>Figure 18: Steam generator water level (%) in assisted simulation mode</figcaption></figure>

Fig 18 shows no mistake in input/output wiring, and sufficient precision.

Looking at other variables however, we find unexpected oscillations like in fig 19, especially around 4000 seconds.

<figure><img src="image_23.png" /><figcaption>Figure 19: H2 pressure (Pa) in VOLUME TUX_V001</figcaption></figure>

This is unexpected because the input variable doesn't oscillate. General tendency seems to have been learned by the model, but those local oscillations with a period of 5-10 seconds has to come from somewhere else. Deeper inspection of input variables shows that some variables, namely the speeds of liquid and gas in junctions actually oscillate (see fig 20). As
<figure><img src="image_24.png" /></figure>

<figure><img src="image_25.png" /><figcaption>Figure 20: Gas speed in the junction cold-box - cold-leg</figcaption></figure>

surrogate models learn correlations and not causalities, LLO seems to have found a correlation between speed variables in JUNCTIONs and other variables like H2 pressure in VOLUMEs.

Oscillations from speed variables might have two sources:

* Numerical instability: the numerical schema oscillates around a value it cannot reach directly. This typically has a 1-time-step period.

* Physical model instability. For instance, thermohydraulic model can use different correlations for different regimes. Close to junctions between regimes, instability can be seen.

* Physical instability: oscillation is an true physical phenomena. It usually has a many-time-step period.

Physical model instability could be the cause of the observed oscillations. However, exploring the true cause is beyond the scope of this report. What matters for the steam generator surrogate model is that those oscillations are unwanted, and degrade performance. A way to avoid this is to artificially modify those variables for the training phase. A centered-moving-window averaging is performed for all speed variables: the new speed value is the average between the 10 values around the actual value (5 before and 4 after). This greatly reduces the oscillations, as expected.

To see if this improves surrogate model performance, a new training phase is performed with the LLO model architecture. Training and validation losses, as well as a comparison with previous LLO values is shown in fig 21

Fig 21a shows a similar training profile compared to old LLO model (see fig 16c). Fig 21b shows that new MSE-loss is about 5 times lower than old, which indicates significant improvements. Those improvements have two sources:

* Speed variables oscillate a lot less. Predicting them is easier and therefore the global loss decreases.

* Other variables previously correlated to speeds are now probably equally correlated to those variables, but the impact is significantly lower.
<figure><img src="image_24.png" /></figure>

<figure><img src="image_25.png" /><figcaption>Figure 20: Gas speed in the junction cold-box - cold-leg</figcaption></figure>

surrogate models learn correlations and not causalities, LLO seems to have found a correlation between speed variables in JUNCTIONs and other variables like H2 pressure in VOLUMEs.

Oscillations from speed variables might have two sources:

* Numerical instability: the numerical schema oscillates around a value it cannot reach directly. This typically has a 1-time-step period.

* Physical model instability. For instance, thermohydraulic model can use different correlations for different regimes. Close to junctions between regimes, instability can be seen.

* Physical instability: oscillation is a true physical phenomena. It usually has a many-time-step period.

Physical model instability could be the cause of the observed oscillations. However, exploring the true cause is beyond the scope of this report. What matters for the steam generator surrogate model is that those oscillations are unwanted, and degrade performance. A way to avoid this is to artificially modify those variables for the training phase. A centered-moving-window averaging is performed for all speed variables: the new speed value is the average between the 10 values around the actual value (5 before and 4 after). This greatly reduces the oscillations, as expected.

To see if this improves surrogate model performance, a new training phase is performed with the LLO model architecture. Training and validation losses, as well as a comparison with previous LLO values is shown in fig 21

Fig 21a shows a similar training profile compared to old LLO model (see fig 16c). Fig 21b shows that new MSE-loss is about 5 times lower than old, which indicates significant improvements. Those improvements have two sources:

* Speed variables oscillate a lot less. Predicting them is easier and therefore the global loss decreases.

* Other variables previously correlated to speeds are now probably equally correlated to those variables, but the impact is significantly lower.
<figure><img src="image_26.png" /><figcaption>Figure 21: New LLO losses, comparison with old LLO</figcaption></figure>

The best surrogate model of steam generator built is this new LLO model. Interestingly, fig 22 shows that the performance differences between several model architectures (SLO, LLO and MLS) are less significant that the same model with two different training process.

<figure><img src="image_27.png" /><figcaption>Figure 22: Validation losses of baseline, SLO, MLS, old and new LLO. Ordering is baseline>slo>mls>old>new</figcaption></figure>

This suggests greater improvements with more refined training loops, which will be the next phase in surrogate model building.
<figure><img src="image_26.png" /><figcaption>(a) New LLO training and validation loss</figcaption></figure>

<figure><img src="image_27.png" /><figcaption>(b) Comparison between validation losses, ordering is old>new</figcaption></figure>

<caption>Figure 21: New LLO losses, comparison with old LLO</caption>

The best surrogate model of steam generator built is this new LLO model. Interestingly, fig 22 shows that the performance differences between several model architectures (SLO, LLO and MLS) are less significant that the same model with two different training process.

<figure><img src="image_28.png" /><figcaption>Figure 22: Validation losses of baseline, SLO, MLS, old and new LLO. Ordering is baseline>slo>mls>old>new</figcaption></figure>

This suggests greater improvements with more refined training loops, which will be the next phase in surrogate model building.
Conclusion

The ASSAS project involves work from two rarely associated fields: Severe Accident Management (SAM) and Artificial Intelligence (AI). The large amount of work made on ASTEC in the previous decades has lead to a powerful and complex code, that does not easily handle surrogate modelling. Yet for some specific cases, ASSAS partners expect it to be possible, with a positive tradeoff between performance gains and precision losses. Those cases have been defined as a couple (domain-model), meaning the replacement of a model in a domain of the facility. Other divisions could be possible, but would not likely get the upper hand.

Three criteria have been enacted to assess that a positive tradeoff is reachable, preferably before spending time and resources attempting the build of a surrogate model: performance, precision and flexibility. Generic causes for lacks of flexibility or precision detailed in this report give hints about what to attempt or not attempt, but shouldn't be taken for definitive conclusions.

Steam Generator (SG) are a promising direction to attempt surrogate modelling. Three surrogate models plus a reference model have been tried, and the Large LSTM Only (LLO) seems to be the best of those, with a significant improvement over the reference. Improvement made in the training process have greatly increased precision without sacrificing performance and flexibility. It suggests that further improvements are possible and should be attempted.

Intermediate metrics like the MSE-loss at the output of the model give handful information on what could and what can't work. However, as long as the surrogate model is not wired back in ASTEC, no definitive conclusions can be made, especially with respect to interaction with other modules. Wiring back the aforementioned surrogate model is a task currently in progress at IRSN, but not advanced enough to be part of this report. Reaching the end of this task will be an important step for the ASSAS project as a whole.
Conclusion

The ASSAS project involves work from two rarely associated fields: Severe Accident Management (SAM) and Artificial Intelligence (AI). The large amount of work made on ASTEC in the previous decades has lead to a powerful and complex code, that does not easily handle surrogate modelling. Yet for some specific cases, ASSAS partners expect it to be possible, with a positive tradeoff between performance gains and precision losses. Those cases have been defined as a couple (domain-model), meaning the replacement of a model in a domain of the facility. Other divisions could be possible, but would not likely get the upper hand.

Three criteria have been enacted to assess that a positive tradeoff is reachable, preferably before spending time and resources attempting the build of a surrogate model: performance, precision and flexibility. Generic causes for lacks of flexibility or precision detailed in this report give hints about what to attempt or not attempt, but shouldn't be taken for definitive conclusions.

Steam Generator (SG) are a promising direction to attempt surrogate modelling. Three surrogate models plus a reference model have been tried, and the Large LSTM Only (LLO) seems to be the best of those, with a significant improvement over the reference. Improvement made in the training process have greatly increased precision without sacrificing performance and flexibility. It suggests that further improvements are possible and should be attempted.

Intermediate metrics like the MSE-loss at the output of the model give handful information on what could and what can't work. However, as long as the surrogate model is not wired back in ASTEC, no definitive conclusions can be made, especially with respect to interaction with other modules. Wiring back the aforementioned surrogate model is a task currently in progress at IRSN, but not advanced enough to be part of this report. Reaching the end of this task will be an important step for the ASSAS project as a whole.
# Glossary

**analyzer** ODESSA-specific programming language 8

**ASCAVI** ASTEC module 7

**CESAR** ASTEC module, responsible for thermohydraulics 3, 4, 6, 7, 9–11, 13, 17–19, 21–23

**CONNECTI** connection between two ASTEC domains 10, 23, 24

**CONTAINM** ASTEC domain 10, 11

**CORIUM** ASTEC module 7

**COVI** ASTEC module 7

**CPA** ASTEC module 7, 11

**DataFrame** Table of data with advanced functions from pandas library 25

**DOSE** ASTEC module 7

**DROPLET** ASTEC module 7

**EVENTS** ASTEC domain 10, 20

**ICARE** ASTEC module, responsible for core degradation 3, 4, 6–11, 13, 17, 18, 21, 22

**ISODOP** ASTEC module 7

**JUNCTION** Junction in space-discretisation of CESAR module 10, 24, 33

**MEDICIS** ASTEC module 7, 8, 11

**MELCOR** US severe accident simulation code 13

**ODESSA** Data management tools (bases, "analyseur"...) 3, 6–10, 19, 20, 25

**pandas** Python library for data management 25

**PH** ASTEC module 7

**PRIMARY** ASTEC domain 10, 14, 17, 18

**RCSMESH** ASTEC module 7

**READBASE** ASTEC module 7

**RUPUICUV** ASTEC module 7, 11

**SAFARI** ASTEC module 7
# Glossary

**analyzer** ODESSA-specific programming language 8

**ASCAVI** ASTEC module 7

**CESAR** ASTEC module, responsible for thermohydraulics 3, 4, 6, 7, 9–11, 13, 17–19, 21–23

**CONNECTI** connection between two ASTEC domains 10, 23, 24

**CONTAINM** ASTEC domain 10, 11

**CORIUM** ASTEC module 7

**COVI** ASTEC module 7

**CPA** ASTEC module 7, 11

**DataFrame** Table of data with advanced functions from pandas library 25

**DOSE** ASTEC module 7

**DROPLET** ASTEC module 7

**EVENTS** ASTEC domain 10, 20

**ICARE** ASTEC module, responsible for core degradation 3, 4, 6–11, 13, 17, 18, 21, 22

**ISODOP** ASTEC module 7

**JUNCTION** Junction in space-discretisation of CESAR module 10, 24, 33

**MEDICIS** ASTEC module 7, 8, 11

**MELCOR** US severe accident simulation code 13

**ODESSA** Data management tools (bases, "analyseur"...) 3, 6–10, 19, 20, 25

**pandas** Python library for data management 25

**PH** ASTEC module 7

**PRIMARY** ASTEC domain 10, 14, 17, 18

**RCSMESH** ASTEC module 7

**READBASE** ASTEC module 7

**RUPUICUV** ASTEC module 7, 11

**SAFARI** ASTEC module 7
**SECONDAR** ASTEC domain 10, 17, 18

**SENSORS** ASTEC domain 10, 20, 24

**SOPHAEROS** ASTEC module 7–10

**SYSINT** ASTEC module 11

**SYSTEMS** ASTEC domain 10

**Tensorflow** Python library for machine learning 25, 27

**THC** ASTEC module 7

**TRUPT** Time of vessel rupture 17, 18

**VESSEL** ASTEC domain 10, 13, 14, 18

**VOLUME** Volume in space-discretisation of CESAR module 4, 10, 24, 32, 33

**WALL** Wall in space-discretisation of CESAR module 10, 24

## Acronyms

**AG** Accident Grave 2

**AI** Artificial Intelligence 5, 12, 35

**APRP** Accident de Perte de Réfrigérant Primaire 2

**ARE** Steam Generator regular water supply 14, 28

**ASG** Steam Generator safety water supply 28

**ASSAS** Artificial intelligence for Simulation of Severe AccidentS 1, 2, 4, 5, 12, 13, 35

**ASTEC** Accident Source Term Evaluation Code 1–13, 16–21, 23, 25, 28, 32, 35

**EAS** Containment spray system 28

**FBA** Automatic borication system 28

**GCT** Turbine shortcut circuit for secondary steam, A for atmosphere and C for condenser 13

**IRSN** Institut de radioprotection et de sûreté nucléaire 1, 2, 7, 35

**ISBP** Safety injection low pressure 28

**ISMP** Safety injection medium pressure 28
**SECONDAR** ASTEC domain 10, 17, 18

**SENSORS** ASTEC domain 10, 20, 24

**SOPHAEROS** ASTEC module 7–10

**SYSINT** ASTEC module 11

**SYSTEMS** ASTEC domain 10

**Tensorflow** Python library for machine learning 25, 27

**THC** ASTEC module 7

**TRUPT** Time of vessel rupture 17, 18

**VESSEL** ASTEC domain 10, 13, 14, 18

**VOLUME** Volume in space-discretisation of CESAR module 4, 10, 24, 32, 33

**WALL** Wall in space-discretisation of CESAR module 10, 24

## Acronyms

**AG** Accident Grave 2

**AI** Artificial Intelligence 5, 12, 35

**APRP** Accident de Perte de Réfrigérant Primaire 2

**ARE** Steam Generator regular water supply 14, 28

**ASG** Steam Generator safety water supply 28

**ASSAS** Artificial intelligence for Simulation of Severe AccidentS 1, 2, 4, 5, 12, 13, 35

**ASTEC** Accident Source Term Evaluation Code 1–13, 16–21, 23, 25, 28, 32, 35

**EAS** Containment spray system 28

**FBA** Automatic borication system 28

**GCT** Turbine shortcut circuit for secondary steam, A for atmosphere and C for condenser 13

**IRSN** Institut de radioprotection et de sûreté nucléaire 1, 2, 7, 35

**ISBP** Safety injection low pressure 28

**ISMP** Safety injection medium pressure 28
**LLM** Large Language Model 25

**LLO** Large LSTM Only 4, 27, 28, 30–35

**LOCA** Loss Of Coolant Accident 1, 4, 10, 17, 28, 29

**LSTM** Long Short Term Memory 4, 26, 27, 31

**MDB** Material Data Bank 3, 8

**MLS** Medium LSTM with Shortcut 4, 27, 30, 31, 34

**MSE** Mean Squared Error 4, 30, 33, 35

**PSA-2** Probabilistic Safety Assessment level 2 6

**PTAE** Perte Totale des Alimentations Electriques 2

**PTR** Primary tube rupture 14

**PWR** Pressurized water reactor 1, 13

**REP** Réacteur à Eau Pressurisée 2

**RIS** Safety water injection in primary circuit 14

**RNN** Recurrent Neural Network 26

**SA** Severe Accident 1, 5, 6

**SAM** Severe Accident Management 5, 6, 35

**SBO** Station blackout 1, 4, 17, 28

**SG** Steam Generator 5, 24, 35

**SGTR** Steam Generator Tube Rupture 14

**SLO** Small LSTM Only 4, 26, 27, 30, 31, 34

**VVER** водо-водяной энергетический реактор: water-water energy reactor 13

**WP** Work-package 12–14, 16, 17, 19, 20
**LLM** Large Language Model 25

**LLO** Large LSTM Only 4, 27, 28, 30–35

**LOCA** Loss Of Coolant Accident 1, 4, 10, 17, 28, 29

**LSTM** Long Short Term Memory 4, 26, 27, 31

**MDB** Material Data Bank 3, 8

**MLS** Medium LSTM with Shortcut 4, 27, 30, 31, 34

**MSE** Mean Squared Error 4, 30, 33, 35

**PSA-2** Probabilistic Safety Assessment level 2 6

**PTAE** Perte Totale des Alimentations Electriques 2

**PTR** Primary tube rupture 14

**PWR** Pressurized water reactor 1, 13

**REP** Réacteur à Eau Pressurisée 2

**RIS** Safety water injection in primary circuit 14

**RNN** Recurrent Neural Network 26

**SA** Severe Accident 1, 5, 6

**SAM** Severe Accident Management 5, 6, 35

**SBO** Station blackout 1, 4, 17, 28

**SG** Steam Generator 5, 24, 35

**SGTR** Steam Generator Tube Rupture 14

**SLO** Small LSTM Only 4, 26, 27, 30, 31, 34

**VVER** водо-водяной энергетический реактор: water-water energy reactor 13

**WP** Work-package 12–14, 16, 17, 19, 20
References

[1] Laborde Chailan. ASTEC V3.1 Overview. IRSN, 2022.

[2] IRSN. ASTEC: CESAR physical and numerical modelling, 2022.

[3] IRSN. ASTEC: Physical modelling of the ICARE module, 2022.

[4] The pandas development team. pandas-dev/pandas: Pandas, February 2020.

[5] Larry R Medsker and LC Jain. Recurrent neural networks. *Design and Applications*, 5(64-67):2, 2001.

[6] Sepp Hochreiter and Jürgen Schmidhuber. Long short-term memory. *Neural computation*, 9(8):1735–1780, 1997.

[7] Martín Abadi, Ashish Agarwal, Paul Barham, Eugene Brevdo, Zhifeng Chen, Craig Citro, Greg S. Corrado, Andy Davis, Jeffrey Dean, Matthieu Devin, Sanjay Ghemawat, Ian Goodfellow, Andrew Harp, Geoffrey Irving, Michael Isard, Yangqing Jia, Rafal Jozefowicz, Lukasz Kaiser, Manjunath Kudlur, Josh Levenberg, Dandelion Mané, Rajat Monga, Sherry Moore, Derek Murray, Chris Olah, Mike Schuster, Jonathon Shlens, Benoit Steiner, Ilya Sutskever, Kunal Talwar, Paul Tucker, Vincent Vanhoucke, Vijay Vasudevan, Fernanda Viégas, Oriol Vinyals, Pete Warden, Martin Wattenberg, Martin Wicke, Yuan Yu, and Xiaoqiang Zheng. TensorFlow: Large-scale machine learning on heterogeneous systems, 2015. Software available from tensorflow.org.
References

[1] Laborde Chailan. ASTEC V3.1 Overview. IRSN, 2022.

[2] IRSN. ASTEC: CESAR physical and numerical modelling, 2022.

[3] IRSN. ASTEC: Physical modelling of the ICARE module, 2022.

[4] The pandas development team. pandas-dev/pandas: Pandas, February 2020.

[5] Larry R Medsker and LC Jain. Recurrent neural networks. Design and Applications, 5(64-67):2, 2001.

[6] Sepp Hochreiter and Jürgen Schmidhuber. Long short-term memory. Neural computation, 9(8):1735–1780, 1997.

[7] Martín Abadi, Ashish Agarwal, Paul Barham, Eugene Brevdo, Zhifeng Chen, Craig Citro, Greg S. Corrado, Andy Davis, Jeffrey Dean, Matthieu Devin, Sanjay Ghemawat, Ian Goodfellow, Andrew Harp, Geoffrey Irving, Michael Isard, Yangqing Jia, Rafal Jozefowicz, Lukasz Kaiser, Manjunath Kudlur, Josh Levenberg, Dandelion Mané, Rajat Monga, Sherry Moore, Derek Murray, Chris Olah, Mike Schuster, Jonathon Shlens, Benoit Steiner, Ilya Sutskever, Kunal Talwar, Paul Tucker, Vincent Vanhoucke, Vijay Vasudevan, Fernanda Viégas, Oriol Vinyals, Pete Warden, Martin Wattenberg, Martin Wicke, Yuan Yu, and Xiaoqiang Zheng. TensorFlow: Large-scale machine learning on heterogeneous systems, 2015. Software available from tensorflow.org.