How NOT To Write Your Final Year Project Report

The following guidelines are for the undergraduate students who conduct their final year projects with me.

1. Do not write in a free-style manner.

Scientific writings and technical reports have a very specific style and format. Adhering to the format is easier. Just be sure you are well-acquainted with the required format as instructed and comply.

A harder part is following a certain style of scientific writing. You can get the feeling from the textbooks, journal papers, and other technical writings you read for your project so you can follow the style therein.

2. Do not partially adhere to the format.

You must instead thoroughly commit the format for every paragraph, word, letter, font, punctuation, spacing, margin. I.e., Every. Single.Thing.

3. Do not mix up mathematical symbols.

The letter “x” is NOT multiplication symbol. In Microsoft Word, use insert “Symbol” for any mathematical symbols. Equations must be written with the equation editor.

4. Avoid using “we”.

While it is a matter of taste, the current practice at USM is to not use “we” in a thesis or report by a single person. “I” is highly discouraged, though I do not mind if I am your examiner.

5. Do not leave orphan figures, tables, or any other objects.

Orphan figures are those that appear in your report but are never mentioned or explained in the text body. ALL figures and tables must have labels (as numbers) and captions.

Figures are captioned at the bottom, while tables at the top.

ALL figures must be mentioned and explained in respective paragraphs.

6. Do not place figures or tables immediately after a topic or sub-topic.

There must always be opening paragraph about the topic or subtopic before you mention about your figures.

7. Do not use color plots unless necessary.

Color plots may be good in presentations but not in reports. Everything in your plots must convey meaning, and it can be done with (black) line types and marker symbols. Colors for cosmetic purpose are not allowed for my students.

Result and Discussion

8. Do not screen-capture figures.

Your figures must look CLEAN and PROFESSIONAL. Any modeling software packages have the menu or command with flexible settings for you to save or export the figures. Use it.

9. Do not use any background color in figures other than white.

The default background in most modeling packages like Ansys, Abaqus, etc. is optimized for screen viewing, but NOT for printing. Find how to revert the settings in your specific software program so you can export the figure in white background.

10. Do not add plot title.

The caption for the plot already describes it. The title is redundant.

Citation and References

11. Do not be slack in referencing. 

Everything in your report that does not originate from you must be completely referenced. It is better to over-reference a source than to under-reference. Absent of proper referencing will lead to plagiarism. And you will fail if you get to this point.

For further reading:

12. Do not cite from Wikipedia.

While Wikipedia today is quite reliable, as a matter of practice in academic and scientific writing, you must refer to original sources. The list of references in a Wikipedia entry is what you should go after.

13. Do not mix up citation and bibliography style.

Every entry in the list of references (bibliography) must follow the SAME format for every word, letter, punctuation, space, etc. Follow every single element. DO NOT rely on automatic formatting by programs like EndNote.

Grammar and Style

14. Do not use emotion-related or vague terms in describing your results.

Avoid words like “wonderful” (Yes, I’ve seen this in reports), “amazing”, “perfect”, (add your own words) when describing your data or findings.

15. Do not rely on your thinking only for correct spelling and grammar.

Before submission, run the spell checker thoroughly. Then run the grammar checker at least once.

For further reading:


Quick Start on TORQUE’s qsub

TORQUE is a queue manager on most parallel computing environment.  The idea of running a usually large computing job is to:

Log on the server. Send job. Log out.

A simple example to submit a job to TORQUE:

1. Create a text file (a script) that contains the executable file to run. Here my program is hellow. Name the file e.g. myjob.pbs

The content of my myjob.pbs script only consists of 2 lines:



2.  Then submit the job like this:

$ qsub -o myjob.out myjob.pbs

3.  You can now log out and wait for your job to complete.

4.  Once the job finishes, whatever screen output in a normal run will be redirected to myjob.out instead.

5.  While waiting for your job, you can check the status of your job with the command:

$ qstat

6.  To cancel a job

$ qdel <your job id>

where <your job id> is as appears in qstat.

The above myjob.pbs is the minimum you must have. We can now add more options in the script. All options must appear at the top just below #!/bin/sh:

To select the specific node to run:

#PBS -l nodes=<node_name>

E.g., if the node name is compute1, then: nodes=compute1

For more about job submission with TORQUE, refer

CMake Tips for Beginners

A few tips when working with CMake:

  1.  Always create a build directory separate from the source directory.
  2. To refresh the directory, i.e., to remove all output files from CMake (like in “make clean” ot “make dist” when using Makefile), simply remove all files in build: $ rm -fr build/*. The restart with “$ cmake” again.
  3. A few of help commands:
    1. file(GLOB SRC *.cpp): gathers all .cpp files in the current directory and store the names in SRC. But some say GLOB is evil, so use with care
    2. include_directories(<path to directory>): a must when compiling in Fortran
  4. When using command target_link_libraries(myLib1 myLib2), the sequence of lib names may be important. Here myLib1 depends on myLib2, so myLib1 must appear first. This is weird. To check on this.