jbae11 / 2016-bae-borehole-ihlrwm Goto Github PK

(hopefully) last things:

• reorganize case definition and proposed / base case
• add GC859 data to Zotero
• discuss historic west and east repository background
• Change to Exelon buying the land
• Quantify the cost of non-consenting locals ( cost to persuade for Yucca)
• Quantify state responsibility with MW /capita nationally, state level and community level
• cease of dry cask campaign -> expedited installment / operation
• local consent / bounding minimum time saved -> due to the handling facility + transportation already there
• Preexisting local talent (ETWDD ANS) - > Education Training Work Development ( Also Smaller Salary)
• change picture of the Canadian National Railroad

create one

Make a long list, including lots of benefits and drawbacks of the proposed repository design from the perspective of the various stakeholders.

• fed gov
• state gov
• local
• utility
• environmentalists
• others

This may seem pedantic, but I noticed some uncommon practices in your repository and I wanted to address them.

It is common practice to avoid committing anything except for source files. In the case of latex, that includes bib, tex, sty, and cls files, along with a few others. It doesn't include aux, ist, bbl, blg, acn, glo, or pdf files. Those latter types of files are derivatives of the source files. If you version control them, you're not hurting anything. However, it will cause "merge conflicts" that are annoying to deal with and unnecessary.

So, to avoid this, we typically never execute the command: git add *. The appropriate way to add new files is one at a time. And, then, when you're ready to commit, execute git commit -am "my commit message for committing all new changes to any tracked files." To avoid accidentally committing unintened derivative files, we often add a .gitignore file to the repository, which will help git to ignore any files it definitely shouldn't be tracking. A common gitignore file for latex repositories is here:https://github.com/github/gitignore/blob/master/TeX.gitignore .

I have made a pull request which should fix both of these issues. (adds more to the gitignore file and stops tracking files which shouldn't be tracked).

However, there is one remaining cleanup issue. What is the temp folder for? With git, you should never need such a thing. Let's talk about best practices to avoid that kind of thing in these repositories.

In order to have enough information to appropriately arrive at value for your metrics for each key benefit criterion you'll need to further define the cases (both base, proposed midwest, and proposed west).

Consider

• specific location
• actual licensed area of the "suggested" facility boundaries
• nearby spent fuel burden
• etc.

Hi @jbae11 : Where are you planning to version control your talk for the conferences? I see a few good options.

1. Putting the presentation related to this work in the same repository as the paper is one good way to keep things organized. If you prefer, one option is to create orphan branches for presentations.
2. OR, if you'd prefer to put the presentation in its own repository, perhaps you put it in a new repository like : arfc/yyyy-mm-borehole
3. I tend to put each of my presentations in the gh-pages branch of their own repositories with the naming convention yyyy-mm-dd-place. But, the main reason for that is because my presentations are usually html websites, so that they are each sub-directories of my personal website. Since yours is latex, that may not be the right solution for you.

Thoughts?

I do think the appropriate thing to do is officially cite the Independent Student Research Group (was that the title?) book project. Please add it to zotero? You'll need to add it manually . Let me know if there are any questions.

• Need more details for the 'wikipedia' citation.
• Similarly, the US Census is divided into various data products which can be individually cited. Can you look here and determine which of these was used for the paper: http://www.census.gov/population/www/cen2010/glance/ (or other details if not listed)

I'm looking over the paper and some of the citations aren't working, so I went to update the bibfile by exporting from zotero. However, it turned out the most recent few additions to the zotero directory don't have any metadata.

The issue is probably this: The appropriate time to click the browser plugin button is no when you are viewing the PDF for whatever you want to include in Zotero. Instead, back up one step (typically) to the google scholar page or the elsevier abstract view or the IAEA archive list. That's when you want to click the button. If you click it when you are at the pdf url, it will just save the pdf with no metadata.

Like so (the last few don't have any metadata, they are just a pdf.)

Hi Teddy, Quick question. How would you folks feel about developing the full paper version of this in the open (i.e. making the repository 'public') , now that the abstract has been submitted?

We can add an attribution license and everything, so that you will be legally protected from someone stealing your ideas. Also, you would still be the gatekeeper for any new additions. No one could add anything unless you grant them permission. But, it's absolutely up to you. Thoughts? Questions?

For the record, I just see the benefit of this being a contribution toward a general trend of transparency in science. I would love for the policy of the group to be "transparent unless there's a reason not to be". However, this is a very personal philosophical stand and I'm sensitive to the desire to maintain ownership over one's academic work until publication.

Let me know what you think. If you like the idea, I can help by adding a license that protects your ownership in various ways (CC-BY is my favorite for this kind of work).

I have marked up the pdf. Good start. We can make these changes as well as re-evaluate the paper according to the outline suggested by Prof. Singer.

bae_abstract.pdf

We can close this issue when the grammatical issues have been addressed.

milestones

• be explicit about the metric
• statement saying the metric is homemade
• main tex for them all
• figure out bibliography
• abstract: motivation / results/ my contributions
• ntroduction: rest to understand the paper
• methodology: how to reproduce my results - equations and all
• results and discussion: everything learned
• citation: where i got the data (the data was scraped from public information)
• explain why the weights are they way they are.
• skilled worker existence
• cost of treatment licenses.

For some set of very important benefit criterion, identify how you would measure the extent of the benefit (e.g. # jobs, # miles, # years in interim storage).

Consider the way that Passerini approached valuation functions and criteria: here

@katyhuff

I read over the paper, and I was wondering if we can discuss some issues!

• The third case, I feel like can cause confusion, maybe only discuss it in the beginning but not have it as one of the cases?
• In the 'Expediency' section, there's a citation 'doe_snf_plan?' that I'm not sure what you're referencing to.
• For the expediency section, wouldn't the Case 1 save 5 years..? and would it be too much to express that in terms of dollars?
• What do you think about concluding with a 'weighted calculation' of the metrics? I think it'd be a bit too much but I feel like the paper sort of ends abruptly.

Again, Thank you greatly.

Hi! @katyhuff

Before I leave for break, I'd like to have a meeting with you ( Friday?)

regarding this paper and future directions!

Do you have time tomorrow?

Thanks!

So I have, after some gruelling hours, finished

parsing, collecting, scraping, dusting, etc the data from the Curie map.

So I successfully made a exact replica of the Curie map on qgis.

However, I feel like there is a better way to find the value for the kg*km question,

so I was wondering what your go-to method would be.

I'm planning to test two scenarios:
1.
'test' the 10 commercial reactors in SAFSTOR

and find the smallest kg*km (assuming we have one central repository).

divide the US into two on some criteria, then

apply the same method to find the two regional sites with smalled kg*km.

What do you think?
oh, and all the data, I stored on
github.com/jbae11/data
let me know what you think!

thanks

There seem to be two bibliography files and the main one is breaking the build. One seems to be designated temporary (bibliography.bib~). That should likely be deleted as it seems to have fewer bibliography entries.

The other, ideally an export from the zotero directory, does not match what I see in my zotero directory in the arfc group. The entries are incorrectly formatted and missing a lot of metadata for the following items:

IAEA_2008
NRC_Clinton
Riddel_2003
Loomis_2012
Ewing_2009
EPRI_1990
Perry_2015
McDonald_2012

How were they added to zotero? It seems they are missing metadata, so maybe they were added manually? If you use the browser plugin, slightly more information should be available. Is there something that has changed about the workflow?