Number of histories overwritten by number of particles in mcpl2ssw

[marquezj]

Maybe I am not understanding something, but I think mcpl2ssw is overwriting the number of histories with the number of particles, here:

mcpl/mcpl_extra/src/ssw/common/sswmcpl.c

Line 515 in 1d1e3fd

int32_t new_np1 = new_nrss;

Is there a reason for this, or is it a bug?

Because I tried a simple conversion ssw -> mcpl -> ssw -> mcpl and I got:

$ ssw2mcpl test.w -s -c test.inp test.mcpl
ssw_open_file: Opened file "test.w":
ssw_open_file:    File layout detected : MCNP6
ssw_open_file:    Code ID fields : "mcnp" / "6"
ssw_open_file:    Title field : "Proton source on Tungsten target"
ssw_open_file:    Source statistics (histories):       63924
ssw_open_file:    Particles in file            :       15175
ssw_open_file:    Number of surfaces           :           1
ssw_open_file:    Histories at surfaces        :       11841
MCPL: Compressing file test.mcpl
MCPL: Compressed file into test.mcpl.gz
Created test.mcpl.gz

$ mcpltool test.mcpl.gz -l1
Opened MCPL file test.mcpl.gz:

  Basic info
    Format             : MCPL-3
    No. of particles   : 15175
    Header storage     : 1001 bytes
    Data storage       : 607000 bytes

  Custom meta data
    Source             : "MCNP6"
    Number of comments : 4
          -> comment 0 : "SSW file from MCNP6 converted with ssw2mcpl"
          -> comment 1 : "SSW metadata: [kods='mcnp', vers='6', title='Proton source on Tungsten target']"
          -> comment 2 : "The userflags in this file are the surface IDs found in the SSW file"
          -> comment 3 : "stat:sum:ssw_np1:                   63924"
    Number of blobs    : 1
          -> 674 bytes of data with key "mcnp_input_deck"

  Particle data format
    User flags         : yes
    Polarisation info  : no
    Fixed part. type   : no
    Fixed part. weight : no
    FP precision       : single
    Endianness         : little
    Storage            : 40 bytes/particle

index     pdgcode   ekin[MeV]       x[cm]       y[cm]       z[cm]          ux          uy          uz    time[ms]      weight  userflags
    0        2112      9.2563          10      9.7177    -0.73648     0.50329     0.86258   -0.051519  3.0355e-06     0.99986 0x00000001

$ mcpl2ssw test.mcpl.gz test.w test_converted.w
Opened MCPL file produced with "MCNP6" (contains 15175 particles)
Opening reference SSW file:
ssw_open_file: Opened file "test.w":
ssw_open_file:    File layout detected : MCNP6
ssw_open_file:    Code ID fields : "mcnp" / "6"
ssw_open_file:    Title field : "Proton source on Tungsten target"
ssw_open_file:    Source statistics (histories):       63924
ssw_open_file:    Particles in file            :       15175
ssw_open_file:    Number of surfaces           :           1
ssw_open_file:    Histories at surfaces        :       11841
Creating (or overwriting) output SSW file.
Initiating particle conversion loop.
Ending particle conversion loop.
Created test_converted.w with 15175 particles (nrss) and 15175 histories (np1).

$ ssw2mcpl test_converted.w -s -c test.inp test_converted.mcpl
ssw_open_file: Opened file "test_converted.w":
ssw_open_file:    File layout detected : MCNP6
ssw_open_file:    Code ID fields : "mcnp" / "6"
ssw_open_file:    Title field : "Proton source on Tungsten target"
ssw_open_file:    Source statistics (histories):       15175
ssw_open_file:    Particles in file            :       15175
ssw_open_file:    Number of surfaces           :           1
ssw_open_file:    Histories at surfaces        :       11841
MCPL: Compressing file test_converted.mcpl
MCPL: Compressed file into test_converted.mcpl.gz
Created test_converted.mcpl.gz

$ mcpltool test_converted.mcpl.gz -l1
Opened MCPL file test_converted.mcpl.gz:

  Basic info
    Format             : MCPL-3
    No. of particles   : 15175
    Header storage     : 1001 bytes
    Data storage       : 607000 bytes

  Custom meta data
    Source             : "MCNP6"
    Number of comments : 4
          -> comment 0 : "SSW file from MCNP6 converted with ssw2mcpl"
          -> comment 1 : "SSW metadata: [kods='mcnp', vers='6', title='Proton source on Tungsten target']"
          -> comment 2 : "The userflags in this file are the surface IDs found in the SSW file"
          -> comment 3 : "stat:sum:ssw_np1:                   15175"
    Number of blobs    : 1
          -> 674 bytes of data with key "mcnp_input_deck"

  Particle data format
    User flags         : yes
    Polarisation info  : no
    Fixed part. type   : no
    Fixed part. weight : no
    FP precision       : single
    Endianness         : little
    Storage            : 40 bytes/particle

index     pdgcode   ekin[MeV]       x[cm]       y[cm]       z[cm]          ux          uy          uz    time[ms]      weight  userflags
    0        2112      9.2563          10      9.7177    -0.73648     0.50329     0.86258   -0.051519  3.0355e-06     0.99986 0x00000001

[tkittel]

Well, what else should mcpl2ssw do, given that it can't reliably extract the original number of histories from MCPL? Would you prefer a value of 1?

[tkittel]

As a clarifying example: Assume you are converting an MCPL file written by another application into an ssw file with mcpl2ssw, what would be a meaningful value for the number of histories to set?

[marquezj]

I think the proper behavior would be to keep np1 if it is available in the file, or replacing it with something that is provided in the command line. And fail if neither is available.

Otherwise you get a file that could be read in MCNP, but that would have the wrong normalization if used in a calculation.

[tkittel]

But an MCPL file does not have a concept of "np1". See https://www.sciencedirect.com/science/article/pii/S0010465517301261 for what is available.

Of course if you do a round-trip ssw->mcpl->ssw, you might naively wish for the resulting ssw file to identical to the original one, but 1) it won't be, MCPL it is not an ssw file, and 2) what would be the point of such an operation? You could just use the original ssw file.

I can only guess, but I am suspecting that your use-case is to somehow perform some custom filtering or other modifications of the ssw file while it is in MCPL format and then convert it back? However, in that case you can in general not expect the number of histories to still have a well defined meaning in such a case. I mean, it might in a particular scenario where you are careful, but in general it could easily be misleading.

So one thing that could perhaps be considered, is to use the statsum field ssw_np1 (cf. https://github.com/mctools/mcpl/releases/tag/v2.1.0 and https://mctools.github.io/mcpl/format_statsum/) which ssw2mcpl now fills. However, we should think carefully about such an endeavour, since it would change behaviour which has been around for ~10 years. If you feel this would be a right path forward, please open an issue for such a feature request (you can refer to this discussion for simplicity).

[marquezj]

We discussed this with @dddijulio. Yes, the proper way to phrase it would be to use the value of ssw_np1 for np1 if it is available in the mcpl file. And yes, this came up from a discussion in the MCNP forum by someone interested in using mcpl --merge to combine two ssw files, and the first step was to check if I could recover the initial file.

I am going to create the issue.

[marquezj]

BTW, the np1 value is already available in mcpl2ssw() as orig_np1. It makes sense to update nrss (the number of particles that could be written), but np1 should be kept.

Edit: no, it is the wrong value. orig_np1 is the number of simulated particles in the reference ssw file.

[tkittel]

Exactly, your edit is correct. Orig_np1 is not the relevant number.