Agenda

1. Brief review of previous meeting for participants unable to join

2. Discussion about particle naming conventions and how to handle 'continuum' particles

   GND-1.8 and earlier use product labels like 'Fe56_c' and 'Fe56_s' to indicate nuclides with unknown excited state energies. c = continuum, s = sum of all energy levels. LLNL proposes getting rid of this convention, since these don't correspond to real particles. Will discuss proposed alternative.

   Proposed name changes to some elements in the particle database (PoPs)

   Provide explicit 'index' attribute for excited state energy level, to avoid having to parse strings

3. Review initial API documentation

   Current document includes classes like ReactionSuite, Styles, Reaction and CrossSection together with their methods.

Meetings notes

1. Particle naming conventions

   • Reaction products like Fe56_c or Fe56_s sometimes appear in GNDS evaluations. They indicate that the product nucleus is in an unknown excited state ('continuum' or 'sum of all'). Gamma decay information is sometimes supplied to tell how these go back to known states, but not always. Since these products don't correspond to a real particle, they cannot be used directly in transport simulations. Whenever they are produced (i.e. in Monte Carlo transport) they need to be converted into an actual particle. If decay information are not available, one option is to assume that a gamma was emitted to balance energy while de-exciting back to the ground state. Different codes may take different approaches, however, so we would prefer to be more explicit in the data about how it de-excites. Proposed action: instead of labelling the products as _c, require that the evaluation explicitly state how they are de-excited back to the ground state.

     Some potential problems with this approach were pointed out. TODO for Caleb: expand the examples to show various different cases and how GNDS could deal with them.

   • Suggest changing the 'nuclearLevel' tag to 'nuclide' in PoPs.

     General comment is that it's time to pick a name and stick with it. As long as the meaning is well-documented, users should be able to work with it.

   • Proposal: add an 'index' to nuclides and nuclei in PoPs. The index could be either an attribute or element, and helps avoid having to parse strings like "Co57_e10" to figure out the excited level index.

     Several votes in favor of this proposal.

2. Review initial draft of high-level API.

   • API document is available here. Note that this is a working document and will continue to change!
   • Comment: current API mixes conventions: 'getAttribute()' vs. 'attribute()'. Recommendation is to pick one convention and stick with it.
   • Dave comments that we need to add more flexible query methods, for example ReactionSuite::findReactions() that takes a pattern like "(n,p*)" to find every reaction that produces a proton.

Attendees

• C.M. Mattoon (LLNL)
• J. Conlin (LANL)
• D.A. Brown (BNL)
• D. Wiarda (ORNL)
• M. Dunn (affiliation)
• K. Tada (JAEA)

Assignments

• Caleb to organize next meeting, likely the week of Aug 28
• Also expand proposed API documentation
• If possible, will have Bret, Doro and others show how they are starting to handle GNDS data at the next meeting.