Giter Club home page Giter Club logo

master-thesis's People

Contributors

anshchaube avatar jbae11 avatar zoerichter avatar

Watchers

 avatar  avatar

master-thesis's Issues

Zoe Apply Writing Checklist

Hi @ZoeRichter. Although we're lucky to have undergrads working to ensure the clarity of your writing, it is also the responsibility of the author to write and iterate on drafts in accordance with the writing checklist. Please take a pass through all of the checklist items before submitting your final version to @munkm and I. Don't forget the other resources available to you at https://arfc.github.io/manual/guides/writing/ and https://arfc.github.io/manual/guides/writing/ms-thesis .

General

  • Run a spell checker.
  • The Oxford comma must appear in lists ("lions, tigers, and bears.")
  • Do not use the word "where" unless referring to a location (try "such that" or "in which").
  • Do not use the word "when" unless referring to a time (try "if" instead).
  • Only use "large" when referring to size.
  • Use of "very" suggests that a cooler word exists.
  • Other misused/overused words include: code, input, output, different, value, amount, model.
  • Articles such as "a" "the" "some" "any" and "each" must 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
  • expand all acronyms on first use (rely on the acros.tex file and glossaries package to automate this)
  • get rid of unnecessary prepositional phrases -- author clearing throat (It can be shown that)
  • #13
  • 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.
  • Always use isotopic notation like $^{239}Pu$. Never $Pu-239$ or plutonium-239.
  • Elemental symbols (Ni, Li, Na, Pu) are capitalized, but their names are not (nickel, lithium, sodium, plutonium).
  • A phrase of the form ion of is probably clearer as ion. (For example, convert "calculation of velocity" to "velocity calculation".)
  • Cite all images, methods, software, and empirical data. Review the principles and try CiteAs if necessary.
  • Refer to software consistently by name.
  • Each sentence/paragraph should logically follow the previous sentence/paragraph.
  • Be concise and direct.
  • When giving examples, use variables instead of numbers and use symbolic math instead of acronyms.
  • When you introduce words or phrases that are unusual or likely to be unfamiliar to the reader, italicize them.
  • If you use an uncommon word, either consider changing it or define it in its first usage.
  • You're a human writing for other humans: Make the wording exciting, and remember some people reading it won't know as much jargon as you do.
  • Vary your sentence structure to keep readers engaged.

Additional Table and Figure Checklist:

  • The text should refer to all tables and figures.
  • When referring to figures by their number, use Figure 1 and Table 1. They should be capitalized and not abbreviated (not fig. 1 or figure 1.)
  • In tables, align all columns of numbers such that the decimals line up.
  • In a single column, all values should probably have the same number of significant digits.
  • Give units for each numerical column.
  • A table should have only 3 horizontal lines (no vertical lines and no more than 3.)

Additional Math Comments:

  • define all variables, with units. If unitless, indicate that this is the case $[-]$.
  • subscripts should be brief and can be avoided with common notation. For example, $\dot{m}$ is better than $m_f$ which is superior to $m_{flow}$.
  • variable names should be symbols rather than words m is better than mass and \ksi is better than one_time_use_variable.
  • The notation $3.0\times10^12$ is preferred over $3e12$.
  • Equations should be part of a sentence.
  • Equations should be in the align environment. Align them at the = sign.
  • Variables should be defined in the align environment as well, not buried in paragraphs.

Here’s an example of an equation:

The line is defined as
\begin{align}
y&=mx + b
\intertext{where}
y&= \mbox{ height of the line, also known as rise [m]}\nonumber\\
m&= \mbox{ slope [-]}\nonumber\\
x&=\mbox{ independent parameter, known as run [m]}\nonumber\\
b&= \mbox{ y intercept [m].}
\end{align}

Second Draft Review

I have completed the first round of edits (thank you Nathan) and have pushed the updated report pdf, here.

Also, @munkm

I believe I have completed all the sections, though I do still need a snazzy title.

Introduction Review

Hi Nathan, could you review the Intro chapter? it's a shorter one this time. updated main pdf here

Thanks for all your help!

Also, @munkm

Results Review

Hi Nathan, could you review the results chapter for me? I'll include the pdf here. The figures definitely need formatting adjustment, so if you have any suggestions, feel free to include those when you look over the text!

I also think it could stand to be a bit longer, so if there's anything you think I should expand on/isn't clear, definitely let me know. The sensitivity test section in particular is a bit brief - there are probably things I took for granted and didn't include that aren't as clear to the person that didn't run them.

Thanks so much for all your help, and have a happy weekend!

Licensing Update

Everything is automatically licensed under creative commons, but it might be useful to have a CC-By-4.0. If I'm remembering correctly, this is what we ended up using for Andre's Thesis and it complied with the school's guidelines. I had to make it a .txt file to upload it here. Just something to consider, depending on how you generated the figures, you might have to explore other types of license but from what I can tell that's not the case.
CC-BY-4.0.txt

Answer key questions in literature review

  • What is the status of equilibrium composition analysis in pebble bed reactors, particularly HTGRs, but with some consideration of FHRs (previous depletion studies with VSOP/etc. for X-Energy and PBMR designs, FHR designs, etc.)
  • How successful were those approaches?
  • What is the status of micro-HTGR designs and where does yours fit (establish that the literature doesn't have one that does what yours does... or that the ones that exist aren't far enough along or are not quite superior in some way)?
  • Have folks evaluated the importance (with respect to uncertainty in flux and reactor physics) of the random packing of differently burnt up pebbles (I know PBMR and PB-FHR project both have worked on this challenge in the context of licensing mobile multi-pass pebble fuel). So, review past (NGNP) approach to this and establish that there was a need to determine the uncertainty/variation in power profiles/ reactor physics for this design.
  • Anything to say about the state of the state of the art of determining how much shielding is required for a device. Perhaps this is related to graphite lifetimes as a function of allowable dose/damage/dpa.

Lit Review and Methods Second Review

I've got the next draft of the method and lit review chapters completed and ready for review. Figures should all be at an appropriate size and location. I also redid some of the figures in methods, they are all to scale now!

pdf is here. If the other chapters get feedback and get finished up tomorrow, any changes I make wouldn't be to methods/lit review, so even an "updated" pdf should be fine to review.

Also, @munkm

Methods Review.

Hi Nataly, could you review the methods chapter?
Check that:

  • the chapter follows the writing checklist
  • everything is clear.

@npanczyk
main.pdf

You can ignore everything else. Thank you!

Revision #4 from me

Here is my review of the most recent draft. I suspect it is possible that a few comments of mine from the last draft should be carried over, so I didn't repeat them. Once a new draft is posted, this issue can be closed.

Lit Review...review.

Hi Nathan! Could you review the lit review chapter for me? (chapter 2). I know the one figure isn't fitting well with the rest of the chapter, but I'm going to wait until the text is more finalized so I know what I have to work with.

Just checking the writing checklist should be enough. Beyond that, I think I've got my sections organized alright, but if you have a suggestion of a better order, I'm all ears :).

Thanks again!

main.pdf

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.