Pebbles motion

Questions and discussion about applications, input, output and general user topics
yrob
Posts: 39
Joined: Tue Oct 01, 2019 9:50 pm
Security question 1: No
Security question 2: 19

Pebbles motion

Post by yrob » Fri Oct 23, 2020 1:19 pm

Hello,

I have a DEM model based on OpenFOAM available that outputs a list of pebbles positions in a pebble bed reactor.
I also have a Serpent 2.1.31 model that uses the pbed card and reads a position file. They are created from a single fuel material and then divided into fuelz{index} materials.

I would like to know if there is a way for Serpent to update dynamically the positions of the pebbles?

The first idea that comes to my mind is the use of the multiphysics interface that couples OpenFOAM and Serpent.
Indeed, it allows for pausing the calculation until the new information (here positions) would be calculated.
However, I am struggling with which type would be adequate.

Has it already been done in the past?

Thank you.

Ville Valtavirta
Posts: 541
Joined: Fri Sep 07, 2012 1:43 pm
Security question 1: No
Security question 2: 92

Re: Pebbles motion

Post by Ville Valtavirta » Fri Oct 23, 2020 3:32 pm

Hi,

what do you exactly mean by "dynamically"? During a burnup calculation?

One potential approach would be to save restart files after each depletion step and restart the simulation with updated coordinates in the file linked in the "pbed" card. (see http://serpent.vtt.fi/mediawiki/index.p ... al#set_rfw)

It would be nice to have this as a coupled calculation feature, but it is a bit tricky. The first potential future implementation that comes to mind would be to give Serpent the option to re-read the coordinates from the file defined in the "pbed" card between coupled calculation iterations.

I think the main challenge with this (in addition to needing to skip all initial memory allocations etc. on the updates) is the fact that Serpent uses a Cartesian search mesh overlaid on top of the pebble bed to speed up the pebble search during the transport. When the pebble coordinates are updated, the contents of the search mesh cells would need to be updated also, which is currently not easy to do.

-Ville

yrob
Posts: 39
Joined: Tue Oct 01, 2019 9:50 pm
Security question 1: No
Security question 2: 19

Re: Pebbles motion

Post by yrob » Fri Feb 12, 2021 3:02 am

Hi,

Thank you for you answer.

This is a great idea, and I see the problem of initializing the search mesh at every burnup step.
Looking at the code, it seems that it is done with the ProcessPBGeometry function at the beginning of the calculation.
What would happen if I applied this function during the interfacing phase?

Using restart files would be a real pain since it takes hours to initialize the materials, so this on-the-fly updating solution would really be ideal.

Ana Jambrina
Posts: 676
Joined: Tue May 26, 2020 5:32 pm
Security question 1: No
Security question 2: 7

Re: Pebbles motion

Post by Ana Jambrina » Fri Feb 12, 2021 10:28 am

It might take some more effort than just a straight-forward call to 'ProcessPBGeometry' routine when processing the interface, to get this functionality up and running.
- Ana

yrob
Posts: 39
Joined: Tue Oct 01, 2019 9:50 pm
Security question 1: No
Security question 2: 19

Re: Pebbles motion

Post by yrob » Tue Sep 14, 2021 2:07 am

Hello, I am now back on this problem.

I have 3D coordinates for each pebbles but need to put them into Serpent.
I wrote a small script that loops over burnup steps, applies depletion with Serpent and writes/reads the compositions from the previous step with the restart feature. The positions are updated by simply changing the path to the position file. This is not ideal since it means that the geometry (and burnable division) is reapplied at every step, taking some time (couple hours for each step), but it is good enough for now.

However, I need to taking into account the facts that during the process some pebbles are inserted or discarded, and that the number of pebbles might not be constant.

The solutions I see are:
- set a radius of 0 for the pebbles that are not within the core
- set a position outside of the core for the pebbles that are not within the core
- both

This way, the compositions are tracked easily for each pebble, while taking into account positions and not forgetting about pebbles that will be inserted and pebble that got discarded.

This raises three questions:
1) When a pebble is outside of the geometry (or/and with a radius of 0), what does Serpent do to handle it?
I see that if I do that, the division is still taking these pebbles into account to create the geometry, as if I use only 1000 pebbles in the core it is almost instantaneous, and if I use 1000 pebbles in the core + 100000 pebbles outside (radius of 0 + position outside), it takes way more time. I also observe that in the bumat file, the composition slightly changes even for pebbles outside of the core (like U235 concentration changing by 1e-14). It does not impact my results, but I would like to know what is happening: is it burning? decaying? both?
2) Based on the previous answer, what would you advise me to do between the three solution? (radius, position, both)
3) This approach is good, but as you can imagine, it requires position files that include all the pebbles that will ever flow in the core. This number can go up very fast, based on the core we use and the simulation. I was wondering if you had another solution, more practical in mind.

Thank you.

Ana Jambrina
Posts: 676
Joined: Tue May 26, 2020 5:32 pm
Security question 1: No
Security question 2: 7

Re: Pebbles motion

Post by Ana Jambrina » Tue Sep 14, 2021 9:47 am

From your description, you, basically, are shuffling the pebbles by sending those to the outside core region. Serpent will continue depleting the outside-core pebbles accordingly to the power setup and flux at the given region. In that sense, if the flux is zero or near to, the behaviour would be consistent with a decay step, but nothing beyond the regular Serpent depletion calculation.

Defining the pebbles with zero radii might cause some misbehaviour related to the volume of those depletion division zones.

Maybe an alternative would be to modify the depletion binary file '.wrk' accordingly. Knowing how that file is written would allow you to fully customize it and readjust the geometry/compositions of the pebbles.

More efficient handling would require some source code modifications. I have been working now for a while in a burnup interface for Serpent, including the depletion zone division mapping and handling of the restart file(s) to rebuild the Serpent calculation (with/without depletion). I am quite confident that the interface would work nicely towards a pebble-based redefinition within the depletion calculation.
- Ana

yrob
Posts: 39
Joined: Tue Oct 01, 2019 9:50 pm
Security question 1: No
Security question 2: 19

Re: Pebbles motion

Post by yrob » Tue Sep 14, 2021 8:29 pm

Hello and thank you for your answer.

It seems like pebbles getting discharged necessarily need to be deleted from the restart file to make sure they are not decaying for the rest of the calculation.

About the volume of the depletion zones, it seems like the total volume of the "fuel" material (that I divide at the beginning of the calculation) is calculated accurately: Serpent actually calculates very well the volumes of the pebbles in the core, without considering the ones outside the core (due to the radius being 0). I found out that, without even using a volume file, each pebble has the correct volume (no partial pebble is in the core).

I actually went through the routine of restart files and modified it slightly in the past, but always modifying the source code.
Is it possible to modify these binary files without Serpent?

Finally, is this burnup interface available somewhere? It would be a real boost for my project.

Ana Jambrina
Posts: 676
Joined: Tue May 26, 2020 5:32 pm
Security question 1: No
Security question 2: 7

Re: Pebbles motion

Post by Ana Jambrina » Tue Sep 14, 2021 9:06 pm

Anything else than providing Serpent with some sort of capability to drive the pebbles wouldn't make sense in terms of modifying the source in this case.
The changes should come from upstream (data structure).
If you know how the restart file is written, meaning the structure and content, you could externally read it - as Serpent does it, and modify/re-write it.
The burnup interface is an ongoing project: the depletion zone mapping is functional and, the current development is towards handling the restart file(s) to customize the geometry/compositions.
- Ana

Ville Valtavirta
Posts: 541
Joined: Fri Sep 07, 2012 1:43 pm
Security question 1: No
Security question 2: 92

Re: Pebbles motion

Post by Ville Valtavirta » Wed Sep 15, 2021 8:46 am

Hi,

could you explain why you do not want further decay for the discarded pebbles to help me understand what might be the best way to solve your problem?

If you are writing restart files and _dep.m output files on a material-zone basis, you should already get the nuclide compositions of each pebble at the point of discharge and should be able to use that instead of the decayed data for any later analyses.

-Ville

yrob
Posts: 39
Joined: Tue Oct 01, 2019 9:50 pm
Security question 1: No
Security question 2: 19

Re: Pebbles motion

Post by yrob » Mon Sep 20, 2021 9:13 pm

Hello,

My biggest constraint is the number of materials: number of pebbles to create (geometry), division of materials, pebble-wise tallies, burning step, ... So my goal was to minimize it. I think what you say makes sense, but I would like to make sure they do not impact the performances of my calculations.

In the meantime, I wrote a script that reads, modifies and writes restart files. It has been made for my specific case, but I think it must not be very different for other cases. This is particularly the case for single parent material divided with the div card.

I cannot attach python files here, so let me know if it could be interesting the upload it somewhere.

I think that with that, I would be able to go with the solution of using restart files, even though I am afraid the materials division step might take too long for each step.

Post Reply