Adjust the Resource Creation and Transaction Paradigm to be more Logging Friendly (and more Complete) about cyclus HOT 7 CLOSED

Matt - The reason messages don't actually carry the resource themselves is because the markets adjust the offer quantity (splitting, etc.) and we don't want them to actually change resource inventory. Each model keeps its actual resources under tight control and never passes references to them outside object. When the actual material is sent, however, the sent and received resource is the same object in memory. So to summarize:

• The resources carried by message objects are just copies.
• The resources that are transacted (via the approveTransfer, removeResource, addResource trio) are one and the same - IDs are consistent.

We moved all transaction/resource bookkeeping into the approveTransfer method in the Message class - this is where you will want to put your table book-keeping.

from cyclus.

That's where the transaction row insertion occurs, but you're suggesting that the resource row insertion should occur there as well?

from cyclus.

yes-it has to occur there - or at least close by.

from cyclus.

The resources you want to boo-keep are the ones that are returned by the removeResource call in the approveTransfer method.

from cyclus.

void Message::define_table(){
  // declare the table columns
  column sender("SenderID","INTEGER");
  column receiver("ReceiverID","INTEGER");
   column resource("ResourceID","INTEGER");
  column time("Time","INTEGER");
  column price("Price","REAL");
  // declare the table's primary key
  primary_key pk;
  pk.push_back("SenderID"), pk.push_back("ReceiverID"),
    pk.push_back("ResourceID"), pk.push_back("Time");

The primary key (created above) doesn't work because there can be multiple resource objects per transaction. And I can envision multiple transactions during a single timestep that have the same sender and receiver. Basically, this means that the primary key for the transaction table needs to be a transaction ID. The transaction table will contain transID (pk), senderID (fk), receiverID (fk), Time, and Price. The Resource state table will contain stateID (pk), materialID (fk), transID (fk), quality, quantity, etc. We will also need a resource table that will contain resourceID (pk), date created, creatorID (fk), date destroyed, destroyerID (fk), etc. And of course the composition table containing stateID (fk), isotope #, quantity.

from cyclus.

Thanks, Robert. This is not a finished product.

On Mon, Feb 20, 2012 at 8:11 AM, Robert Carlsen <
[email protected]

wrote:

void Message::define_table(){
 // declare the table columns
 column sender("SenderID","INTEGER");
 column receiver("ReceiverID","INTEGER");
  column resource("ResourceID","INTEGER");
 column time("Time","INTEGER");
 column price("Price","REAL");
 // declare the table's primary key
 primary_key pk;
 pk.push_back("SenderID"), pk.push_back("ReceiverID"),
   pk.push_back("ResourceID"), pk.push_back("Time");

The primary key (created above) doesn't work because there can be multiple
resource objects per transaction. And I can envision multiple transactions
during a single timestep that have the same sender and receiver.
Basically, this means that the primary key for the transaction table needs
to be a transaction ID. The transaction table will contain transID (pk),
senderID (fk), receiverID (fk), Time, and Price. The Resource state table
will contain stateID (pk), materialID (fk), transID (fk), quality,
quantity, etc. We will also need a resource table that will contain
resourceID (pk), date created, creatorID (fk), date destroyed, destroyerID
(fk), etc. And of course the composition table containing stateID (fk),
isotope #, quantity.

---

Reply to this email directly or view it on GitHub:
https://github.com/cyclus/core/issues/41#issuecomment-4054156

from cyclus.

The database system currently works as intended, so I'm closing this issue. However, we should note the following:

• in the simulation, when a material is split, a NEW material is made (with a new id, etc.)
• in the database, when a material is split, we still want to reference the original material -- accordingly resource objects now have an originalID_ member.
• a new material is registered in the database when its setOriginatorID is called. Facilities must call this function when they want the simulation to know that a new resource has entered the sim. It is analogous to the setParentID function.
• the flow of material information is maintained through the Transactions table. The Resources table notes the initial quantity when a resource enters the simulation and the Transactions table records who has how much of that resource as the simulation progresses, referencing the resources' originalID_ to keep track of isotopics (i.e. a resource state). Much documentation writing to come.

from cyclus.