Main Page


Purpose of this page


I have many times witnessed starting PhD students/researchers to use a significant amount of time for doing relatively simple everyday tasks because they don't know the correct tools and practices to automate the process. A prime example is reference management, which, when done well, can be (almost) automated. The purpose of this page is to collect links to useful tools, practices, and advice for practical matters to help to do science more effectively. The purpose of this page is not to teach how to do good science nor how to be a good PhD student.

Since this page represents a personal viewpoint to the matter, I've included some brain imaging specific links to data and software, which are useful knowledge for students in my group. I'll try to keep this very concise so it can be skimmed through quickly maybe adding later more pages to explain something more in detail. 

Finally, these pages are under construction and likely to so for quite a while...


Writing papers


If it is not published, it does not exist. 

How to write a paper


When I googled 'How to write a scientific paper?', I got about 2 billion hits. These are mostly good (and concise) hints and you should read few of them. I'll provide links to some specific resources:

How to write and publish a scientific paper is a classic book that is recommended. An article by G.D. Gopen and J.A. Swan is also recommended. A number of other links concerning technical writing in English can be found here

Mathematical writing is requires its own guidelines. A good and concise set of rules can be found in a report of a course by D.E. Knuth (from 1987). The document is 118 pages long, but do not worry, the basic rules are presented in the 6 first ones.

Brain imaging researchers should consult also Guidelines for reporting an fMRI study and Ten simple rules for reporting voxel-based morphometry studies. These (mostly) target neuroscientists, but are useful also for method developers.


With what to write a paper


I strongly recommend LaTeX for technical writing of longer documents because of the ease of writing mathematics, reference management and backward-forward compatibility. Most scientific publishers accept papers written in LaTeX and provide LaTeX styles for manuscript preparation. WYSIWYG word-processors (such as Word) are better in writing of shorter documents such as letters and when you need absolute control of the final appearance (with no ready-made style file available). If you (against my advice) decide to go with Word, learn to use it effectively. The rest of the section deals with LaTeX.

LaTeX is a document preparation system not a word-processor. So to start with you'll need 1) a LaTeX distribution and 2) a LaTeX editor. I am using a combination of MikTeX and TexMaker on Windows with which I have been very happy, but if you like to see what other editors have to offer see comparison of TeX editors. Especially, LyX might be appealing to persons that miss the WYSIWYG word-processors. A good LaTeX reference is in wikibooks.org. Many more LaTeX tutorials are available in the web, just google them! 

My only advice on using LaTeX is: use \ref and \label, use BibTeX for building reference lists, and if something seems horribly inconvenient, there's probably better way to do it.

Reference management

The rule is: Don't build the bibliography section of your paper manually, but let a bibliography management software to do this for you. There is a list of reference managers in Wikipedia. The important point is to minimize your own efforts and the time spent on reference management. The next paragraph demonstrates what features you should expect from the software. 

I am using a combination of BibTeX (that reads the \cite{} commands in LaTeX document and builds a reference list according to those) and JabRef (that I use to maintain my  database of BibTex records). BibTeX can adapt to a specific bibliography style and there are hundreds of them available in the web. The only commands required are

\bibliographystyle{elsarticle-harv}

\bibliography{ownbib}  

embedded into the LaTeX source and to run bibtex (after running latex/pdflatex).  The first one defines the bibliography style and the second one the database to use. These have to be in correct directories (guidelines for MikTeX). The rerunning of latex then produces document with the reference list in the correct format. The workings of BibTeX are explained here.  There's also BibTeX for Word

I use JabRef for managing the bibliographic databases. I like it because of the convenient way to fetch bibliographic entries directly from several databases including PubMed and IEEE Xplore freeing me from all sorts of copy-pasting.  

Finally, there is the issue of defining keys for bibliographic entries of  the publications. It is extremely good practice to select a good method defining the keys. I like keys starting with the name of the first author and ending with the publication year, e.g., Tohka2004. One can any method when it is consistent (i.e. all the entries are keyed in the same way), it is easy to decode the paper being cited based on the key, and this is supported in your reference manager (to automate everything). Note there is a difference between Tohka04 and Tohka2004 and it is important to stick with only one style.   



Reading papers


It is important to develop techniques for reading scientific papers as well. However, googling 'How to read a scientific paper?' results in far fewer hits than the query 'How to write a scientific paper?' above. This link provides a good summary worth to take a look at. Also, it is good to keep a record what you have read and make notes. RSS-feeds are a useful tool for keeping track of recent literature. The citation databases such as Pubmed and Google scholar are essential when searching literature.     


Reproducibility


The reproducibility is a cornerstone of the experimental research. However, here I do not aim to go philosophical, but claim that doing everything in a way that is easily reproducible offers substancial practical advantages. Think about, for example, preparing a figure for a paper. Then, a reviewer comments on that figure and requires a minor change to it. Unless the figure has been prepared with the reproducibility aspect in mind, this can take considerable amount of time. Note that reproducibility is more than replicability. It is not sufficient to be able to exactly replicate the results, figures, etc., but to allow also changes.

In my field, the reproducibility usually means that you should have a piece of code that you can edit for everything. This documents exactly what has been done to produce the results and you can easily change some aspects of the work. The same goes for preparing figures. The only exception to this are the software packages that are easier to operate using a GUI and produce detailed logs to show what has been done. 

It is a good practice to name you scripts/functions/programs with long enough and descriptive names, so you can locate them later on. In addition,study a style-guide of your favourite programming language and develop your own coding style and learn what version control means. This just makes things much easier in a long run. A good slide-set of scientific programming basics is here and educational material can be found here.   
           

Open Data (Brain imaging)



FBRIN data (several datasets)

LONI-IDA (ADNI, ICBM)



Open Software (Brain imaging)


Neuroimaging tools and resources clearinghouse - probably the most complete listing of the neuroimaging tools and resources 










PMTK3  - This is the only link not related to brain imaging; a very useful collection of machine learning Matlab functions.