Replies: 5 comments 4 replies
-
Based on these two requirements, I recommend make this nuclide system an independent repo, outside the ARMI repo. It seems like (1) will be the time-consuming bit, but (2) is easy enough. Will this library include all the actual data, or will users have to find/generate most of the high-detail data files themselves? |
Beta Was this translation helpful? Give feedback.
-
|
Agreed on the separate repo thing. I don't think we want to be maintainers of data itself. We should provide easy ways to go get it/import it from NNDC and/or related |
Beta Was this translation helpful? Give feedback.
-
|
This is related to #455 to a degree. |
Beta Was this translation helpful? Give feedback.
-
|
I (possibly falsely) opened a smaller Issue that would be entirely consumed by this work: #581 |
Beta Was this translation helpful? Give feedback.
-
|
This might be a good starting place for a universal nuclide library, written in rust - https://github.com/JASory/Iridium |
Beta Was this translation helpful? Give feedback.
-
|
Just looking at that and comparing against our requirements makes me worried about how the data is hard-coded in code, not user-loadable or importable from a different library |
Beta Was this translation helpful? Give feedback.
-
|
Agreed. JASory/Iridium#1 |
Beta Was this translation helpful? Give feedback.
-
|
The data is hardcoded by design as it was assumed that it would be used for non-rigorous simple modeling, so concern was primarily for simplicity on the user side. Looking over the specifications I could easily extend it meet most of the specifications. The only issue would be constructing from file input which would require a new structure. The hardcoded data however will remain as the defaults. |
Beta Was this translation helpful? Give feedback.
-
|
Some progress on updated the nuclide package for meeting these requirements in #998 |
Beta Was this translation helpful? Give feedback.
-
Most nuclear engineering codes need basic information about nuclides, and most have independent nuclide systems built in. ARMI is no exception, and has a whole subpackage called nucDirectory to handle it. . We had some discussions with other folks in the past about the potential to build a relatively simple and portable nuclide library that could potentially be shared across the community and used in a variety of codes. Doing so may help with code interoperability, and would certainly help future people who need some nuclide info. So we decided that we should at least try drafting some requirements.
Essentially, this system should do roughly what a physical chart of the nuclides can do.
Functional Requirements
The nuclide library shall represent fundamental nuclide information
This would include, at least:
It could conceivably also include other information often found in charts of the nuclides, such as:
The nuclide system shall load nuclide data from some standardized data sources
Nuclide information should be loadable from at least the following sources (and be extensible to others):
The nuclide library shall facilitate nuclide lookups by A, Z, M
Clients shall be able to pass in A, Z, M and get a nuclide object from which, e.g. atomic weight can be obtained
The nuclide library shall allow nuclide lookups from a variety of textual representations
Clients shall be able to pass in, e.g.
U235and obtain a nuclide object from which, e.g. atomic weight can be obtained. Formats that shall be supported include:Uranium-235U2350922350The nuclide library shall generate string generation of representations consistent with the textual nuclide lookup requirement above
For example, any given nuclide object shall be able to be printed out in Element/A, or ZZZAAAM format as text
The nuclide library shall allow general mappings of certain transmutation/decay types
If a user has a nuclide (e.g.
Pu239) and wants to find out the product nuclide after decay or transmutation (e.g. alpha decay), then the nuclide library shall return the resulting nuclide (U235).Traversals supported shall include (at least):
(Note that these are all simple operations of A and Z. The system shall only handle purely physical decays and will not directly facilitate decay chain truncations)
Portability requirements
The nuclide library shall be accessible directly in Python, C, C++, and Fortran
To facilitate the wide variety of nuclide codes, the nuclide library must be easily usable in interpreted Python code as well as compiled languages.
The nuclide library shall be pip installable
To facilitate ease of use in Python projects, the library shall be pip installable on relatively barebones Windows, Mac, or Linux systems
Performance requirements
The nuclide library shall require less than 5 MB of RAM
Heavier-weight systems (e.g. depletion codes) may be built upon this library as a foundation, but this library itself is not expected to be too big.
The nuclide library shall be able to map Z, A, M to an object and return the atomic mass in less than 1 microsecond
Speed often matters.
(Note: this number is chosen rather arbitrarily and can be adjusted if necessary)
Things explicitly left out
The nuclide library shall not have any microscopic cross sections on it
Cross sections can always be loaded by clients onto objects based on these if necessary.
Related projects
Beta Was this translation helpful? Give feedback.
All reactions