CEP 30 - Improvements to Cyclus Supply-Demand Framework

[dean-krueger]

After gathering informal community feedback, this is a more formal first draft of an official CEP on the website. I made sure it all displays correctly on a local spinup of the website I tested following the instructions in the README.

[gonuke]

A few editorial changes as well as some clarifications.

[gonuke]

This title is vague and all-encompassing.

This CEP should be targeted at sharing financial parameters between the R-I-F hierarchy, and the title should be clear at this more narrow scope.

[gonuke]

Suggested change

	Framework section of CEP 18. This CEP references moving the Supply-Demand from being
	requester based to being supplier based, with more considerations for economics. As a part
	of moving the DRE in that direction, it is necessary to add economic-based elements to
	the definitions of the Region, Institution, and Facility in such a way as to allow them
	to interact with each other economically. The proposal for doing so is to add sub-classes
	to each which will act as a method of communicating economic information between layers
	of the simulation.
	Framework section of [CEP 18](https://fuelcycle.org/cep/cep18.html). In particular, that CEP
	suggests that the introduction of economic concepts could allow the supplier to have more
	influence over the preferences of particular trading paths. As a part
	of moving the DRE in that direction, it is necessary to add economic parameters to
	the definitions of the Region, Institution, and Facility in such a way as to allow them
	to interact with each other to combine these parameters in meaningful ways. The proposal
	for doing so is to add sub-classes
	to each which will act as a method of communicating economic information between layers
	of the simulation.

[gonuke]

Suggested change

	Facility classes which will allow the communication of economic data between each layer
	of the CYCLUS simulation. The main feature of the subclass will be a hash table
	Facility classes which will allow the communication of economic/financial data between each layer
	of the CYCLUS Region-Institution-Facility hierarchy. The main feature of the subclass will be a hash table

[gonuke]

Suggested change

	API of a derived Institution archetype because it may not always be there. Because of the
	API of a derived Institution archetype because it may not always be there.
	This eliminates the use of the optional Toolkit to introduce economic/financial parameters
	into agents that are required to interact for those parameters since C++ doesn't provide
	a way to interrogate the API of an agent.
	Because of the

[gonuke]

by convention, I think (?) we prefer the R-I-F order for describing this

Suggested change

	interdependence of imagined economic functionality on the Facility-Institution-Region
	interdependence of imagined economic functionality on the Region-Institution-Facility

[gonuke]

(Remove unnecessary passive voice)

Suggested change

	It was decided to make the overall feature a subclass is to keep it in line with the class-subclass
	Implementing the overall feature as a subclass keeps it in line with the class-subclass

[gonuke]

Suggested change

	structure of other CYCLUS functionality, such as the Facility Institution Region - Agent structure.
	structure of other CYCLUS functionality, such as the `TimeAgent` or `Trader` features that are inherited this way.

[gonuke]

Suggested change

	add economic information to archetypes themselves at the beginning of simulations. This was tested,
	add economic information as an optional Toolkit feature to archetypes themselves at the beginning of simulations. This was tested,

[gonuke]

Not sure we need to focus on MS Windows as the model here.

This is also probably in addition to the Toolkit/code injection, but the code injection would include a facility for archetypes to register their ability to respond to financial requests in some globally accessible place.