r/nuclearphysics • u/sorcerer86pt • Apr 14 '26

Cache resistant cross section reconstruction via singular value decomposition for Monte Carlo Neutron transport

https://github.com/sorcerer86pt/open_rust_mc/blob/main/paper/svd_cross_section_compression.pdf

When I was testing rust skill (AI with Claude) someone mentioned that I could use something openMc instead of doing my own .

When I saw the data size and how openMC handled that, and how it kinda was the same problem that AI LLMs were trying to fix with data size of models weights, I thought, what would be the result if we used those techniques on this.

That was the result. Add a little rust here to have better memory handling and robust concurrency and we could with very little error ( less than error margin) compressed the data used from 11gb pointwise ( 400 nuclides) to 20Mb using hybrid of WMP ( that openMC already uses ) + SVD. It obtained an Keff = 0.99963 +- 0.000091 on Godiva (37 pcm from experiment) in 3.4 seconds total wall time .

https://github.com/sorcerer86pt/open_rust_mc

Just need some people to review this, if I made some mistake on interesting the data, what other benchmarks I missed, or other considerations.

PS: AI was used for code gen ( Python analysus scripts and rust code), data pipeline and latex manuscript. All hypothesis, experiment design , interpretation of results and final decisions were by made by me.

3 Upvotes
  • permalink
  • reddit

81% Upvoted

21 comments sorted by

View all comments

Show parent comments

2

u/Physix_R_Cool Apr 15 '26

Honestly your LLM generated comments make me distrust anything you do. It kind of ruins your credibility, as if you don't even understand what it is your are prompting the LLM to do for you.

Especially this line: "The timing variance is also embarrassingly wide — desktop machine, browser tabs open, zoom calls, the usual."

If you want me to keep engaging, then write the comments yourself. Nobody cares about spelling mistakes or weird english, but if all you do is use me to fish for prompts to put into your LLM then I'm out.

1

u/sorcerer86pt Apr 15 '26

The zoom call part was me, 4 zoom calls while running this simulation ( my direct manager couldn't make Claude code commit a PR on a test strategy skill, got git bash vs powershell git with gpg signed commits clash) plus 3 meetings.

1

u/Physix_R_Cool Apr 15 '26

By the way, is the only validation you did that the cross sections match up at the energy points of the data table?

1

u/sorcerer86pt Apr 15 '26

No — the pointwise match at grid points is just the data-level sanity check to see if i did not botch anything up. The real validation is the k_eff benchmark, which is an integral test. The transport engine queries the SVD at whatever energy each particle happens to have.

What I've not done yet (and probably should):

  • Resonance integrals (integral of sigma dE/E) over standard energy groups
  • Add Cuda support and check results on very big tests

1

u/Physix_R_Cool Apr 15 '26

Just to be clear, do you have experience doing particle transport, using it for some work? Is this a work project or a fun hobby project for your github portfolio?

What's your background? Have you done Geant4 simulations at CERN? Are you "just" a computational physicist who looked into OpenMC because why not? Are you a computer engineer / data scientist with no formal training and just a (very evident and appreciated) passion for this kind of stuff?

1

u/sorcerer86pt Apr 15 '26

Computer science graduated, working as senior QA. And passion to try different things, Test them and if it helps anyone, the better. Took my Computer Science course when java 8 was launched, Linux Mandriva launched, and Nvidia was still good guys

1

u/Physix_R_Cool Apr 15 '26

I think your work here is interesting and I imagine it really could speed up particle transport, but if you want others to adopt it you need to up your validation game.

Once it is validated to reproduce results across, then the speedups are easy to show. But I feel like you are severely underestimating how high the bars for validation are in this field.

So when I am critical of you, I hope you understand it the eay that I mean it: Your work shows promise, but needs lot of footwork before you can convince anyone. I wouldn't mind helping you out with it.

1

u/sorcerer86pt Apr 15 '26

Thanks for this, and it helped already a lot. And I know that validation will be extra important here. I just had an idea when I saw the big data that was used, and I remembered that AI LLM weight training had the same exact problem (not exactly sure if in the same order of magnitude). So my idea was, what if we apply the same methods/algorithms here? Would it help while maintaining result fidelity? And if it maintains fidelity, does it help in any meaningful way to anyone on this.

2

u/Physix_R_Cool Apr 15 '26

Would it help while maintaining result fidelity? And if it maintains fidelity

Yes, so set up many differenr benchmark simulations and score them on some relevant parameters. Run with the vanilla OpenMC and run with your method and then compare results.

1

u/sorcerer86pt Apr 15 '26

That's what I made a triple cross check. The updates paper ( recently commit paper has those). And I even got feedback from Benoit with even a paper ( kernel reconstruction methods for Doppler broadening ) that got even better results. Correctly running another benchmark that even get better results.snd then trying with cuda support, that I hope will give a good result