Page 1 of 3

Restart feature in 2.1.17

Posted: Wed Mar 05, 2014 12:29 pm
by Jaakko Leppänen
I started working on a an automated burnup sequence for group constant generation, capable of handling branch calculations. The work is still under way, but as a first step I implemented a kind of a restart feature in version 2.1.17, that could be useful for other purposes as well.

The idea is relatively simple. First run a burnup calculation with entry:

Code: Select all

set rfw 1 <file>
in the input file. The code should write a binary file <file>, which contains the nuclide compositions of all materials for all burnup steps. This file can then be read in another calculation by setting:

Code: Select all

set rfr <bu> <file>
Instead of starting from the initial composition defined in the input, the calculation should now start from burnup step with burnup <bu>, using compositions from the previous run. The input file can be different from the run where the restart file was written, the only limitation is that the names of the burnable materials must be the same, and the same nuclides must be found in the compositions.

I want to emphasize that this feature is mainly intended to be used by another calculation routine in an automated manner, so there are certain limitations on what can and cannot be done. Basically the geometry, compositions of non-burnable materials, temperatures, etc. can be changed, but not the names or compositions of burnable materials. Changing cross section, decay or fission yield libraries or cut-offs may also change which nuclides are included in the material compositions and cause the calculation to fail.

Re: Restart feature in 2.1.17

Posted: Thu Mar 06, 2014 11:29 am
by Jaakko Leppänen
A few additional instructions:

1) The burnup point given in "rfr" must correspond to the value entered in the "dep" card of the previous run. Or if burnup was entered in steps, the cumulative sum of the values.
2) If the value in "rfr" is entered with a minus sign, it is interpreted as burn time (in days) instead of burnup. This format must be used if the depletion steps were entered in days instead of burnup.

I realize that this feature probably doesn't work if the depletion history has both burnup intervals entered in units of burnup and decay intervals entered in days, as the routine tries to find an exact match for a decimal number. I'll fix that in the next update.

Re: Restart feature in 2.1.17

Posted: Fri May 30, 2014 12:06 am
by Diego
Hi Jaakko,
I´m having problems with the restart feature when using several burnup steps. Is there a limitation in the restart file size (I have a couple of Gb) ?
Additionally, how does this feature interact with the automatic division of depletion zones feature (i.e. it looks like the numeration of zones is conserved, it is right?)
Thanks in advance!
Diego

Re: Restart feature in 2.1.17

Posted: Fri May 30, 2014 9:13 am
by Jaakko Leppänen
There shouldn't be any limitation on file size. Automated division of depletion zones should work, as long as the division is the same for both runs. The routine looks for matching material names, as they are set by the routine.

Do you get an error message or strange results?

Re: Restart feature in 2.1.17

Posted: Tue Jun 03, 2014 3:14 pm
by Diego
I just get the error message
"Input error:
Error in restart file"
Thanks anyway,
Diego

Re: Restart feature in 2.1.17

Posted: Tue Jun 03, 2014 6:58 pm
by Jaakko Leppänen
OK, that could mean a multitude of things... Which code version are you running? Could you send me your input file by e-mail?

Re: Restart feature in 2.1.17

Posted: Tue Jun 23, 2015 4:34 pm
by novako
Hi Jaakko,
I'm having problem with restarting.
I used i input file:
set rfr 18 22au_serpent6.inp.wrk

Could you please help me?
Thanks
Ondrej Novak




Calculating activities...
OK.

Writing depletion output...
OK.


***** Mon Jun 22 17:18:02 2015 (seed = 1435005499, MPI task = 0, OMP thread = 0)

Fatal error in function SetDepStepSize:

Error in cumulative values

Simulation aborted.

-------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code.. Per user-direction, the job has been aborted.
-------------------------------------------------------
--------------------------------------------------------------------------
mpirun detected that one or more processes exited with non-zero status, thus causing
the job to be terminated. The first process to do so was:

Process name: [[54577,1],0]
Exit code: 255
--------------------------------------------------------------------------

Re: Restart feature in 2.1.17

Posted: Wed Jun 24, 2015 8:35 am
by Jaakko Leppänen
Does it work without MPI?

Re: Restart feature in 2.1.17

Posted: Fri Jul 03, 2015 3:56 pm
by novako
No,
That was only omp task.
I tried mpi too and it crashed again.

Options : (O4) (MPI=2) (OMP=1) (CE/LI)
------------------------------------------------------------

Transport cycle completed in 1.1 hours.

Waiting for results from other MPI tasks...
OK.

Calculating activities...
OK.


***** Thu Jul 2 16:53:14 2015 (seed = 1435866265, MPI task = 1, OMP thread = 0)

Fatal error in function SetDepStepSize:

Error in cumulative values

Simulation aborted.

Writing depletion output...
-------------------------------------------------------
Primary job terminated normally, but 1 process returned
a non-zero exit code.. Per user-direction, the job has been aborted.
-------------------------------------------------------
--------------------------------------------------------------------------
mpirun detected that one or more processes exited with non-zero status, thus causing
the job to be terminated. The first process to do so was:

Process name: [[23367,1],1]
Exit code: 255
--------------------------------------------------------------------------

Re: Restart feature in 2.1.17

Posted: Fri Jul 03, 2015 4:30 pm
by Jaakko Leppänen
Could you send me the input and outputs by e-mail?