mcpl2openmc

[yrrepy]

It would be great if mcpl had the functionality to directly produce an OpenMC surface_source.h5 file.
https://docs.openmc.org/en/stable/io_formats/source.html?highlight=surface_source.h5

Much like mcpl2ssw and mcpl2phits.

Cheers,
Perry

[ebknudsen]

Hi Perry,
I've looked into the matter and I've now got a plan for creating such a tool. It could be there by next mcpl-release. I don't know when that is though.

cheers
Erik

[tkittel]

Great Erik @ebknudsen - an mcpl2openmc tool would certainly be enough to induce a new release all by itself :-)

For Perry @yrrepy in the meantime - if you (as you told me in your email) plan to produce some sort of code yourself, I strongly suggest you make your code capable of reading MCPL files directly, rather than relying on an intermediate ASCII representation. It should be essentially trivial:

https://mctools.github.io/mcpl/usage_c/#reading-mcpl-files

Feel free to ask follow up questions here if it gives your problems or if you have other issues.

I add @marquezj and @dddijulio here as well, since they might also have experience working with MCPL+OpenMC.

Cheers,
Thomas

[ebknudsen]

I was in fact looking in to the matter of having OpenMC read/write mcpl directly which should not be significantly more difficult than a standalone mcpl2openmc and vice versa, but adoption would likely take longer than in the lean and mean mcpl-organization.
cheers
Erik

[tkittel]

Absolutely, we are extremely lean ;-)

(and mean...)

[marquezj]

@norberto-schmidt has a solution for this. Not as elegant as something from @tkittel, but it works.

[yrrepy]

@tkittel ;
Thanks, I'll keep you appraised of whatever progress I make. I'm not much of a programmer so its just much easier for me to come up with some ad-hoc Linux text-hacking solution.

Cheerio!

[norberto-schmidt]

Hi eveyone,

The solution that I founded to transform an OpenMC surface source file into MCPL format is the next:

• First, I read the surface_source.h5 with Python, and write an ASCII format temporary file that contains the particles list. I forked the OpenMC project and generated a special branch to do this, so you can find an example of these functions: read_from_h5 and write_to_ascii
• Then, I transform this ASCII temporary file into MCPL format. To do this, I saw the MCPL script example that generates a random ASCII particles list (rawexample_writemcpl.c) and created an ascii2mcpl class. Also, I forked the MCPL project, there you can find the ascii2mcpl.c implementation.

I know it is not the best solution, but at least it worked for my Master's Thesis. Unfortaunly my OpenMC branch is not well commented, so please @yrrepy let me kindly know if you have any problem with the codes and if they work for you!

With kind regards,

Norbert

[paulromano]

Hi all! 👋 I just learned about MCPL this week and would love to see OpenMC support in one form or another! I'm curious to hear everyone's thoughts on whether it makes more sense to have functionality in OpenMC for reading/writing MCPL files (using the mcpl Python package), or if it would be more appropriate for that functionality to exist in MCPL itself? Either way, I think it won't be very difficult and would lend my support.

[yrrepy]

Hi guys,

so as it were, I just got the MCPL to OpenMC surface.source.h5 working yesterday. It comes from an original MCNP6.2 wssa.
It's a fairly compact Python script that I ended up using, inspired by your suggestions on the OpenMC forums, Paul.
Really, it was so simple, I'm not sure extra functionality is really needed elsewhere. (And this is from a non programmer, with not great scripting skills).
That said I do like the ease and tidiness of MCPL, so it would seem to be a natural fit to have it within MCPL.

As Thomas suggested I worked directly from the MCPL format rather than from a ASCII text output, I was hoping this would save in RAM, but it doesn't, it just saves the to text conversion step and having that giant file.
(I have an 8 GB WSSA, all told it required about 50-60GB of RAM to process it)

Paul, I might drop in on the OpenMC Discourse tomorrow and we can chat.

Cheerio,
Perry

[ebknudsen]

Hi guys, Great to hear that there is already a pipeline. On my hand I managed to put together half a c++-prototype to do the mcpl/openmc coupling before I had to attend to other things. I hope to be able to finish that in a week or two. Although the use of that somewhat limited now :-). But I do like to finish what I started. Perhaps it could be easily integrated into OpenMC if that is of interest. cheers Erik

…

On Thu, Apr 28, 2022 at 4:43 PM yrrepy ***@***.***> wrote: Hi guys, so as it were, I just got the MCPL to OpenMC surface.source.h5 working yesterday. It comes from an original MCNP6.2 wssa. It's a fairly compact Python script that I ended up using, inspired by your suggestions on the OpenMC forums, Paul. Really, it was so simple, I'm not sure extra functionality is really needed elsewhere. (And this is from a non programmer, with not great scripting skills). That said I do like the ease and tidiness of MCPL, so it would seem to be a natural fit to have it within MCPL. As Thomas suggested I worked directly from the MCPL format rather than from a ASCII text output, I was hoping this would save in RAM, but it doesn't, it just saves the to text conversion step and having that giant file. (I have an 8 GB WSSA, all told it required about 50-60GB of RAM to process it) Paul, I might drop in on the OpenMC Discourse tomorrow and we can chat. Cheerio, Perry — Reply to this email directly, view it on GitHub <#56 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGQ7FERIWPJCZXQZVCIHILVHKPZPANCNFSM5PYBMULQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[tkittel]

Hi everyone,

Great to see so much activity here! I think both avenues of approach are useful: A proper integration of mcpl-reading/producing code into OpenMC itself could indeed be the most convenient way, skipping intermediate file formats. However, creating such code can be tricky and it might take years before it will be adopted into a project like OpenMC. On the other hand, two standalone cmdline scripts a'la what we do for MCNP's ssw files could be immediately useful.

So I would suggest that, to the extent people are interested in contributing, those of you interested pursue the avenue of getting the direct mcpl-using code directly into OpenMC - then time will tell when and if it will one day become a superior alternative. In the meantime, I would be very happy to help guide some people creating some polished command-line tools for openmc integrated into the MCPL release itself. For that to happen, I would ideally ask those of you to volunteer to contribute to that to also "hang around" afterwards and help me answer support requests when someone asks for help or submit bug reports concerning that code. After all, I can't be an expert in all the MC codes, and we have done something similar for our McStas/MCNP/PHITS/etc. support and it seems to be working so far :-)

Let me know what you think.

Cheers,
Thomas

[paulromano]

@tkittel or others -- I was just looking at the Python mcpl package and as far as I can tell, it looks like it only reads MCPL files. Is that correct? I had naively hoped it could write them too, which would give me an easy path for getting conversion capabilities into OpenMC. The OpenMC team is also quite agile in getting contributions in, so it needn't take years to get something merged 😄

[ebknudsen]

Hi there,
I think in light of this that shall charge ahead with my project then. Seeing as OpenMC is likely to be my main sledgehammer for the foreseeable furture, I'd have no problem acting as mcpl/OpenMC middleman. The direction I was working in was rather based on the native OpenMC-code, so I'm thinking integration should be a SMOP (once I am done :-) ). It is likely, though, that I will ask you some questions in doing @paulromano if you don't mind.

[paulromano]

@ebknudsen sounds good, feel free to reach out!

[tkittel]

@paulromano yes, the mcpl python module is read-only (because of lack of time). However, while that is certainly something that should one day be improved upon, I think that any built-in support for reading mcpl files from OpenMC should in any case be using the C-module, to avoid any overhead.

@yrrepy when you say that you get 50GB of overhead for reading an 8GB file, I assume you are not talking about overhead from mcpl? If you read a few particles at a time then there should be very little memory usage from mcpl (it does not need to read the entire file in memory).

@ebknudsen sounds good! Yes, native openmc (c++) code using the mcpl C code should certainly be the most efficient (and hopefully also the most convenient).

A bit of advice: From my past experiences, one of the most tricky parts of these converters is mapping the particle codes with good coverage and fallback strategies. In particular, it might be worthwhile to check carefully that Ions/nuclei codes are dealt with correctly.

[ebknudsen]

Hi there,
Some info: I've now (finally) been able to extricate myself enough from other things to finish an OpenMC-internal input-iterface for MCPL, which seems to work quite well. Sorry it took so long. I'll put in a PR to OpenMC to pull that bit of code in...
Next bit is doing the same for output I imagine.

[ebknudsen]

@paulromano Btw. I imagine I could spend 5 min at the next OpenMC "gathering" to show this code.

[paulromano]

Yes, that would be great!

[yrrepy]

Hi all,
for the record below is my Python script to convert from MCPL to OpenMC 0.13.2.
Perry

import openmc
import mcpl
import h5py
import os
import numpy as np
from enum import Enum

mcplfile = mcpl.MCPLFile("mcpl.gz")

class ParticleType(Enum):
    neutron = 0              #  neutron   (2112 in MCPL)
    photon  = 1              #  photon    (22   in MCPL)
    electron= 3              #  electron  (11 in MCPL)
    positron= 4              #  positron  (-11 in MCPL)

MCparticles = []
for p in mcplfile.particles:
    weight = p.weight        
    energy = p.ekin*1000000  # MCPL MeV to OpenMC eV
    x  = p.x
    y  = p.y
    z  = p.z
    ux = p.ux
    uy = p.uy
    uz = p.uz
    t  = p.time/1000         # MCPL msec to OpenMC sec                  
    pp = p.pdgcode

    if pp == 2112: 
        pp = ParticleType.neutron
    elif pp == 22:
        pp = ParticleType.photon
    elif pp == 11:
        pp = ParticleType.electron
    elif pp == -11:
        pp = ParticleType.positron

    MCp = openmc.SourceParticle(r=(x, y, z), u=(ux, uy, uz), E=energy, time=t, wgt=weight, surf_id=1, particle=pp) 
    MCparticles.append(MCp)

openmc.write_source_file(MCparticles, 'source.h5')

Great Erik @ebknudsen - an mcpl2openmc tool would certainly be enough to induce a new release all by itself :-)

For Perry @yrrepy in the meantime - if you (as you told me in your email) plan to produce some sort of code yourself, I strongly suggest you make your code capable of reading MCPL files directly, rather than relying on an intermediate ASCII representation. It should be essentially trivial:

https://mctools.github.io/mcpl/usage_c/#reading-mcpl-files

Feel free to ask follow up questions here if it gives your problems or if you have other issues.

I add @marquezj and @dddijulio here as well, since they might also have experience working with MCPL+OpenMC.

Cheers, Thomas

[norberto-schmidt]

Hi @yrrepy, your script looks nice! I have just two comments regarding the conversion from MCPL to OpenMC:

• the time in the MCPL files is saved in milliseconds, while in OpenMC is in seconds, so there should be a conversion factor somewhere;
• OpenMC simulates also the electrons (pdg=11) and the positrons (pdg=-11), so maybe would be good to add them into the ParticleType class too.

[paulromano]

Just wanted to note here that openmc-dev/openmc#2116 was recently merged 🎉 Thanks to @ebknudsen for making it happen. Perhaps it makes sense to close this issue here now?

[tkittel]

Indeed, huge thanks to @ebknudsen for this nice work + @paulromano for shepherding it into OpenMC :-)

I will keep this issue open a bit longer, to remind myself that we need the new functionality mentioned on the MCPL website as well (perhaps after the next OpenMC release).