openmc-dev
WMP compatibility issues
Bug Description
I am interested in using the windowed multipole (WMP) format to generate transient perturbed fission matrices, which requires the use of tally derivatives with respect to temperature. These tally derivatives are only supported when using WMP.
While exploring the implementation in multipole.py, I noticed that OpenMC relies on the external vectfit package, which is sourced from: https://github.com/liangjg/vectfit. However, that repository has not been maintained since 2020. This raises concerns about the long-term maintainability and compatibility of this dependency.
Steps to Reproduce
Not applicable – this is a support/development inquiry regarding external dependencies used in the WMP infrastructure.
Environment
- OS: Ubuntu 22.04
- OpenMC version: OpenMC 0.14.0
- Installation method: source build
- Nuclear data: JEFF33
Proposal / Request for Guidance
To improve long-term maintainability, I would like to contribute to OpenMC by integrating Jingang Liang's vectfit functionality natively into the OpenMC codebase (rather than relying on the unmaintained external repository).
-
Is this integration of interest to the OpenMC development team?
-
If yes, could you please guide me on the preferred approach to implement this within OpenMC?
- Should this be done as a full reimplementation?
- Is it preferable to preserve the existing API structure?
I would be happy to initiate a PR or work under the direction of a maintainer to ensure this contribution aligns with the overall architecture and roadmap of OpenMC.
Thank you for your guidance.
@azimgivron You read my mind; the fact that the vectfit library has sat unmaintained has been bothering me too and I had the same thought that it would be better off as part of OpenMC directly. I see that vectfit relies on xtensor and some bindings through pybind11. I am not a huge fan of that approach and would rather that we use something that relies on more common Python scientific packages (numpy, scipy, etc.). To explore the possibilities, I posed a question to ChatGPT about alternatives and learned that the same vector fitting algorithm is implemented in the scikit-rf package. So in principle we could either 1) adopt that as a dependency or 2) vendor the relevant lines of code, which ChatGPT asserts should be about ~120 lines of code. I also asked it to give me scikit-rf equivalents of the vectfit.vectfit and vectfit.evaluate functions that we rely on in the multipole module, and it produced some code that supposedly conforms to the same interface. If you want to take the chat transcript I linked above and run with it from there, that would be great. The next steps would be:
- Confirm whether the wrapper code it produced is correct or needs updating
- Vendor a stripped version of the necessary vector fitting functionality from scikit-rf's vectorFitting.py module
- Test it out by generating multipole data from an ENDF file and compare what you get with the updated implementation compared to the
vectfitmodule. Hopefully it agrees but if not it will require some more digging.
Hi, I think integrating vecfit for maintainability is very important, but I think it may have to be part of a broader discussion. @gridley and I have been debating switching vectfit to the aaa algorithm (see paper from last M&C), and there are also some discussions with another student about tweaking the WMP format to make it easier for the UQ methods we are developing. However, it might still be worth integrating vectfit in the short term. Ben
From: azimG @.> Sent: Thursday, July 3, 2025 8:41 AM To: openmc-dev/openmc @.> Cc: Subscribed @.***> Subject: [openmc-dev/openmc] WMP compatibility issues (Issue #3487)
[https://avatars.githubusercontent.com/u/27843989?s=20&v=4]azimgivron created an issue (openmc-dev/openmc#3487)https://github.com/openmc-dev/openmc/issues/3487 Bug Description
I am interested in using the windowed multipole (WMP) format to generate transient perturbed fission matrices, which requires the use of tally derivatives with respect to temperature. These tally derivatives are only supported when using WMP.
While exploring the implementation in multipole.pyhttps://github.com/openmc-dev/openmc/blob/develop/openmc/data/multipole.py, I noticed that OpenMC relies on the external vectfit package, which is sourced from: https://github.com/liangjg/vectfit. However, that repository has not been maintained since 2020. This raises concerns about the long-term maintainability and compatibility of this dependency.
Steps to Reproduce
Not applicable – this is a support/development inquiry regarding external dependencies used in the WMP infrastructure.
Environment
- OS: Ubuntu 22.04
- OpenMC version: OpenMC 0.14.0
- Installation method: source build
- Nuclear data: JEFF33
Proposal / Request for Guidance
To improve long-term maintainability, I would like to contribute to OpenMC by integrating Jingang Liang's vectfit functionality natively into the OpenMC codebase (rather than relying on the unmaintained external repository).
-
Is this integration of interest to the OpenMC development team?
-
If yes, could you please guide me on the preferred approach to implement this within OpenMC?
* Should this be done as a full reimplementation?
* Is it preferable to preserve the existing API structure?
I would be happy to initiate a PR or work under the direction of a maintainer to ensure this contribution aligns with the overall architecture and roadmap of OpenMC.
Thank you for your guidance.
— Reply to this email directly, view it on GitHubhttps://github.com/openmc-dev/openmc/issues/3487, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAHXBLR77ZWPQXU2PL7BOVL3GUQINAVCNFSM6AAAAACAWWK4ZKVHI2DSMVQWIX3LMV43ASLTON2WKOZTGE4TSMRVGY3TONA. You are receiving this because you are subscribed to this thread.Message ID: @.***>
My $0.02: integrating an equivalent of vectfit in the short term would be the move. AAA is best when fitting to individual smaller subsets of energy space, but hasn't been proven as a usable tool for finding all poles across the whole RRR energy range quite yet. The computational expense quickly grows from the SVD step with very large grids, so some algorithmic development might have to take place or prototyping using an iterative SVD rather than the direct solver used in most AAA papers is necessary. The result: plenty of uncertainty as to whether this works with the conventional WMP formulation. IMO, the best move is to simply change how WMP itself is formulated to remove the need to fit across all energies at the same time, but this would be a research development.
And regarding vectfit, I highly recommend a re-implementation of it using more mainstream tools and eating the small performance penalty that may come along with a pure python approach. I tried for about an hour once to get it built to no avail. For some reason, xtensor-python is pretty fragile.
