Discussion of pebble movement infrastructure

[ZoeRichter]

This issue is for workshopping the broader code infrastructure didymus will use for moving pebbles within an active core. While there will be multiple modes of movement, there will be a necessity for tracking pebble data that they will share (at the very least).

didymus will need to track:

• pebble material
• a pebble's unique ID, which should not change over the pebble's lifetime
• number of passes each pebble has made (for a mulitpass cycle)
• If a pass would cause a pebble's material to change (for example, if material is determined by pass, and a pebble leaves its first pass and goes to its second) then didymus needs to be able to recognize this, identify what material it currently is, and update it to the corresponding new material
• pebble discharge criterion (once a pebble has been discharged, should its unique ID be retired as well, or reused?) (should didymus create some sort of output tracking pebbles that exit the core, and when?)

(this initial list may be updated if more things to track are thought of)

[katyhuff]

• pebble material
  • less get some more fidelity on what this means.... maybe material composition/isotopic vector (or what Cyclus calls "compID") ?
• a pebble's unique ID, which should not change over the pebble's lifetime
  • yes
• number of passes each pebble has made (for a mulitpass cycle)
  • yes
• If a pass would cause a pebble's material to change (for example, if material is determined by pass, and a pebble leaves its first pass and goes to its second) then didymus needs to be able to recognize this, identify what material it currently is, and update it to the corresponding new material
  • all passes will change the material composition
  • definitely review cyclus approach here
• pebble discharge criterion (once a pebble has been discharged, should its unique ID be retired as well, or reused?) (should didymus create some sort of output tracking pebbles that exit the core, and when?)
  • do not reuse unique ids.

[katyhuff]

This issue can be closed with a short description of the proposed structure of capabilities to be implemented in didymus and discussion of complementary capabilities potentially to be implemented in other tools. This could be executed as a .rst file in the docs directory of didymus.