jbae11 / 2016-bae-borehole-ihlrwm Goto Github PK
View Code? Open in Web Editor NEW"Benefits of Siting a Borehole Repository at a Non-operating Nuclear Facility" Paper Collaboration
License: Other
"Benefits of Siting a Borehole Repository at a Non-operating Nuclear Facility" Paper Collaboration
License: Other
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
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?
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!
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.
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.)
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.
Hi @jbae11 : Where are you planning to version control your talk for the conferences? I see a few good options.
Thoughts?
create one
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
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).
Make a long list, including lots of benefits and drawbacks of the proposed repository design from the perspective of the various stakeholders.
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
I read over the paper, and I was wondering if we can discuss some issues!
Again, Thank you greatly.
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.
We can close this issue when the grammatical issues have been addressed.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.