[Task] Ensure inputs are consistent

[abachma2]

What is this task about?

Ensure that the inputs across the Cycamore library are consistent, such as making instances of in_commods and incommod all have consistent naming and punctuation (i.e., all have underscores or none have underscores)

Why is this task needed?

This can make it easier for users to write input files if the inputs are all consistent in their formatting. This may also help in making future updates if they are all consistent.

Relevant resources or references

Discussed some in #645. One potential issue, is removal of backward compatibility with old input files that users may have. Will need to ensure we provide ample documentation about the changes.

How can this issue be closed?

This issue can be closed by ensuring the archetypes in the Cycamore library have consistency in the input variable names they use.

[dean-krueger]

Went in and checked. There is definitely a naming convention issue in Cycamore, specifically with in_commods (Storage, Sink, mixer) and variations on incommods (Reactor: fuel_incommods, Enrichment : feed_commod, fuel_fab: fill_commods, Separations: feed_commods). If it was as simple as just "incommods" vs "in_commods" I was going to choose "incommods" since it's slightly easier to type, but it seems like there's some deeper inconsistency here that I wanted to get further input on before I went and screwed with things.

[abachma2]

That is an interesting one. Thanks for checking this Dean. I think the Source archetype uses incommod. Part of the inconsistency I think comes from those that can accept many argument names and those that can only accept on. Some of the other variations are related to the traditional terms used for that process, like feed being the name of the input material for enrichment. I'm not sure we want to change any names that are more based on a physical process.

[gonuke]

I think it would be helpful to have a complete list of all commodity names in a table as part of this discussion

[dean-krueger]

I can see about putting something like this together. I may not get to it tonight, but I'll probably have bandwidth before either of you do.

[gonuke]

Here is the summary

enrichment:

• feed_commod - singular commodity
• product_commod - singular commodity
• tails_commod - singular commodity

fuel_fab:

• fill_commods - plural commodity
• fiss_commods - plural commodity
• topup_commod - singular commodity

mixer:

• in_stream - list of commodities (?)
• in_commods - plural commodity
• out_commod - singular commodity

reactor:

• fuel_incommods - plural commodity
• fuel_outcommods - plural commodity
• recipe_change_commods - plural commodity
• pref_change_commods - plural commodity

separations:

• feed_commods - plural commodity
• leftover_commod - singular commodity
• streams - list of commodities (?)

sink:

• in_commods - plural commodity

source:

• outcommod - singular commodity

storage:

• in_commods - plural commodity
• out_commods - plural commodity

[gonuke]

It looks like the only thing that really sticks out is:

source : outcommod --> source : out_commod

We may also want to review how we deal with lists of commodities, although I think the two implemented cases are slightly different data structures.