Git Product home page Git Product logo

ddca_numerical_exp's Introduction

ddca_numerical_exp

Numerical Experiment for CYCLUS Demand-Driven Deployment

The repository is part of an effort to add demand-driven deployment capabilities into the CYCLUS framework. PI: Kathryn Huff

Assume the algorithm is an INSTITUTION.

GIVEN:

all prototype definitions and parameters
    - reprocessing capacity of one facility
    - reprocessing efficiency
    - reactor specifications
    - enrichment capacity / tails assay
    - spent / fresh fuel compositions

Non-optimizing

  • If it `predicts' the fuel demand correctly ( given the past, )
  • Does all the reactors run? (timeseriespower =! 0 if not in refueling)
  • Does it deploy facilities when it sees we need more capacity?
  • Does it track demand?

Deterministic-Optimizing

  • Are the constraints met?
  • The objective function is maximized?
  • Same result every time?

Commodity Flow

Power / Advanced Reactor Deployment -> mox_fuel (fuel for advanced reactors) -> spent fuel (Pu / Fissile) -> Reprocessing Capacity -> uox -> uox fabrication capacity -> uox enrichment capacity -> natural u

Example Objective Function

2% nuclear electricity generation annually, starting from x P = x*(1.02)^(t/12)

ddca_numerical_exp's People

Contributors

gwenchee avatar jbae11 avatar katyhuff avatar nsryan2 avatar pep8speaks avatar robfairh avatar

Stargazers

 avatar

Watchers

 avatar

ddca_numerical_exp's Issues

Draft 1 comments

numerical_exp_report.pdf

This issue can be closed when the comments in the above attached review have been merged into the repository. Please excuse the handwriting (was missing my stylus).

Writing Checklist

A checklist exists for writing properly...
http://arfc.github.io/manual/guides/writing/checklist/

This issue can be closed when the following items have been checked in the DDCA July 2019 report.

  • Run a spell checker.
  • The Oxford comma appears in ("lions, tigers, and bears.")
  • Do not use the word "where" unless referring to a location (try "such that" or "in which").
  • Articles such as "a" "the" "some" "any" and "each" appear where necessary.
  • All subjects match the plurality of their verbs ( no: "Apples is tasty" yes: "Apples are tasty")
  • Avoid run-on sentences.
  • clunky nouns -> spunky verbs (progression, expression --> progress, express)
  • reduce vague words (important, methodologic)
  • reduce acronyms / jargon
  • get rid of unnecessary prepositional phrases -- author clearing throat (It can be shown that)
  • get rid of extraneous adverbs (very, really, quite, basically, generally)
  • get rid of there are / there is
  • turn negatives to positives (she was not often right -> she was usually wrong)
  • get rid of extraneous prepositions (the meeting happened on monday -> the meeting happened monday) (they agreed that it was true -> they agreed it was true)
  • get rid of passive voice (is/was/are/were/be/been/am + past tense verb), replace with active voice
  • use strong verbs (use sparingly: is, are, was, were, be, been, am)
  • avoid turning verbs into nouns ("obtain estimates of" -> "estimates"; "provides a description of" -> "describes")
  • don't bury the verb (keep the predicate close to the subject at the beginning of the sentence)
  • data is plural (the data are critical)
  • compare to (point out similarities between different things) vs. compared with (point out differences between similar things)
  • punctuation helps you to vary your sentence structure
  • Power to separate in increasing power: comma, colon, dash, parentheses, semicolon, period
  • In increasing order of formality: dash, parentheses, all of the others. Don't overdo it with the dash and parentheses
  • semicolon: connects two independent clauses. OR used to separate when the items in the list contain internal punctuation.
  • use a colon to introduce a list, quote, explanation, conclusion, or amplification
  • if there's a list in a sentence, it shouldn't come before the colon
  • use a dash to insert something in the middle of the sentence. Don't overuse it.

Add a Coversheet to the Report

This issue can be closed by merging a PR that adds the coversheet to the July 2019 report.
There is a template for the ARFC report coversheet here .

Leave the report number as a draft report number for now.

What's the deal with the directory called "final"?

There is both a directory called "final" and one called "final-report."

(Neither, in fact, is the project's final report, which is distinct from the report satifying the final milestone and has not yet been written.)

I have made a PR that changes the name of "final-report" to uiuc-arfc-2019-05.

But -- I can't figure out the purpose or proper fate of the directory called "final". This issue can be closed when someone:

  • explains what the deal is.
  • and/or a pull request is merged which changes the name of that directory or deletes it entirely.

Plots to illustrate demand function:

Currently the report lists initial demand and growth rate.
Since we want to move away from that nomenclature and want stepwise functions to define our demand,
plots should be included as well as the equations in the report to help the reader understand the test parameters.

Update of the report

The report should add the demonstrations of d3ploy capabilities using the transition scenarios.

Addressed by #25

The .pdf can we found here:
report.pdf

This issue can be closed when @robfairh updates the report.

Organizing test category

An 'intuitive' way of labeling the tests should be implemented.

Currently,

A - source only
B - source & reactor
subsequent letters reflect more sophisticated supply chains

1 - Test only deployment capability
2 - Test only decommissioning capability
3 - Test mixed capability.

However, the status quo presents a problem when moving forward, and is a bit confusing.

This issue can be closed once a better labeling is implemented.

Summer Transition Report

This issue can be closed after @sonatav2 and @robfairh read the summer transition report. In the report, I candidly added some comments and recommendations for setting up the large transition scenario. In the conclusions section, I made a recommendation for what @sonatav2 could work on while @robfairh is in Sweden taking the nuclear waste course. Feel free to reach out to me if y'all need any help :)

report.pdf

Also, could someone merge #22 if you are satisfied with the report.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.