khuff@mdt-huff:~/repos/cyclus/build/debug(clean_inputs) $ ./cyclus sample.in.xml 

|--------------------------------------------|
|                  Cyclus                    |
|       a nuclear fuel cycle simulator       |
|  from the University of Wisconsin-Madison  |
|--------------------------------------------|

 ERROR(core  ):cyclus exception: You have tried to access the parent of Exelon but the parent pointer is NULL.

The backtrace just after the exception is :

(gdb) run sample.in.xml 
Starting program: /Users/khuff/repos/cyclus/build/debug/cyclus sample.in.xml

|--------------------------------------------|
|                  Cyclus                    |
|       a nuclear fuel cycle simulator       |
|  from the University of Wisconsin-Madison  |
|--------------------------------------------|


Breakpoint 1, Model::parent (this=0x1011377a0) at /Users/khuff/repos/cyclus/src/Models/Model.cpp:317
317   if (parent_ == NULL){
(gdb) bt
#0  Model::parent (this=0x1011377a0) at /Users/khuff/repos/cyclus/src/Models/Model.cpp:317
#1  0x00000001007702c6 in DeployInst::init (this=0x1011377a0, cur=0x10065b740) at /Users/khuff/repos/cyclus/src/Models/Inst/DeployInst/DeployInst.cpp:31
#2  0x00000001000035fe in Model::create (model_type=@0x7fff5fbfe318, cur=0x10065b740) at /Users/khuff/repos/cyclus/src/Models/Model.cpp:93
#3  0x0000000100003e18 in Model::load_institutions () at /Users/khuff/repos/cyclus/src/Models/Model.cpp:182
#4  0x00000001000037f8 in Model::load_models () at /Users/khuff/repos/cyclus/src/Models/Model.cpp:112
#5  0x0000000100029a7f in InputXML::load_file (this=0x100602140, filename=@0x7fff5fbff470) at /Users/khuff/repos/cyclus/src/Input/InputXML.cpp:118
#6  0x000000010007b430 in main (argc=2, argv=0x7fff5fbff910) at /Users/khuff/repos/cyclus/src/App.cpp:103

There are number of concepts that will be valuable to many/all module developers. We need a common mechanism to provide implementations of these concepts, to facilitate adoption and streamline the process of adding new modules while maintaining consistency in the representation of those concepts. This consistency will benefit I/O handling.

Create a growth region which takes as input some growth/demand function and the builds facilities based on that demand. It should be general enough to support demand for any commodity, but shall be tested first with reactors.

Next action: Write up initialization and tick implementation
Next action: Review previous work and test implementation
Next action: finish tick implementation
Next action: write tests (for as many concerned classes as possible)
Next action: clean up test files, submit

Like core issue https://github.com/cyclus/core/issues/245. Need to be able to build documentation without seeking all the dependencies.

Robert brought up the fact that this would greatly speed up build time during subsequent builds. It'll add more to the implementation file, but the implementation file will directly match the header file.

This was https://github.com/cyclus/core/issues/181 .

The argparse module provides excellent support for managing cli args. Use it.

simple fix. it currently can increase supply but cannot decrease it.

A complete once-through fuel cycle has the following material flow:

• u235 mine
• conversion
• enrichment
• fabrication
• reactor
• storage

How many of these do we actually want to model? how do we determine when facilities are built?

We currently demand that the reactors meet some growth scenario, and each other facility must provide materials to meet that fuel assembly demand.

Note that what we really care about, at least at first blush, is the material flow between facilities, not neccesarily the building of facilities. However, we can't just have an infinite reactor provide material to an infinite capacity conversion facility; we would lose that information.

I can think of three possible ways to approach this - no ordered in the order of increasing complexity:

1. explicitly declare the build decisions of supporting facilities. one idea would be to have all supporting facilities in a 'build region' as it exists and have the reactors in a 'growth region' as it is conceptualized.
2. have facilities with finite capacities with some ability to provide a manager information regarding what % of that capacity was requested on the last time step. If that % passes an upper threshold, the manager would order a new facility be built.
3. have facilities with infinite capacities but "intelligent" orders. i.e., resolve markets in a given order from downstream to upstream (i.e., resolve fresh fuel to reactors, then enrichment to fab, etc.). the facility would have its offers resolved and then could make requests to upstream to match that offer. markets would then resolve in reverse order.

Next action: document implementation approach and pros and cons of easiest strategy that will provide a way forward

We have discussed the issue of not being able to track/book-keep internal stocks of facilities (e.g. wet/dry storage). I propose a new module dev helper tool that will allow this. It will be a model subclass for which instances can easily be created without the use of dynamic loading/initialization.

Implementation:

• Inherit from Model class and satisfy entire concrete Model interface
• contain a single resource buffer
• provide add/remove resource methods that push/pull from the solitary resource buffer
• expose public methods that allow for querying/configuring the storage sub-facility's state (e.g. capacity, space, etc.) - these will essentially wrap some of ResourceBuff's methods.
• To move resources to/from a sub-facility storage, a facility will just create and execute transactions directly (not using messages or markets) with itself as the supplier/requester and the sub-storage as the counterpart.

Benefits:

• Allows for book-keeping of internal facility state
• doesn't require additional book-keeping infrastructure - relies on what we already have.
• Developers can choose whether or not the added effort/code is necessary. It is an opt-in thing.

Thoughts?

There are many ideas emerging for what to include and make available for module developers. Rather than making new issues right now for each of them, we should have a cyclus.github.com page to capture them.

And until then:

• tools to generate particular types of requests/offers for a particular kind of market
• resource buffers
• output data models
• time series representations

I noticed that on many concrete models, there is a lot of code in xml constructors and copy methods that seems very repetitive. Here is a snippet from recipereactor xml constructor:

 47   // initialize ordinary objects
 48   capacity_ = strtod(XMLinput->get_xpath_content(cur,"capacity"), NULL);
 49   //cycle_length_ = strtod(XMLinput->get_xpath_content(cur,"cycletime"), NULL);
 50   lifetime_ = strtol(XMLinput->get_xpath_content(cur,"lifetime"), NULL, 10);
 51   startConstrYr_ = strtol(XMLinput->get_xpath_content(cur,"startConstrYear"), NULL, 10);
 52   startConstrMo_ = strtol(XMLinput->get_xpath_content(cur,"startConstrMonth"), NULL, 10);
 53   startOpYr_ = strtol(XMLinput->get_xpath_content(cur,"startOperYear"), NULL, 10);
 54   startOpMo_ = strtol(XMLinput->get_xpath_content(cur,"startOperMonth"), NULL, 10);
 55   licExpYr_ = strtol(XMLinput->get_xpath_content(cur,"licExpYear"), NULL, 10);
 56   licExpMo_ = strtol(XMLinput->get_xpath_content(cur,"licExpMonth"), NULL, 10);
 57   state_ = XMLinput->get_xpath_content(cur,"state");
 58   typeReac_ = XMLinput->get_xpath_content(cur,"typeReac");
 59   CF_ = strtod(XMLinput->get_xpath_content(cur,"elecCF"), NULL);

Much of the xml input is simply key-value pairs. capacity=15, state="hello", etc. How feasible would it be to provide a mechanism for developers to do something like this in their input file:

<doubles>
   <capacity>15</capacity>
   ...
</doubles>
<strings>
   <state>hello</state>
   ...
</strings>

... etc.

We could conceivably add a std::map<std::string, double>, std::map<std::string, std::string>, etc. to the model base class. The xml initialization process could automatically discover and populate these key-value model member vars.

Disbenefits:

• loss of fine-grained control during initialization and copying
• potential for run-time errors - if a key/value doesn't exist - we would likely want to force dev's to use some sort of doubleProperty(name), stringProperty(), functions that would check for non-existing keys
• slightly more complicated "under-the-hood" initialization process.

Benefits:

• Developers would not be forced to use the key-value functionality - they could continue to do things as they are done now if they wished
• Model creation becomes much simpler (lower barrier to entry). For many modules, a developer might not need anything other than key-value pairs of fundamental types. Model creation becomes almost exclusively a matter of coding handleTick/Tock behavior.
• reduce likelyhood of errors in model initialization and copying. This is a very legitimate concern. RecipeReactor actually had a nasty copy bug where a member-var value was not being copied - it took me a while to isolate and correct this bug.

Thoughts?

@gidden, @katyhuff

Robert brought this issue up, and I've been thinking about ways to keep "future needs" out of our base model API.

We basically have employed a way to do this via our Communicator class. Could we pull all of the build-related methods out of Model, RegionModel, and InstModel and instead make a Subclass "Builder"?

We may find that we want all Region Models and all Inst Models to inherit from builder, but we could, at the very least, just let the BuildRegion and BuildInst modules inherit.

In general, I think this is a reasonable strategy we could follow. When in doubt: make a inheritable class. If we find that we're using that way too much, we can either make a higher abstraction layer inherit from that class or merge its API with a higher abstraction class as we see fit.

@rwcarlsen , does this type of separation satisfy your core API concerns?

A high level definition of this problem exists. It is essentially a 2 stage once through cycle. A complete definition of this problem should be documented, including a candidate input file.

Based on the algorithm explored in Genius v2, implement a market that will solve a linear system to mix barrels of candidate material to achieve the optimal match for a known recipe of isotopes.

When a user defines a SeparationMatrixFacility, it is possible that they don't account for 100% of every element. That is, the sum of all the separation fractions across all streams for some element may be less than 100%.

If so, an extra stream should automatically be generated that captures all the excess material.

Comment 1 by project member uwgonuke, Aug 3, 2011

Additional comments:

1. What if they sum to >100% - throw exception to user and halt?
2. User should get warning if/when extra stream is generated.
3. Unclear: what commodity/market should the extra stream be connected to?

This is a top-level issue that includes some sub-tasks:

Tasks:

• debug existing SeparationMatrixFacility (https://github.com/cyclus/core/issues/159 a.k.a. #20)
• change behavior to offer multiple barrels (https://github.com/cyclus/core/issues/161 a.k.a. #18)
• change behavior to satisfy each transaction with a single material object(https://github.com/cyclus/core/issues/162 a.k.a. #17 )

So I ran into this when looking for the message problem addressed in a recent pull request. If I make a change to a model and make install it again, I get multiple entries in the master cyclus.rng file for that model. This causes rng parse errors for any/every input file. I'm not sure what kind of change will be required, but the behavior I was expecting (just reinstall the updated version for it to work) was not what happened.

To help reduce the barrier to entry for developers with working code, in another language, upon which they will base their module, we can provide wrappers that demonstrate how to do that for a set of different languages: FORTRAN, Python, C (, others?)

I'm cleaning up some of the input files, and taking note of the ones that are failing. I recognize that some are under development. But, in case they've recently become broken and the author was unaware, I wanted to flag them.

One is input/benchmarks/vision_genius_v1 :

khuff@mdt-huff:~/repos/cyclus/build/debug(clean_inputs) $ ./cyclus p5v1.xml 

|--------------------------------------------|
|                  Cyclus                    |
|       a nuclear fuel cycle simulator       |
|  from the University of Wisconsin-Madison  |
|--------------------------------------------|

 ERROR(core  ):ERROR occured in sendTock(): cyclus exception: BatchReactor v1:ReactorA0 received more fuel than was expected, which is not currently acceptable behavior; it has a surplus of 79567.2.
 ERROR(core  ):ERROR occured in sendTock(): cyclus exception: BatchReactor v1:ReactorA0 received more fuel than was expected, which is not currently acceptable behavior; it has a surplus of 79567.2.

The first attempt at implementing the output database was a rough draft. It should be cleaned up and the website should be updated with the new schema.

All methods should reduce copying as much as possible.

The table creation and row addition API should be simplified.

The BookKeeper should log all predefined recipes during load_recipes()

This idea is a major change from our current paradigm. I claim that it will have very large benefits (this is how we should be talking about markets). It has a few key points:

• Markets are not agents, they are representations of graphs
• The market graph is comprised of nodes, representing agents.
• Markets should have a set of agents which are actors in that market
• At any given time step, there is a set of players in that market, which is a subset of the actors
  • this can be thought of as a boolean variable, turning on and off actor arcs
• Actors should register with the market when born (in setParent) and should be removed from the market's registry when they die (destructor?)
• Associated with each node is a notion of flow constraints. A node has a maximum in-flow and out-flow.
  • offers and requests should set these flow constraints
• The modularity of the market models should come with the solution technique
  • i.e., until we determine additional complexity, only the resolve() function should be virtual. all other functionality should be defined in the base MarketModel class
  • we currently have two main markets -> null and greedy. the resolve functions could be the same, with the greedy market sorting nodes first.

all concrete facilities must write:

• a function to copy xml-initialized members (copyInitializedMembers)
• a function to initialize concrete members (once entered into the simulation with a parent)

The cyclus.rng configure step needs to result in two files.

The first is a copy of cyclus.rng.in with the concrete module references and includes in place as well as @ directives where future modules can add themselves. That is, it will look something like :

<grammar xmlns="http://relaxng.org/ns/structure/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">

  <include href='../lib/Models/Converter/StubConverter/StubConverter.rng'/>
  <include href='../lib/Models/Converter/SWUeUF6Converter/SWUeUF6Converter.rng'/>
  <include href='../lib/Models/Facility/BatchReactor/BatchReactor.rng'/>
  <include href='../lib/Models/Facility/ConditioningFacility/ConditioningFacility.rng'/>
  <include href='../lib/Models/Facility/NullFacility/NullFacility.rng'/>
  <include href='../lib/Models/Facility/SinkFacility/SinkFacility.rng'/>
  <include href='../lib/Models/Facility/SourceFacility/SourceFacility.rng'/>
  <include href='../lib/Models/Facility/StubFacility/StubFacility.rng'/>
  <include href='../lib/Models/Inst/BuildInst/BuildInst.rng'/>
  <include href='../lib/Models/Inst/DeployInst/DeployInst.rng'/>
  <include href='../lib/Models/Inst/FixedInst/FixedInst.rng'/>
  <include href='../lib/Models/Inst/StubInst/StubInst.rng'/>
  <include href='../lib/Models/Market/ConverterMarket/ConverterMarket.rng'/>
  <include href='../lib/Models/Market/GreedyMarket/GreedyMarket.rng'/>
  <include href='../lib/Models/Market/NullMarket/NullMarket.rng'/>
  <include href='../lib/Models/Market/StubMarket/StubMarket.rng'/>
  <include href='../lib/Models/Region/BuildRegion/BuildRegion.rng'/>
  <include href='../lib/Models/Region/NullRegion/NullRegion.rng'/>
  <include href='../lib/Models/Region/StubRegion/StubRegion.rng'/>
  <include href='../lib/Models/Stub/StubStub/StubStub.rng'/>
  <include href='../lib/Models/StubComm/StubStubComm/StubStubComm.rng'/>
  @RNG_INCLUDES@

The other is the fully configured copy that is readable by the xml rng schema :

<grammar xmlns="http://relaxng.org/ns/structure/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">

    <include href='../lib/Models/Converter/StubConverter/StubConverter.rng'/>
  <include href='../lib/Models/Converter/SWUeUF6Converter/SWUeUF6Converter.rng'/>
  <include href='../lib/Models/Facility/BatchReactor/BatchReactor.rng'/>
  <include href='../lib/Models/Facility/ConditioningFacility/ConditioningFacility.rng'/>
  <include href='../lib/Models/Facility/NullFacility/NullFacility.rng'/>
  <include href='../lib/Models/Facility/SinkFacility/SinkFacility.rng'/>
  <include href='../lib/Models/Facility/SourceFacility/SourceFacility.rng'/>
  <include href='../lib/Models/Facility/StubFacility/StubFacility.rng'/>
  <include href='../lib/Models/Inst/BuildInst/BuildInst.rng'/>
  <include href='../lib/Models/Inst/DeployInst/DeployInst.rng'/>
  <include href='../lib/Models/Inst/FixedInst/FixedInst.rng'/>
  <include href='../lib/Models/Inst/StubInst/StubInst.rng'/>
  <include href='../lib/Models/Market/ConverterMarket/ConverterMarket.rng'/>
  <include href='../lib/Models/Market/GreedyMarket/GreedyMarket.rng'/>
  <include href='../lib/Models/Market/NullMarket/NullMarket.rng'/>
  <include href='../lib/Models/Market/StubMarket/StubMarket.rng'/>
  <include href='../lib/Models/Region/BuildRegion/BuildRegion.rng'/>
  <include href='../lib/Models/Region/NullRegion/NullRegion.rng'/>
  <include href='../lib/Models/Region/StubRegion/StubRegion.rng'/>
  <include href='../lib/Models/Stub/StubStub/StubStub.rng'/>
  <include href='../lib/Models/StubComm/StubStubComm/StubStubComm.rng'/>

These will both be installed in the ${install_prefix}/cyclus/share directory.

The same should be true down at the bottom where the FAC_REFS, INST_REFS, etc. are concerned.

This problem is defined at a high level in the milestone definition, but needs a complete definition include input file.

This is related to issue https://github.com/cyclus/core/issues/20 (a.k.a. #40 ) . The SeparationsMatrixFacility should be checked for errors and tested to confirm that it performs a matrix based separations process in a straightforward and simple way.

Parent: https://github.com/cyclus/core/issues/160 (a.k.a. #19)
Blocked by: none
Blocking: https://github.com/cyclus/core/issues/161 (a.k.a. #18)

I am building cycamore and the only thing that doesn't work is trying to set CYCLUS_ROOT_DIR on the command line.

prompt%> cmake -DCYCLUS_ROOT_DIR=/path/to/cyclus/install ../cycamore/src

ends up with CYCLUS_ROOT_DIR unset in Findcycluscore. Only if I set it as an environment variable does it work.

as discussed in #27

To reduce material logging in the output DB, each individual transaction should be satisfied by a single material object based on the mixture of "barrels" defined in the satisfied request.

Parent: https://github.com/cyclus/core/issues/160 (#19)
Blocked by: https://github.com/cyclus/core/issues/161 (#18)
Blocking: none

Add capability for recipe reactors to move batches to wet and dry storage buffers with:

• predefined residence times
• possibility of initial stocks

pretty easy to implement. there's an example of it in cyclopts.

As described in our meeting on 05/14/12, the only difference between a GreedyMarket and a NullMarket is that the GreedyMarket sorts its offers and requests before it attempts to resolve them.

That's a pretty small difference, but we completely duplicate the code between the two. Are we ok with this?

Allows modules who need information about commodity supply/demand to communicate that information.

Comprised of:

• issue #56
• issue #57
• issue #58
• issue #61

This issue is a subpart of issue #37.

Make sure github issues are moved to any new repositories with which they are associated. (https://github.com/mkorenkov/tools/blob/master/gh-issues-import/gh-issues-import.py).

This issue is blocked by issue https://github.com/cyclus/core/issues/191 in which modules are moved into their own repositories.

Next Action : Decide whether it's okay to use the script to grab 27/37 issues (without comments) and port the rest over manually. If so, do that. Else, figure something else out.

Concerning Issue https://github.com/cyclus/core/issues/81, a new solution is suggested. The current need for an input wrapper is driven by the need for an unfettered ability to create new agents from prototypes in tests. Another solution is to have access to a suite of (currently only header files) Test agents (Region, Inst, Facility, Market) as createable agents in the test framework. This will require three steps:

1. Create implementation files for each, including an extern constructor function and a deep copy function that does not access the cyclus core (e.g. accessing a parent pointer)

2. Modify the build system such that it builds these libraries in an appropriate directory and allows global (all tests) access to these libraries

3. Modify the cyclus core so that it will look for constructors based a default value (the status quo) or a specified path (e.g. to the Testing directory)

I claim that this functionality is critical to my path forward regarding the BuildRegion (I can do work arounds, but why not do it right to begin with?). I'll add this to my list of things to do, but it will also take a back seat to the benchmarking effort. Does anyone have a less pressing schedule to work on this sooner rather than later? @rwcarlsen @katyhuff

Presumably, there will be concrete models that make offers for more than one kind of resource/material composition. Currently, there is no good way for a facility to determine what resource(s) a matched offer requires them to send.

A helper tool could be created that mapped some unique offer handle to (a list of) resources assosiated with that offer. If/when a matched request returns from a market, the removeResource method of the facility could simply retrieve the resources from the key-value store (barring any order splitting) easily.

There are finer points that would need to be considered and worked out, but I think a tool like this has potential to become very useful - especially for facilities that deal in multiple output streams (e.g. separations).

I am realizing that exceptions are much more helpful if they are specific enough that callers know what to do if it is thrown. Something like CycRangeException (as we currently have) could have been thrown by tons of different things, and the caller won't know what to do if it catches one. But if something like CycOverCapException is caught, the caller knows that the materials didn't all fit - and weren't successfully moved.

ToDo:

• Make class-specificish exceptions instead of the super generic ones (all should subclass CycException).

• change code to throw appropriate specific exception.

• actually catch the exceptions in try/catch blocks. Recover from the error if possible. If recovery is not possible, do:

  LOG(LEV_ERROR, ...) << [what happend];
  

next action: write the function including in it the leaveMarket method

Issue https://github.com/cyclus/core/issues/78 fleshed out a full picture for the BuildRegion class. As of now, the facility requirements section is complete. This ticket is for the completion of the capacity requirements section.

This is an easy fix, so I'm just documenting it here.

Many facilities still invoke setNextDest( facInst() ).

The Source Facility is an example where the function is as it should be written: setNextDest( dynamic_cast<Communicator*>( parent() ).

This is an artifact of an incomplete switch from strict RIF to parent/child. This will also assist in the storage facility change as stated in #24.

I have been using a number of tools and implementations to create a once-through fuel cycle that could be implemented in the core to make future scenario formulations easier. I am trying to keep this list as general/abstract as possible. I will also try to explain motivations behind these suggestions.

This will be an evolving list.

• Provide additional Agent 'mix-ins' to define specific behavior (e.g. our current Communicator class)
  • builder (defines behavior for building concrete agents from prototypes)
  • consumer (defines behavior for being a consumer of a commodity, allows for class supported connectivity between a prototype, a commodity, its production capacity, and its production price)
  • producer (same as above, but for producers)
  • motivation: for each region I implement, I have found that I need to implement an corresponding institution because I need to pass mutual information from my region to whatever institutions exist.

I think we should pull all of our concrete modules out of the core. Not only would this allow us to start understanding what it will be like for 3rd party module developers, but also unclutter our Doxygen documentation.

If/when we get documentation for a separate bundle of concrete modules, we might want to consider how we can segregate the Doxygen for the Tests from those of the class itself (if necessary?).

@gidden @katyhuff @rwcarlsen

Tasks:

• https://github.com/cyclus/core/issues/189
• https://github.com/cyclus/core/issues/80
• https://github.com/cyclus/core/issues/190
• https://github.com/cyclus/core/issues/191
• https://github.com/cyclus/core/issues/192 (a.k.a. #9)

Next Action : Issue #9

next action: add a set of MPManagers to the BuildInst class with the option of using them if the corresponding xml input is provided

The desired behavior of this facility is to offer all of its "barrels" of material to the market, each in its own offer. Assume that it can offer the entirety of it's own resource buffer.

Parent: https://github.com/cyclus/core/issues/160 (#19)
Blocked by: https://github.com/cyclus/core/issues/159 (#20)
Blocking: https://github.com/cyclus/core/issues/162 (#17)

next action: write the initialization functionality

This requires several tasks:

1. add generic resource table to cyclus core (done)
2. Modify/hack a cyclus branch to run code-configured simulations (done)
3. Create code-configurable models
   • source (done)
   • sink (done)
   • null (done)
   • market (done)
4. create post processing script to look at results (in progress).
5. sketch out scenarios
   • include a facility build constraint propogation scenario
6. analyze results

Blocked by : #14

as described in https://github.com/cyclus/core/issues/278

Next action: add the mixin, registering its parent as its manager

Issue https://github.com/cyclus/core/issues/200 (a.k.a. #8 ) outlines some possible strategies. The simplest to implement would be strategy 1.

Next action: Test a simulation with a build and growth region where the growth region holds reactors and the build region holds supporting facilities.

Blocked by: #20

As the BatchReactor currently stands (in my fork), it has the following resource buffers:

• pre-core
• in-core
• wet-storage
• dry-storage
• post-core

Pre/Post cores are utility buffers to describe what materials are ready to be used or sent away.

We wish to test the process of fuel moving from the reactor into wet/dry storage and out of the system. We can describe the system with the following parameters:

• cycletime = 1
• lifetime = 2 * cycletime
• wet residency > cycletime
• dry residency > wet residency

This describes the following situation:

At each state change, the inventory levels should be confirmed. This integration test will require a source and sink facility... Maybe we should discuss strategies this at our working meeting.