Currently working for Deploy inst,

I'm looking for a smarter way to set dates.

Currently:
the csv file has dates in format mm/dd/yy

convert that to yyyymmdd, store as string.

this is the function to get build_times and life_times for cyclus input:

def convert_dates(init_date, start_date, end_date):
    """This function converts the date format and saves it in variables.

        All dates are in format - yyyymmdd

    Prameters
    ---------
    init_date: int
        start date of simulation
    start_date: int
        start date of reactor - first criticality.
    end_date: int
        end date of reactor - null if not listed or unknown

    Returns
    -------
    entry_time: int
        timestep of the prototype to enter
    lifetime: int
        timestep of the duration of the prototype

    """

    init_year = init_date // 10000
    init_month = (init_date // 100) % 100

    start_year = start_date // 10000
    start_month = (start_date // 100) % 100
    
    dyear = start_year-init_year
    dmonth = start_month - init_month
    if dmonth<0:
        dyear -= 1
        start_month += 12
    dmonth = start_month - init_month

    entry_time = 12 * dyear + dmonth

    if end_date != null:
        end_year = end_date // 10000
        end_month = (end_date // 100) % 100
        dyear = end_year - start_year
        dmonth = end_month - start_month
        if dmonth<0:
            dyear -= 1
            start_month += 12
        dmonth = end_month - start_month

        lifetime = 12 * dyear + dmonth
    
    return entry_time, lifetime
    

I'm not quite sure this is appropriate, but I have initialized

the repository with the input file generator with Jinja2.

I will pull request from now on, sorry.
:(

The write_reactors.py is getting too big,

and there are repetitive functions that can be called.

Make that change so it's compressed.

Refactor the eg01-eg24 transition scenario that does not use d3ploy capabilities to match the new scenario details similar to #93

cd cyclus
git fetch upstream 
git checkout v1.4.0-release
<may have to at this point follow git instructions which will tell you to type git checkout -b v1.4.0-release >

then

cd ../cycamore
git fetch upstream 
git checkout v1.4.0-release
<may have to at this point follow git instructions which will tell you to type git checkout -b v1.4.0-release >

then rebuild everything, open cyclist, and see if the archetypes have magically appeared (probably not, but at least you'll be on the newest release).

This issue can be closed when @gwenchee has successfully run united_states.ipynb in her own cyclus environment and confirmed the results. The total spent fuel amount and possibly the major isotopes in the spent fuel should be compared to CURIE (unf-ST&DARDS) data (e.g. the 2020 spent fuel isotopic calculation.

All scripts in the scripts folder need to be reviewed and to be refactored for clarity.

This issue can be closed when all scripts have been refactored to to use meaningful variable names and to avoid python keywords when choosing variable names (many words, including list and type, are verboten)

All scripts in the scripts folder need to be reviewed and to be refactored for clarity.

This issue cannot be started until #58 has been completed.

This issue can be closed when all scripts have been refactored to have unit tests for at least 80% of the functions.

All scripts in the scripts folder need to be reviewed and to be refactored for clarity.

This issue cannot be started until #61 has been completed.

This issue can be closed when all this repository uses a continuous integration system (e.g. travis) which runs all of the unit tests.

Create an archetype that is capable of representing a continuously refuelled reactor. This issue really belongs in cyclus/recycle but that repository doesn't seem ready yet, so I'm putting it here. This issue can be closed when such an archetype exists in cyclus/recycle or elsewhere.

(It was suggested by @jbae11 that this issue should have a deadline of 3/1)

Demonstrate, using Cyclus and Cycamore, the transition between EG01 and EG29.

EG01 - The current U.S. fuel cycle plus disposal of the spent nuclear fuel in a repository.
EG29 ­- Continuous recycle of U/Pu with new natural U fuel in both fast and thermal critical reactors.

As a base case, make sure it can be done once again with the current version of Cyclus & Cycamore. If the bright-lite implementation can be conducted as well, that would be great.

This should build on the effort in #13 and #26. Information about the EG29 evaluation group can be found here:

https://fuelcycleevaluation.inl.gov

Create or update the current Cycamore Separations archetype so that it can separate isotopes using aqueous separation methods such as PUREX.

@katyhuff
when I use genfromtxt or loadtxt ( and I think I have tried almost all imaginable dtype),

I keep getting the character b in front of the string output.

like this

currently the type is S128.

I was looking around google, but couldn't quite find a clear solution to this.
Can you help me please?

I'm submitting a ...

• bug fix
• feature addition

Expected Behavior

Build checks and tests all pass
Circle-CI does build checks on PRs in this repo

Actual Behavior

Build is failing on the master branch, per Circle-CI, due to PR #115 being merged.
Build checks are not tested on PRs in this repo

How can this issue be closed?

The build checks and tests pass, build checks are automatically done on PRs

The synergistic paper is looking good. Next step is to make sure all of the scripts and data in transition-scenarios are completely up-to-date with the plots and simulations in the paper. Once those PRs are merged (#65 & #64 ) and reproduce the paper plots exactly, we can make a zenodo DOI for the repo and cite it in the paper.

running the following input file,

the simulation does not 'use' MOX, despite the presence of

separations and fuelfab plant.

To replicate:

1. copy and paste the input file to filename
$cyclus -o reprocess.sqlite [filename]

2. Open sqlite file

3. SELECT * FROM transactions WHERE commodity = "mox"
   or
   SELECT * FROM transactions WHERE senderid = 24
   where 24 is agentid of fuelfab

Results show

Querry OK
Row(s) returned: 0

Any ideas?

Demonstrate, using Cyclus and Cycamore, the transition between EG01 and EG30.

EG01 - The current U.S. fuel cycle plus disposal of the spent nuclear fuel in a repository.
EG30 ­- Continuous recycle of U/TRU with new natural U fuel in both fast and thermal critical reactors.

As a base case, make sure it can be done once again with the current version of Cyclus & Cycamore. If the bright-lite implementation can be conducted as well, that would be great.

This should build on the effort in #13, #26, and #32. Information about the EG30 evaluation group can be found here:

https://fuelcycleevaluation.inl.gov

It seems like

the table agentstate_cycamore_reactorinfo

does not show decommissioned reactors.

The following query outputs blank:

SELECT power_cap, entertime
FROM agentexit INNER JOIN
agentstate_cycamore_reactorinfo
ON agententry.agnetid = agentstate_cycamore_reactorinfo.agentid

I also tried using other tables, but the 'agentstate_cycamore_reactorinfo`

is the only table with the column power_cap.

It also looks like Anthony's eg-01-23 file also has the same issue,

but I think he is okay since all the reactors have capacity 1000 MWe

The mishandled conflicts in 5066347 can't remain. I'm hesitant to do the cold revert just that commit because the end state would still be un-reviewed code. To return the repository to the state pre-push-to-master requires someone to individually revert that commit as well as all commits in PR #34 . There are too many changes in the combined set for me to comfortably parse without context and I'm concerned I don't understand @JBA11's order of operations well enough to understand what was done to create the problem. Please fix this malformed repository history before moving forward with anything else.

Refactor the eg01-eg29 transition scenario that does not use d3ploy capabilities to match the new scenario details similar to #94

Refer to #20

The input file renders successfully ( I think,)

but when run on cyclus,
/transition-scenarios/input$ python write_reactors.py ./europe/eu_reactors_pris.csv reactor_template.xml.in deployinst_template.xml.in input_template.xml.in reactors_crude.xml regions_crude.xml

gives this error message:

cyclus complete_input.xml 
              :                                                               
          .CL:CC CC             _Q     _Q  _Q_Q    _Q    _Q              _Q   
        CC;CCCCCCCC:C;         /_\)   /_\)/_/\\)  /_\)  /_\)            /_\)  
        CCCCCCCCCCCCCl       __O|/O___O|/O_OO|/O__O|/O__O|/O____________O|/O__
     CCCCCCf     iCCCLCC     /////////////////////////////////////////////////
     iCCCt  ;;;;;.  CCCC                                                      
    CCCC  ;;;;;;;;;. CClL.                          c                         
   CCCC ,;;       ;;: CCCC  ;                   : CCCCi                       
    CCC ;;         ;;  CC   ;;:                CCC`   `C;                     
  lCCC ;;              CCCC  ;;;:             :CC .;;. C;   ;    :   ;  :;;   
  CCCC ;.              CCCC    ;;;,           CC ;    ; Ci  ;    :   ;  :  ;  
   iCC :;               CC       ;;;,        ;C ;       CC  ;    :   ; .      
  CCCi ;;               CCC        ;;;.      .C ;       tf  ;    :   ;  ;.    
  CCC  ;;               CCC          ;;;;;;; fC :       lC  ;    :   ;    ;:  
   iCf ;;               CC         :;;:      tC ;       CC  ;    :   ;     ;  
  fCCC :;              LCCf      ;;;:         LC :.  ,: C   ;    ;   ; ;   ;  
  CCCC  ;;             CCCC    ;;;:           CCi `;;` CC.  ;;;; :;.;.  ; ,;  
    CCl ;;             CC    ;;;;              CCC    CCL                     
   tCCC  ;;        ;; CCCL  ;;;                  tCCCCC.                      
    CCCC  ;;     :;; CCCCf  ;                     ,L                          
     lCCC   ;;;;;;  CCCL                                                      
     CCCCCC  :;;  fCCCCC                                                      
      . CCCC     CCCC .                                                       
       .CCCCCCCCCCCCCi                                                        
          iCCCCCLCf                                                           
           .  C. ,                                                            
              :                                                               
Entity: line 5048: element DeployInst: Relax-NG validity error : Expecting an element n_build, got nothing
Entity: line 5070: element n_bulid: Relax-NG validity error : Invalid sequence in interleave
Entity: line 5070: element n_bulid: Relax-NG validity error : Element DeployInst failed to validate content
Entity: line 5102: element DeployInst: Relax-NG validity error : Expecting an element n_build, got nothing
Entity: line 5252: element n_bulid: Relax-NG validity error : Invalid sequence in interleave
Entity: line 5252: element n_bulid: Relax-NG validity error : Element DeployInst failed to validate content
Entity: line 5101: element config: Relax-NG validity error : Element config failed to validate content
Entity: line 5099: element institution: Relax-NG validity error : Invalid sequence in interleave
Relax-NG validity error : Extra element region in interleave
Entity: line 5096: element region: Relax-NG validity error : Element simulation failed to validate content
 ERROR(core  ):Document failed schema validation

It doesn't seem like it is an indentation issue, though that should also be addressed.

Switching the order between prototype and n_build doesn't seem to do the trick, either.

Do you have any suggestions?

Some base cases to set up, run, (in cyclist), export the xml, and upload it to this directory.

• Source -> Sink
• Many Sources -> Many Sinks
• Source -> Reactor -> Sink
• Many Sources -> Reactor -> Many Sinks
• Many Sources -> Many Reactors -> Many Sinks

I am so pleased that you mastered jinja templates @jbae11 ! However, I have many style suggestions that may help your general python programming fu. I know most of them are not errors you introduced! However, I will make a PR with style suggestions that I generally hope to see in python code. I hope you will look them over.

They cover:

• line lengths: See PEP8. Lines should not be super long. Consider making your text editor handle this.
• tabs: I generally recommend no tabs. Only spaces. PEP8 agrees. Again, this is something your text editor can handle for you.
• templates, by convention, end in ".in". So, template.xml should be template.xml.in
• output files should only be versioned once they are input for something else. (this is a squirmy rule. What I mean is: If you can create a file based entirely on scripts existing in the repository, you probably shouldn't version control it until it is a stage of input for something else.)
• unused imported packages

#pro-tip : you can run pylint to see some of these things. There are also linters that one can install in their text editor.

huff@lise:~/repos/transition-scenarios/input(style) $ pylint write_reactors.py
No config file found, using default configuration
************* Module write_reactors
C: 10, 0: Trailing whitespace (trailing-whitespace)
C: 14, 0: Exactly one space required after comma
with open(sys.argv[2],'r') as fp:
                     ^ (bad-whitespace)
C: 20, 0: Exactly one space required after comma
                              dtype=('S128','float64','float64'),
                                           ^ (bad-whitespace)
C: 20, 0: Exactly one space required after comma
                              dtype=('S128','float64','float64'),
                                                     ^ (bad-whitespace)
C: 21, 0: Exactly one space required after comma
                              names=('reactor_name','n_assem_core','n_assem_batch'))
                                                   ^ (bad-whitespace)
C: 21, 0: Exactly one space required after comma
                              names=('reactor_name','n_assem_core','n_assem_batch'))
                                                                  ^ (bad-whitespace)
C: 30, 0: Line too long (103/100) (line-too-long)
C: 31, 0: Exactly one space required around assignment
output=open('written_input_file.xml','a')
      ^ (bad-whitespace)
C: 31, 0: Exactly one space required after comma
output=open('written_input_file.xml','a')
                                    ^ (bad-whitespace)
C: 36, 0: Line too long (150/100) (line-too-long)
C: 38, 0: Trailing newlines (trailing-newlines)
C:  1, 0: Missing module docstring (missing-docstring)
C: 15, 4: Invalid constant name "input_template" (invalid-name)
C: 16, 4: Invalid constant name "template" (invalid-name)
C: 18, 0: Invalid constant name "reactor_lists" (invalid-name)
C: 31, 0: Invalid constant name "output" (invalid-name)
W:  2, 0: Unused import mimetypes (unused-import)
W:  4, 0: Unused import os (unused-import)
W:  5, 0: Unused import smtplib (unused-import)
W:  7, 0: Unused import getpass (unused-import)
C:  2, 0: standard import "import mimetypes" comes before "import jinja2" (wrong-import-order)
C:  4, 0: standard import "import os" comes before "import jinja2" (wrong-import-order)
C:  5, 0: standard import "import smtplib" comes before "import jinja2" (wrong-import-order)
C:  6, 0: standard import "import sys" comes before "import jinja2" (wrong-import-order)
C:  7, 0: standard import "import getpass" comes before "import jinja2" (wrong-import-order)

Refactor the eg01-eg23 transition scenario that does not use d3ploy capabilities to match the new scenario details similar to #92

@katyhuff

As the write_reactors.py is getting bigger, I think it should be considered to maybe
internalize the templates and region_head/tail files?
There's currently 5 arguments for the function, which seems a bit excessive.
(along with two files, region_head.xml, region_tail.xml).

They'd just be declared as a string variable, jinja rendered, and output files
would be the only ones in the function argument.

I feel like this would help with the modularity and possibly documentation
of this code, and I'd like your input on it!

thanks

All scripts in the scripts folder need to be reviewed and to be refactored for clarity.

This issue can be closed when all scripts have been refactored to have smaller functions, specifically, functions small enough to unit test.

This project would benefit from having a library of spent fuel recipes

generated from depletion codes like serpent.

The obtained recipe should be averaged throughout the core.

@lkissin2 has been working partially on this for benchmarked SFRs.

The analysis.py script fails to fully run on the EG01-EG23-cycamore output.
If the analysis script is not meant for this output, please close or ignore this issue.

/home/user/anaconda3/envs/python2/lib/python2.7/site-packages/matplotlib/axes/_axes.py:545: UserWarning: No labelled objects found. Use label='...' kwarg on individual plots. warnings.warn("No labelled objects found. "

Demonstrate, using Cyclus, the transition between EG01 and EG23.

EG01 - The current U.S. fuel cycle plus disposal of the spent nuclear fuel in a repository.
EG23 - Continuous recycle of U/Pu with new natural-U fuel in fast critical reactors

This scenario has been done before (Djokic et al., 2015). The work was completed both with the Cycamore Reactor model and then additionally with Bright-lite as the reactor model. As a base case, please make sure it can be done once again with the current version of Cyclus & Cycamore. If the bright-lite implementation can be repeated as well, that would be great.

Resources for that work can be found in the following locations:

• 5061- final.pdf Zotero > ARFC > Fuel Cycle > Cyclus
• https://github.com/scopatz/fco-ta
• https://github.com/bright-dev/Bright-lite
• https://fuelcycleevaluation.inl.gov

Problem:

The deployment schedule of transition scenarios are currently heavily dependent
on the output recipe of Cycamore::Reactor. (How many LWRs are needed to start FRs, etc.)

A model fuel recipe for the transition scenarios are needed:

Note the only difference between 23/24 and 29/30 is the MOX PWR.

The input fuel and output fuel recipes have to be semi-compatible with the mixer facility.
i.e.)
The reprocessed Pu or TRU from spent fuel, and its mixture with dep U should
resemble the input fuel recipe closely. In short:
(Reprocessed Pu or TRU recipe)(ratio) + (dep U)(1-ratio) ~= input recipe

Solution:

Various solutions are available, some better than others

Weak:

use vision recipe and modify to fit need

Better:

Produce own recipe using depletion codes

Best:

Use Bright-lite, which would be better in the longer run to
demonstrate cyclus capabilities.

All scripts in the scripts folder need to be reviewed and to be refactored for clarity.

This issue can be closed when all scripts have been refactored to avoid hard-coding variables without leaving any trace of the source or meaning of the data. No bare numbers, please. Filenames and paths that must be stored may need to be hardcoded, but should be organized and well-named.

Demonstrate, using Cyclus and Cycamore, the transition between EG01 and EG24.

EG01 - The current U.S. fuel cycle plus disposal of the spent nuclear fuel in a repository.
EG24 ­- Continuous recycle of U/TRU with new natural­ U fuel in fast critical reactors

As a base case, make sure it can be done once again with the current version of Cyclus & Cycamore. If the bright-lite implementation can be repeated as well, that would be great.

This should build on the effort in #13 . Information about the EG24 evaluation group can be found here:

• https://fuelcycleevaluation.inl.gov

The version of this repository which created the accepted ANS summary needs to be directly citable. Best practice for this is to create a zenodo or figshare DOI which can be cited in that document. @jbae11 , you or I should do this, but it will rely on the answers to the following questions:

• is the current revision sufficient to recreate the results in the ans summary?
• are there pending pull requests related to the ans paper?
• do recent changes to the repository change the results or the plots such that they don't match those in the ans summary?

This issue can be closed once a figshare or zenodo doi exists and is cited in the ans summary.

The scripts should be able to have a large room of flexibility for the user to choose
the countries (regions) involved in reprocessing.

Current:

reprocessing can be turned on and off,

but is only for French PWRs (MOX plants)

But the reprocessing plant receives waste from all reactors.

Goal:

User would be able to choose which country (region)

can 'participate' in reprocessing, whether backend or frontend.

example)

# these countries will have mox reactors
backend_list = [France, Belgium]
# theses countries will send spent uox to reprocessing plant
frontend_list = [France, Belgium, Netherlands, Spain]

Alternative

modify csv file to specify backend and frontend participation ( 1 for 'yes' and 0 for 'no')
-> not recommended cause 'manually' altering database?

Figure out, with the help of cyclus-dev and cyclus-users, what's up with cyclist's failure to discover local archetypes.

Develop Analysis Capability for important fuel metrics such as:

1. u_util_factor

Uranium Utilization ( Ratio of Heavy Metal Mass Burned to Total Uranium Mass used for Fuel)
In other words,
natural uranium from source divided by total mass of fuel burned in all reactors

The correct natural uranium quantity can be calculated (currently)
only by back calculating from enrichment output of enriched material.

2. Uranium Disposal

Amount of Uranium (isotopic) in Sink or stockpiled in reprocessing plants.

The output should either have total Uranium mass (Sum of all isotopes of U)

or separate quantity for individual isotope.

Generally, the functions should be made to fit all output files

i.e. use spec column than prototype column, consider all possible fuel cycles

For the eg01-eg30 transition scenario using d3ploy (with @robfairh's recent "sharing" feature as implemented in the "mixerbug2" branch), only fr reactors are being deployed. This is true with or without using the sharing/percentage feature, and the fr and moxlwr reactors have equal preference values. Power supply and demand is being maintained successfully around 60,000 throughout the transition. Input file attached.

eg01-eg30-flatpower-d3ploy2.xml.zip

Higher fidelity models like Cyborg and Bright-lite can be used for transition scenarios.

Since the purpose of this project is to identify gaps in the cycamore library, this should not be considered a major goal, but useful.

This issue kicks off activities toward a comparison activity between thorium and uranium fuel cycles to be conducted by @jbae11 (now @ZoeRichter ???) . To serve this activity, this literature review should:

• be reflected (by adding reviewed papers to a folder) in the group zotero
• identify all similar work in this area, summarize the methods and conclusions.
• be recorded in a document resembling the literature review chapter of an MS thesis
• identify common metrics used to evaluate the sustainability of a fuel cycle or similar system
• determine the promise of these metrics for evaluating a dynamic rather than static scenario (that is, some static metrics may not make sense in a dynamic scenario and vice versa)
• identify the technologies to compare in these transition scenarios
• identify appropriate reactor specifications for representing the technologies to be compared

(it was proposed by @jbae11 that this issue should have a deadline of 12/20)

regarding #24

Apart from the decrease from reactor shutdown ( Issue #22 ),

the created chart seems to lack some capacity (~ 23 GWe)

Upon searching, the following is found:

1. for 2016, the used csv file (for input generation)
   has a higher capacity

2. the country Switzerland, should not be here (so lower capacity :/)
   Other than that, all the EU countries are considered in the csv file.

3. The country lithuania had two power plants (RBMK),
   that is currently shutdown.
   -> This still does not satisfy the goal ( still need ~20 GWe more)

Do you have any guesses as to what might be the problem?
my three main questions are these:

1. missing countries?
2. missing reactors?
3. there's something wrong with the online graph?

The input generator will automatically place each country's respective reactor in the region.

Desired output:
section of input with all the reactors names in each respective regions.

Issue regarding matplotlib figure rendering in Ipython notebook.

The legends are too big.

currently: legend size is decreased and is to the upper-left hand corner (loc=2)

Goal:
Find ways to load (either plt.show() or plt.savefig() then show)
the figures in Maximized size, so the legends do not cover the actual plot.

Problem:
'backend' maximization methods seems to be different for Ipython notebook
and just running the script from terminal (QT backend).
i.e)
Having

figManager = plt.get_current_fig_manager()

figManager.window.showMaximized()

successfully maximized figure and saves, but would error on the ipython notebook,
with the following error:

---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-5-0b9eb5d48c48> in <module>()
      8     cur = con.cursor()
      9     print(an.snf(output, cur))
---> 10     an.plot_power(output, cur)
     11     print('Completed! You may go to the next box')

/home/dkadkf/Desktop/poopeepoop/module_branch/transition-scenarios/scripts/analysis.py in plot_power(filename, cursor)
    244     stacked_bar_chart(power_dict, timestep,
    245                       'Time', 'net_capacity',
--> 246                       'Net Capacity vs Time', 'power_plot.png')
    247     plt.figure()
    248     stacked_bar_chart(num_dict, timestep,

/home/dkadkf/Desktop/poopeepoop/module_branch/transition-scenarios/scripts/analysis.py in stacked_bar_chart(dictionary, timestep, xlabel, ylabel, title, outputname)
    195     plt.grid(True)
    196     figManager = plt.get_current_fig_manager()
--> 197     figManager.window.showMaximized()
    198     plt.savefig(outputname, format='png')
    199 

AttributeError: 'FigureManagerBase' object has no attribute 'window'

It has been discussed in ARFC group meeting (04/18/2018) that the arfc/predicting-the-past should be integrated to this repository for a more centralized maintenance of Cyclus fuel cycle scenarios.

This issue can be closed when the files and git history of arfc/predicting-the-past have been merged into this repository.

With all other conditions constant,

it takes a lot LESS TIME for the simulation WITH REPROCESSING

which is counter-intuitive.

It also seems like the output is more clumped together for the reprocessing case

in table resources , but it is all separate for each assembly in the non-reprocessing case.

The input files used is here.

Refactor the eg01-eg30 transition scenario that does not use d3ploy capabilities to match the new scenario details similar to #95

Convince yourself that you can see the results of the runs (#3) in Cyclist.