Arrows

[FlanFlanagan]

Cycic needs a method of determining which way material is flowing.

[katyhuff]

I don't think this is possible with the information the input schema currently allows. Is it reasonable to just have non-directional facility-to-market linkages?

[FlanFlanagan]

That is the way it is setup now. I'm comfortable with it, however I think it will depend on how the sponsor feels about the GUI at the meeting in September.

[katyhuff]

righto.

[scopatz]

OK, I was under the impression that markets had offers and requests but on further investigation it seems that only the Converter market has that. Unfortunately, this is one of those features that is on Erich's must have list. So what I propose is that the UI present offer's and requests. If the underlying market model does not follow this convention then that all attached resources get dumped into whatever bucket it does have.

[scopatz]

Yeah, I guess that we can ignore it for now entirely too ;)

[katyhuff]

The information about whether a facility will make offers or requests are sortof private to the facility as it is. We could attempt to constrain them by changing the input rng a little differently than is suggested in the new cyclus issue https://github.com/cyclus/core/issues/323 .

The current situation is this :

<!-- begin section for facilities -->
  <define name="facility">
    <element name="facility">

      <element name="name">
        <text/>
      </element>

      <element name="model">
      <choice>
        <!-- insert ref to new FacilityModels here -->
      </choice>
      </element>

    </element>
  </define>

The 323 suggestion is this :

<!-- begin section for facilities -->
  <define name="facility">
    <element name="facility">

      <element name="name">
        <text/>
      </element>

      <zeroOrMore>
        <element name="commodity">
          <text/>
        </element>
      </zeroOrMore>

      <zeroOrMore>
        <ref name="recipe">
      </zeroOrMore>

      <element name="model">
      <choice>
        <!-- insert ref to new FacilityModels here -->
      </choice>
      </element>

    </element>
  </define>

The more constraining solution that would give some notion of direction would be :

<!-- begin section for facilities -->
  <define name="facility">
    <element name="facility">

      <element name="name">
        <text/>
      </element>

      <zeroOrMore>
        <element name="incommodity">
          <text/>
        </element>
      </zeroOrMore>

      <zeroOrMore>
        <element name="outcommodity">
          <text/>
        </element>
      </zeroOrMore>

      <zeroOrMore>
        <ref name="recipe">
      </zeroOrMore>

      <element name="model">
      <choice>
        <!-- insert ref to new FacilityModels here -->
      </choice>
      </element>

    </element>
  </define>

If we implement the latter, you'd be able to draw arrows for facilities that comply, but not all facilities will necessarily comply. You may also want to include some level of flexibility in the long run for facilities interested in both buying and selling on the same commodity market (sound crazy? sure, it's unlikely a facility would need to do this... until you think about retail...)

[scopatz]

We've been thinking a bit about bidirectional facility/market interactions. (In fact, one facility which exchanges bidirectionally with a single market is the trivial case of a closed fuel cycle ~_~.) Naturally, we do not expect all facilities to comply (zeroOrMore implies this) so we would of course fall back to mere associated connections.

Personally, I prefer the terminology of requests and offers. It feels more transactional. Either way though.

After some thought, I agree that the way you wrote out the last option is probably the most concise and requires the fewest levels of nesting.

[katyhuff]

Personally, I prefer the terminology of requests and offers. It feels more transactional. Either way though.

The requests and offers terminology is already in use in the code. Though closely related, commodities are subtly different from requests/offers. A commodity is just a part of a request or offer. A request/offer includes a commodity data member, but also includes an amount, a price, and a resource. A resource may be a specific instance of a commodity, maybe a material (commodity:waste) or an engineer (commodity:worker) or a kiloWatt (commodity:electricity).

Going with incommodity and outcommodity avoids any conflict/ambiguity between the requests and offers vocabulary in the code and in the input. In any case, a pull request with incommodity and outcommodity has already been made.

Of course, we could use requestcommodity=incommodity and offercommodity=outcommodity if that works better. I'll change it if you'd rather see requestcommodity etc.

[scopatz]

I see, I see. I don't like incommodity and outcommodity is that they imply a binary relationship that isn't necessarily there as well as implying there may be some economic value to these resource flows. Of course I am thinking of Enrichment or Milling here. While it is technically correct to think of Tails as out commodities, they are really just accidental, physically necessary byproducts. So maybe it is that "commodity" connotes "product" which is rubbing me the wrong way.

If we wanted to use the appropriate economic legal terms we would label them "calls" and "puts", or perhaps "callresources" and "putresources" [1]. This would be distinct terminology from "requests" and "offers". I would be happy with "requestcommodites" and "offercommodities" or "requestresources" and "offerresources" though too.

Sorry! I feel as if I have just dumped my entire thought process here ;). I am basically +1 for anything that doesn't use in/out, +0 for anything that doesn't use "commodity", and +0.25-0.75 for call/put if you think that other people could handle it.

http://en.wikipedia.org/wiki/Option_(law)

[katyhuff]

We chose commodity very intentionally, and while it's not set in stone, it is kindof a longstanding notion within the code and is common terminology in much of our previous published literature on cyclus. Let's address your concerns though.

I don't like incommodity and outcommodity is that they imply a binary relationship that isn't necessarily there

There is, actually, a binary relationship. The simplest possible explanation of markets is this : A market is defined by a commodity (sometimes a few commodities) for which it receives offers and requests. For more info on how markets actually work: http://cyclus.github.com/devdoc/make-models/market.html .

as well as implying there may be some economic value to these resource flows.

The word commodity does not necessarily imply economy (see the first few sentences of the wikipedia article on commodities http://en.wikipedia.org/wiki/Commodity). Also, our treatment of commodities fits very well with the definition on Wikipedia. With the simple explanation above it should be clear that the thing we're calling a commodity should be something for which there are offers and requests (supply and demand) and for which the logistics of trade is dealt with on a market. No economics need be involved. In cyclus we treat commodities in just this way. A facility is free to send offers and requests to the same market, and those offers and requests don't necessarily have a nonzero price. In fact, most offers and requests are currently priced at zero, and all of our current markets are non-economic, not matching by price whatsoever.

If we wanted to use the appropriate economic legal terms we would label them "calls" and "puts", or perhaps "callresources" and "putresources" [1].

If you're annoyed by the implicit presence of economy in the nomenclature, this suggestion seems counterproductive to that concern as it seems much more closely related to prices. In any case, I appreciate that these may be more appropriately specific legal jargon, but these terms "calls" and "puts," are fairly esoteric. We'd like the code to be easily understood by ordinary humans. Uncommon jargon might obfuscate our interface. Paul Dirac once said, " In science one tries to tell people, in such a way as to be understood by everyone, something that no one ever knew before. But in the case of poetry, it's the exact opposite! "

I would be happy with "requestcommodites" and "offercommodities" or "requestresources" and "offerresources" though too.

After all those concerns, you're fine with requestcommodities ? Incommodities and outcommodities do the same thing with fewer letters and fewer changes to the input schema... but, we live to please. Requestcommodities it is.

[gonuke]

Having read all of this, I'm not sure I understand why "requestcommodities" is better than/different from "incommodities"? Can someone summarize just this difference in 2 sentences or less?

[katyhuff]

That's going to have to be @scopatz .

They're interchangeable to me, though incommodity is shorter than requestcommodity, so I prefer it slightly.

[rwcarlsen]

I also prefer incommod because of brevity. I would also like to point out that requestresources would be bad - because resources are a very different think than commodities.

On Tue, Aug 14, 2012 at 10:17 AM, Katy Huff notifications@github.comwrote:

That's going to have to be @scopatz https://github.com/scopatz .

They're interchangeable to me, though incommodity is shorter than requestcommodity, so I prefer it slightly.

— Reply to this email directly or view it on GitHubhttps://github.com/cyclus/cycic/issues/17#issuecomment-7729136.

[scopatz]

I am going to respond to @gonuke, then @katyhuff, then end with a proposal.

@gonuke, "requestcommodities" is better than/different from "incommodities" because it is more suggestive of possible commodity exchanges rather than enforced flows. Because the requests/offers keywords are already taken, we append commodity.

[scopatz]

@katyhuff

I don't like incommodity and outcommodity is that they imply a binary relationship that isn't necessarily there

There is, actually, a binary relationship. The simplest possible explanation of markets is this : A market is defined by a commodity (sometimes a few commodities) for which it receives offers and requests. For more info on how markets actually work: http://cyclus.github.com/devdoc/make-models/market.html .

It might help here for me to be a little more specific. Obviously, the relationship between any single facility and any market is a binary operation. Call this a market-centric view. Taking a facility-centric view, the facilities themselves may accept many incommods and may return many outcommods. In this view, facilities are Nary operators. Sorry, my they pronoun dangled.

as well as implying there may be some economic value to these resource flows.

The word commodity does not necessarily imply economy (see the first few sentences of the wikipedia article on commodities http://en.wikipedia.org/wiki/Commodity).

My reasoning here is actually the same (apt) criticism that you levy against 'calls' and 'puts'. As I said originally, while commodity denotes any marketable item, it connotes economic ones. In making a user interface, as you point out, we need to be sensitive to what people will unconsciously associate with the terms we use.

Furthermore, we may be accidentally fusing the terms (E)conomic - items exchangeable, not necessarily monetary - with fuel cycle economics - items which contribute to the levelized cost of electricity.

So to rephrase my (minor) problem, the term commodity does not seem to fit in a facility-centric view for items in which there are no real functioning markets where such items may be exchanged. For example, depleted uranium. Or carbon dioxide in the atmosphere. DOE for DU or the UN for CO2 having been trying for a long time to figure out how to be market makers for these items so that they can be exchanged for other existing commodities.

I realize that this is an edge case and I may be overly concerned about it which is why I was only +0-ing it.

[scopatz]

After discussing this with Robert last night, since we are editing the facility schema and are in a facility centric view/namespace, why not just call these "inputs" and "outputs".

Simple, clean, plural, avoids other domain-specific terminology. If we weren't to go for this, I think would vote to elect @katyhuff as benevolent dictator here and let her do what she thinks is right!

[katyhuff]

inputs and outputs are too vague. These parameters actually refer to constructs in the code called commodities, so I think calling them incommodity and outcommodity is appropriate.

As per what I think is right, I did it yesterday before this conversation started. https://github.com/cyclus/core/pull/325 .

[scopatz]

Oops, one addendum. Could we make these plural, ie "incommodities" and "outcommodities"? There is only one case where they are singular...

[katyhuff]

Ah, good suggestion, but I'll have to push back on that too. (sorry! I'm not trying to be contrary.)

The way rng works, we define the entry as zeroOrMore incommodity objects.The incommodity ref itself defines just one incommodity. See the code example above, look at the cyclus.rng.in file, or see the example below :

      <zeroOrMore>
        <ref name="incommodity">
          <text/>
        </element>
      </zeroOrMore>

      <define name="incommodity">
          <element name="incommodity">
              <text/>
          </element>
      </define>

This results in xml that looks like :

      <facility>
        <model>StubFacility</model>
        <name>myName</name>
        <incommodity>freshMOX</incommodity>
        <incommodity>freshPWRFuel</incommodity>
        <outcommodity>spentMOX</outcommodity>
        <outcommodity>spentPWRFuel</outcommodity>
        <outcommodity>electricity</outcommodity>
      </facility>

It wouldn't make sense to have code that looked like:

      <facility>
        <model>StubFacility</model>
        <name>myName</name>
        <incommodities>freshMOX</incommodities>
        <incommodities>freshPWRFuel</incommodities>
        <outcommodities>spentMOX</outcommodities>
        <outcommodities>spentPWRFuel</outcommodities>
        <outcommodities>electricity</outcommodities>
      </facility>

I know you're saying to yourself, "why don't we say incommodities is a list of commodities?" like this:

        <incommodities>freshMOX,freshPWRFuel</incommodities>

Unfortunately, that misses the point of the rng schema a bit. To have the entry contain a list reduces the scope of input checking on that element.

[scopatz]

Ahh gotcha. So I think that we could do something that used more natural language with another level of nesting, but why bother. 'Flat is better than nested' anyway. Your way stands.

@FlanFlanagan , this means more work on your side ;). We can talk about what this means but basically you'll have to write a mapping from element names to UI labels. ie

var labels = {'incommodity': 'Input Commodities'}

Unless @katyhuff know of a way of a non-intrusive way of adding label info or other metadata to the rng schemas. Not a big deal though. We can always make it @FlanFlanagan's problem.

[katyhuff]

I'll have to think about a non-intrusive way. There probably is a way using attributes.

[katyhuff]

probably annotations... http://relaxng.org/tutorial-20011203.html#IDA1OZR

[katyhuff]

Your in/outcommodities elements have officially been pulled into the cyclus/cyclus repo.

We haven't currenlty changed any of the input simulations to use it though... it's a little peripheral to their functionality at the moment...

But you can add these things to input all you like.

[scopatz]

Thanks @katyhuff!