Skip to main content


  • Work package WP1 – Coordination

    Lead Beneficiary: IRSN
    Start Month: 1
    End Month: 48

    Overall project coordination in order to achieve the objectives of the project in terms of scientific quality, milestones and deliverables and contribution to the expected impacts ofthe project.

    Scientific coordination:

    • Monitoring the progress ofwork in collaboration with WP leaders,
    • Survey the release of deliverables and the achievement ofmilestones,
    • Organization ofmeetings of Steering Committee and Management Board,
    • Ensure communication between project participants.

    Administrative management:

    • Consortium agreement,
    • Contractual aspects,
    • Coordination ofthe project periodic and fmal reports to be delivered to European Commission.

    Financial management:

    • Management ofEuropean Commission financial contribution by the coordinator,
    • Monitoring the project and partners’ budgets,
    • Management of the partners’ costs statements.
  • Work package WP2 – Methodology

    Lead Beneficiary: JSI 
    Start Month: 1
    End Month: 48

    Define the modelling strategy and give scientific support to the other WPs.

    The WP is divided into three tasks.

    Task a: Definition of the modelling strategy
    This task aims at defming which physical phenomena and models in ASTEC need to be optimised in priority. lt will also give recommendations for the classical and machine-learning techniques to be used. In the first piace, ASTEC calculations will be analysed to identify the most computationally expensive tasks, using precise profiling tools owned by IRSN and CS GROUP. Relevant data will be provided by IRSN at the beginning ofthe project, and it will be completed by partners with a limited number of calculations. That stage will help defme which calculation steps require evolutionary or in-depth improvements to achieve the expected features.
    The work performed in this task is necessarily exploratory and multidisciplinary. The first few months ofthe project will be the most challenging, because contributors to this task will have to issue a first generai framework for the generation ofthe training database and the surrogate models. However, the task will remain active during the entire duration ofthe project to adjust the strategy with regards to the results generated by the other work packages.

    Task b: General framework for the development of surrogate models
    The aim of this task is to provide scientific and methodological support for the development of surrogate models and the constitution of the training database (WP 3 and 4). Contrary to task a, it does not include efficient programming techniques. It will have frequent iterations with WP 3 and 4. The task will apply the strategy defined in WP 2-task a and give feedback to adapt it.
    In the first months of the project, different computational strategies will be evaluated for surrogate models, based on a preliminary analysis of the small data samples available at this time. Characteristics like regularity of the funct io ns, dimens ionality, variable correlations, resources necessary to generate and store data will be eval uated. They will give a first insight of the most promising techniques to be used, considering end-users needs and technical constraints. Associated recommendations concerning the generation of datasets will be provided. The strategy will be updated during the consortium as long as results are generated. Methodological support will be provided to overcome the difficulties faced when applying the strategy to real data . Considering that AI experts in the group have different fields of expertise, exchange of experience will be favoured.
    Recommendations will be formulated for surrogate models for the generic BWR and VVER designs, taking into account the return from experience gathered on the generic PWR design.
    A report summarising the recommendations of tasks a and b will be issued in month 10, with a preliminary version in month 7. It will be coordinated by JSI and it will include a description of ASTEC ‘s models and computational architecture by IRSN. A return from experience will be established in the final WP report (month 45). It will describe the methodology applied in WPs 2-3-4 and give recommendations to generalise the results to similar calculation codes. It will feed the generai return from experience ofthe project.

    Task c: Definition ofthe validation criteria
    The performance of the different models developed in the consortium must be evaluated against precise criteria, that will be defined in this task. They will concern for instance explicability (a concept to be defined precisely), rapidity, robustness (especially concerning threshold effects) and accuracy. The expectations may differ depending on the user case for the simulator. In addition to the partners, the end user group will be solicited for this task. Preliminary thoughts about criteria are given in the methodology section ofthe proposal.
    This task is expected to give results relatively early during the project, because it will be necessary for the development of surrogate models (definition of the error functions) and the optimisation of ASTEC. A progress report coordinated by JSI will be issued in month 15 and finally integrated in the global report on surrogate modelling.

  • Work package WP3 – Generation of training database

    Lead Beneficiary: HIT 
    Start Month: 1
    End Month: 48

    Generation of the database necessary to train the machine-learning algorithms used for surrogate models

    The work package is divided into four tasks.

    Task a: coordination
    The database will be fed by many partners to include different accident sequences and reactor designs. It will be continuously enriched to adapt to the needs of the partners who develop surrogate models. Therefore, tasks b and d must be considered as iterative and will be in close relation with WP 4. Coordination and a clear task repartition will be essential to generate homogeneous data, which means that there will be no duplication, no missing data and no oversampling or undersampling. lterations will be necessary with the generai implementation framework (WP2 – task b). Infonnation exchange will be necessary with WP6 to ensure consistency with the plant model used in the simulator. Considering the close links between WP3 and WP4, they have approximately the same contributors.

    Task b: Definition ofthe specifications for the performed calculations
    Before launching calculations to generate the training database , its specifications must be set. Partners will have to agree on the physical and computational assumptions used for data generation. Some assumptions will be fixed for all calculations , whereas others will be considered as training parameters and therefore sampled. Moreover, the variation limits ofthe parameters will have to be agreed upon. Sampling rules ensuring the bomogeneity oftbe training databases will be set. Tbe partners will bave to decide whicb accident sequences tbey will study (depending on the computational cost ofthe data generation) and which reactor datasets tbey will rely upon.
    The inputs and outputs to be stored for each calculation will be chosen . This very important step will bave consequences on tbe database specifications and on tbe possibilities of the surrogate models. It will be determined by tbe strategy defined in WP2-task a, especially by tbe list of modules/models that are intended to be replaced by surrogate models. The inputs and outputs ofthe surrogate models will include:
    User specified inputs, like the characteristics oftbe accident sequence,
    Plant model specific inputs, like the properties of safety systems,
    Plant model specific outputs, like the information transmitted to the main contro! room,
    Outputs required for the analysis and visualisation tools of tbe simulator, like the core degradation progression , the fraction ofFP released .. .
    Internal code variables coming from otber modules tbat are used by tbe model to be replaced,
    Internal code variables used by other modules tbat are generated by the model to be rep laced.
    Depending on the modelling strategy, the number of internal variables can vary a lot, witb consequences on the dimensionality ofthe problem , and tberefore on the AI algorithms to use and tbe size oftbe training database.
    The internal variables must be defined carefully, so tbat the developed surrogate models will be able to replace existing modules smoothly. Both must have exactly the same inputs and outputs.
    Furthennore, a strategy must be defined fortime sampling. It means tbat, for eacb calculated accident sequence, tbe times at which so-called ” snapshots” are saved into the training database must be defined . Adaptive sampling techniques can be used to store only the most relevant snapsbots into the database. Tbis requires a close coordination with WP 4-task b. The specifications will be summarised in a progress report coordinated by KIT. It will be issued in montb 12 and integrated in the final report on surrogate modelling.

    Task c: Database design and exploitation
    Tbe database infrastructure used to store the training data must be designed to meet the requirements defined in task b. It must be secure and accessible, because it is the foca! point forali partners involved in WP 3 (wbo will write into it) and 4 (wbo will read it). It must be considered tbat multiple users will upload or download a large quantity of data from it. Tbe database must also be flexible, because new training data will be added during the iterative development of surrogate models , to refine tbe sampling wbere more accuracy is needed .
    Tbe same or anotber database infrastructure will be used to disseminate tbe results in tbe long term, according to tbe principles of open science. The requirements will be defined in relation witb WP 7-task b. Otber features must be considered , like environmental impact , security . ..

    Task d: Running calculations and checking quality of the generated data
    Partners will generate training data in line with the requirements issued by WP 3-task a and by WP2. They will calculate SA sequences by batches using high-perfonnance computers. Tbe most experienced partners will share tbe scripts tbey developed to automatically launcb calculations and analyse the results.
    Before storing the results into tbe database, the quality of the generated sequences will be verified. Experts will track and eliminate irrelevant results, wbicb can stili be generated during batch calculation despite tbe increased robustness of ASTEC. AI techniques may be used to assist this process.
    The partners will evaluate how calculations perfonned during fonner and on-going European Union projects (SARNE T, CESAM, FASTNET, IVMR, MUSA . ..) and within tbe ASCOM network can be reused. Since they bave not been designed specifically to train surrogate models, the most promising option is to use the input decks to launch tbe calculations again and extract tbe additional necessary data.
    According to the separation between macro-phases 1 and 2, tbe priority will be to generate data for tbe generic PWR design witb ASTEC during macro-pbase 1. Tbe database will also include sequences calculated witb MELCOR or ASTEC for tbe generic VVER and BWR designs. In particular:
    PSI, CIEMAT, ENEA, JSI, TU-Delft and KIT will generate the data fora generic PWR by means ofthe ASTEC code;
    Energorisk will generate tbe data fora generic VVER by means ofthe ASTEC code;
    KTH will generate tbe database fora generic BWR design witb the MELCOR code.

    For the machine-learning techniques used by KTH and TU-Delft, tbe constitution oftbe training dataset and the training of the surrogate models are perfonned in a single stage, using for instance adaptive sampling. Therefore, the overall manpower effort bas been counted in WP4 only.
    PHIMECA will provide methodological support.

  • Work package WP4- Surrogate models design

    Lead Beneficiary: KTH 
    Start Month: 13 
    End Month: 48

    The main goal of WP4 is to explore applicability of different machine learning (ML) methodologies and develop surrogate modelling (SM) approaches to modelling ofsevere accident phenomena and development ofplant simulators.

    The work package is divided into three tasks.

    Task a: Coordination
    A strong coordination by the WP leader is essential because surrogate models will be generated by different partners with different scopes and mathematical tools. Iterations with other work packages will also be necessary to adapt the generai implementation framework (WP2-task b) and to generate additional data when necessary (WP3-task d). A good equilibrium will be found to explore different modelling options to maximise the chances of success, without spreading efforts too much.
    WP 3-task b will inform partners ofthe inputs and outputs ofthe surrogate models to be integrated into ASTEC.

    Task b: Iterative development and validation of surrogate models
    In accordance with the strategy defined in WP2-task (a) and with the recommendations formulated by WP2-task (b), different surrogate models will be developed , using datasets generated in WP3 or automatically during the training of the AI-models (for TU-Delft and KTH). First, different techniques will be used following the recommendations of WP2- task (b). Based on the first results of SM deve lopment, requirement for the extension of the data set will be developed and the database will be further generated in WP 3.
    WP4.b will include following technical subtasks:
    Selection ofthe machine-leaming and surrogate modelling approaches (based on the review and recommendations produced in WP2 and data provided from WP3) that will be developed by partners in WP4.
    Implementation of different approaches for the development of surrogate models (SMs) for:
    selected mechanistic model
    single module of a SA analysis code.
    group ofmodules in a SA analysis code.
    whole SA analysis code that can be directly integrated with a severe accident analysis simulator.
    Validation ofthe developed SMs.
    The distribution oftasks is based on the experience ofthe partners and will be further adapted according to the conclusions of WP2, which requires more in-depth study ofsmall data samples at the beginning ofthe project.
    TU Delft: will use ASTEC generic PWR model for the development of a SM for core degradation and thermal­ hydraulics (coupled ICARE and CESAR modules);
    PSI, ENEA, PHIMECA: will use ASTEC generic PWR model for the development of a surrogate model for thermal­ hydraulics (CESAR module);
    KIT: will use ASTEC generic PWR model to develop a surrogate model for core degradation (ICARE module);
    Ciemat: will use ASTEC generic PWR model to develop a surrogate model for the fission product release in ICARE;
    BelV: will use ASTEC generic PWR model to develop a surrogate model for the CPA module (thermal-hydraulics in containment) ;
    JSI: will use ASTEC generic PWR model to develop an advanced interpolation system for the containment behaviour after the vessel rupture (CPA, SOPHAREOS and, ifnecessary, MEDICIS modules);
    KTH: will use MELCOR generic BWR model to develop a surrogate model for the whole severe accident analysis code such that it can be used in a sever accident simulator;
    Energorisk and JSI: will use a generic VVER-1000 model to develop an advanced interpolation system for the containment behaviour after the vessel rupture (CPA, SOPHAREOS and, ifnecessary, MEDICIS modules). The system will be adapted from the one developed with the generic PWR model.
    Validation is an integrai part ofthe development of AI models. A part ofthe data is not used for training ofthe surrogate model and kept apart to assess the accuracy of the trained surrogate model in approximation of the reference model.
    In addition to the validation of the stand-alone SMs, the robustness and performance of the surrogate models coupled
    with ASTEe must be evaluated. The best perfonning surrogate models will be selected and interfaced with ASTEe ‘s rnain memory using the recently released Python interface. The reference model will be deactivated and replaced by the surrogate model. At this stage of the project, the reference versions of the other modules (released before the project starts) will be us ed.
    The criteria defined in WP2-task c will be relied upon. ASTEe results will be used as a reference mainly but other severe accident codes might be integrated. Docurnentation will be established for the different surrogate models to ensure their transparency and auditability.

    Task c: Sensitivity and uncertainty analysis
    Ali participants in the task will compare the sensitivity of response of the surrogate models and the reference models to the variation ofthe input parameters. Expertjudgement about physical sensibility ofthe SM predictions will be also relied upon. Special attention will be paid to cliff-edge effects and operator actions. This task will help to define the conditions in which the surrogate models can be used.

  • Work package WPS – Improving ASTEC’s performances

    Lead Beneficiary: IRSN
    Start Month: 7 
    End Month: 48

    Implement efficient programming techniques to improve ASTEe’s performances. Optimise the nodalization used in ASTEe. Integrate the new models developed in WP 3 and 4 into ASTEe.

    The work package is divided into four tasks. The main contributors are IRSN (code owner), es GROUP (historical contributor to the development of ASTEe) and KIT (IRSN’s partner for the development of ASTEe ), which bave access to ASTEe’s source code.

    Task a: Improvement of ASTEe’s overall computational architecture
    IRSN and es GROUP will implement improvements that are common to different modules in ASTEe, like the mutualisation and optimisation of numerica! solvers which are currently duplicated in different modules. KIT will provide methodological support. The parallel execution of weakly coupled modules will be explored. This task will be based on extensive performance analysis performed with specific tools developed by IRSN and es GROUP.

    Task b: Improving the performance of specific modules and calculation steps using efficient programming Parallelisation techniques will be applied by es GROUP to IeARE (core degradation) and eESAR (thermal-hydraulics in the prirnary vessel) modules . MEDieIS (module for the core-concrete interaction) will be partly reengineered by IRSN to be more efficient. Moreover, IRSN will evaluate the benefits of using a statistica! approach to model fuel assemblies. Moreover, KIT will perforrn an audit of IeARE and propose solutions to improve the performance of specific models of the module , most likely the rnelt-down offuel assemblies . lt will also provide methodological support.
    The optimisation of the nodalization will be performed by KIT for the generic PWR design. lt will focus on the core region. IVS will oversee a similar task fora VVER design. Available resources do not allow to perform a similar task forBWRs.

    Task c: Integration of the best perfonning models into ASTEe
    Different solutions will have been explored in WP4 and WP5 to improve the performance of ASTEe for the generic PWR design used in the simulator: surrogate models, enhanced numerica! methods, optimised nodalization. The best perfoming solutions will be chosen according to the validation criteria defined in WP2. Each will already bave been tested in stand-alone conditions and in connection with the reference version of ASTEe. At this stage, es GROUP will connect them with one another to fonn the version of ASTEe that will be implemented into the simulator. The combination of different techniques may cause numerica! stability issues. If they cannot be solved, other back-up solutions will be used. IRSN will provide support to es GROUP.
    Even if the solutions developed for BWRs and VVERs will not be integrated in the complete calculation chain, the results generated for the PWR design will be sufficient to prove the feasibility of this task.

    Task d: Global performance tests and validation
    The different participants of the WP will check the performance and robustness of the enhanced integrai code to be implemented into the simulator.

  • Work package WP6 – lnterfacing ASTEC with the simulation environment

    Lead Beneficiary: TECNATOM S.A. 
    Start Month: 4
    End Month: 48

    Definition oft he specifications and design of the prototype generic basic-principles’ simulator. Interfacing ASTEC with the simulation environment (TEAM_SUITE®).

    The work package is divided into five tasks. CS GROUP will participate as an observer to gather useful information for the integration of the different models developed in WP4 and WP5 in ASTEC.

    Task a: Interfacing of ASTEC’s with TEAM_SUITE®
    Tecnatom will develop an API to enable the controI of ASTEC by TEAM_SUITE® and the exchange of information between them. In this way, ASTEC will be synchronized with the simulator. Communication will be achieved thanks to ASTEC ‘s module ODESSA, which controls the communication with the main memory. The development ofthe API can take piace while optimised and surrogate models are being developed, thanks to ASTEC’s modular structure. lt must be reminded that ASTEC will not have the required performances concerning execution time when the API will be developed.

    Task b: Defining users’ functional expectations
    Tecnatom will work with potential future users of the prototype simulator to define its functional specifications more precisely. This will include members ofthe consortium and of the end-user group in priority. This study will be extended to industriai simulators to have a better idea of the potential future market after the end of the project. This task is necessary for the completion of task c.

    Task c: Construction of the generic plant design
    Tecnatom will develop models for the plant systems that will be emulated by TEAM_SUITE® directly. Other systems will be modelled by ASTEC. In addition, Tecnatom will design the human-machine interface ofthe simulator, through which users can internet with the simulated reactor and visualise calculation results. lt will also include a graphical representation of the main plant systems, alarms and information from instrumentation .
    Tecnatom will provide generic data for this purpose, that will be adapted to the specificities of the project. To minimise costs while reaching the generai objective of the project to demonstrate the feasibility of an ASTEC-based SAS, only the most important systems will be modelled. The design used in the simulator must be as close as possible to the design used in WP3 to generate training data for surrogate models, to ensure representativeness. The model must be ready by the time the enhanced version of ASTEC will be delivered.

    Task d: Acceptance tests
    Global acceptance tests will be performed on the final version of the simulator by Tecnatom (as designer) , IRSN and Ciemat (as users).

    Task e: Documentation and demonstration
    Extensive documentation will be provided to facilitate the dissemination of the simulator, notably to universities. The objective is for users to be as autonomous as possible. The capabilities of the simulator will be demonstrated to partners and the end-user group during the final meeting of the consortium to gather feed-back. The documentation will precisely describe the limitations of the simulator and its validation domain, especially when artificial intelligence models are used.

  • Work package WP7 – Conclusion and dissemination

    Lead Beneficiary: ENEA 
    Start Month: 1
    End Month: 48

    Communicate about the project and disseminate results. Organise training and education activities. Summarise the conclusions ofthe project.

    The work package will be divided into three tasks. lt also includes a contribution to the final activity report mentioned in WPl.

    Task a: Communication and dissemination Communication and dissemination activities will include:
    A round-table seminar to define users’ expectations during the first year of the project (lead by Tecnatom in relation with WP6-task b),
    A workshop during the third year of the project to present the results generated by work packages 3 and 4 on surrogate modelling (lead by KTH),
    A workshop at the end of the project to demonstrate the capabilities of the prototype simulator and gather feedback from users (lead by Tecnatom),
    The constitution of an end-user group by ENEA and IRSN,
    General communication activities lead by ENEA (release of a yearly newsletter, communication on social media, the design of communication materiai) and IRSN (construction of a website),
    Publications and presentations in conferences by the researchers.
    The corresponding budget is integrated in the flexible costs of the coordinator. Progress reports will be issued after the different workshops, which will be integrated in the report on communication and dissemination activities. The advisory board will issue some advice on the scientific orientations of the project in month 9, especially concerning the provisory report on the modelling strategy (WP2). The end-user group will contribute to the definition of user s’ expectations concerning SASs.

    Task b: Education and training
    Education and training activities will include:
    Hiring Ph-D and post-doctoral students at TU Delft, KIT, KTH and Ciemat,
    A generai training session on ASTEC at the beginning of the project organised by IRSN ,
    A mobility programme for Ph-D and post-doctoral students (6 months for 4 students).
    The workshop planned during the third year of the project to present the results generated by work packages 3 and 4 on surrogate modelling can be considered as a training activity as well.

    Task c: Conclusion ofthe project and return from experience
    The final activity report ofthe project will be jointly supervised by IRSN and ENEA, with contributions from ali partners. It will gather feedback from the different work packages and make proposals for the possible continuation of the project, for example its extension to other SA codes . It will include the end-user feedback on the demonstrator. Recommendations will be issued for the further exploitation of the open access datasets. The advantages, disadvantages, challenges and opportunities of the use of AI will be assessed. The evolving capability of the simulator to new reactor design and new functionalities will be evaluated.