Data dissemination: addressing users’ feedback and needs

Data dissemination: addressing users’ feedback and needs Marco Verpelli Consultancy Meeting on Information Exchange on Developments and Operations of Nuclear Data Dissemination Services Vienna, 15-19 February 2024

Rationale Users’ feedback has been the major driver for the development of dissemination tools. Here below some relevant examples 2

Requests for custom queries on Structure & Decay data Plot A vs B(E2) strengths for transitions from first excited Jπ 2 states to the Ground State Plot Sn vs A for Led Plot A vs δ for E2/M1 transitions from Jπ 2 to 2 for e-e nuclides having 60 A 150 3

This required to parse the ENSDF into a data model easy to navigate, with an interface that translates the physics problem into a query 4

It’s not (only) the format, but the data model This below could be a JSON-formatted ENSDF dataset {“nuclide”:“135Xe“, “dataset”:“adopted”, “records”: {“type”: “L“ {“start”:10, “end”:19 , “value”:70 It is JSON, but would not provide a data model, it would not make possible to query the database without heavy programming and a deep knowledge of the ENSDF. An example on how data model and format are entangled is the ‘ ‘ (blank) in some uncertainty fields 5

depending on the context in which it is placed, it can mean: Take it from the Normalisation record at the beginning of the file It is unknown It is zero As a result , the uncertainty of some reference gamma lines in a decay is often not retrievable from the ENSDF dissemination tools 6

Requests for mobile devices Then we started to get requests for access from mobile devices. The data model was dumped in a SQLite database and wrapped in an app with graphic and query capabilities: Isotope Browser Now we try to design web applications that adapt their interface to the device : TALYS World 7

Requests for API, Open Source, and Python More and more, users are mainly interested in automated data download. To address this need, we made available an API api v0 notebook There are some problems though that restrict the full machine readability of the database. Some of them were addressed when building the RIPL discrete levels database. Futher problems raise when treating decay radiations: the „same“ gamma may be present in the database with different energies and intensities 8

See for example : Gamma energy Start level End level Dataset energy energy 119.46 1082.842 963.358 Adopted Sm-152 118.97 119.44 119.5 1082.816 1082.88 1082.77 963.363 963.40 963.25 Decay Decay Decay Eu-152 to Sm-152 Eu-152-m to Sm-152 Pm-152 to Sm-152 This makes it difficult, for example, to overlap all decay datasets to have an overall gamma spectrum, a request we often receive 9

To have a database fully machine readable and navigable, I am testing an extension of the approach taken for RIPL, which includes the decay radiation: NDLab 0.1 The Notebook included shows how to program in Python using this tool 10