Discussion forum for Serpent users

No. You need to define another detector for that.

OK. This is actually a valid fix to the problem. The root cause is that Serpent uses intermediate variables to store cross sections and other values that may be frequently re-used during the transport simulation. In this case the value is carried over from previous burnup step, and it is no longer v...

see: http://serpent.vtt.fi/mediawiki/index.p ... set_printm

The standard flux detector is always integrated over energy and volume, and the detector options determine the integration domain. If you have no other definitions, the results are integrated over all space and energy. In your example the spatial integration domain is cell 1 (dc 1). The dv option is...

As a quick fix, try commenting out lines 36-37: in photonmacroxs.c

I got the same error now. I'll get back to you.

Since this seems like a rare event, you can probably get through the calculation by running with the "-nofatal" command line option.

Where exactly did you get the photon library used in the calculation?

I cannot reproduce the error with my photon data, so it's most likely photon-related. Could you try changing lines 84-94 of trackmode.c from: if ((mat > VALID_PTR) && (totxs/majorant - 1.0 > 1E-6)) { /* Check reaction lists */ CheckReaListSum(mat, PARTICLE_TYPE_NEUTRON, E, NO, id); /* Exit */ Die(FU...

There is a bug in the surface flux detector routine in version 2.1.31, (ds type, option -2) that causes false surface crossings to be scored. To correct the problem, modify the if-branch starting from line 181 of superdet.c from: else if (norm == -2) { /* Flux, get surface normal */ SurfaceNormal(su...

The -rdep command line option should work if the list is explicitly specified, but in order to include all nuclides, noble gases, etc. the routine that processes the inventory list needs information on material compositions, which are not read when run in this mode. One way to go around this issue i...