A few nifty tips for conducting scientific research

The purpose of scientific research is to create new knowledge. This is not an easy task. Years of learning and training from grade schools to grad schools are needed to grasp a wide range of knowledge that mankind has accumulated about the universe, from basics in fundamental fields like math and physics to the state of the art in the particular field that the researcher has chosen. A typical flow chart of a scientific research project is illustrated in Figure 1. The whole process can be divided into four stages: coming up with a research idea and forming a plan, developing and testing methods, collecting and processing data to obtain results, and analyzing and interpreting the results for publication. Notice that the flows are often bidirectional. Some steps require many rounds of back-and-forth trials. Also, many research plans might not work out and need to be revised or abandoned.

Figure  1.  A typical flow chart of a scientific research project. Different colors represent different stages of the project.

DownLoad: Full-Size Img PowerPoint

Among all the stages, the first stage of research idea and plan is the most difficult one. Vidale (2025) listed five general rules for good research ideas which I totally agree with and strongly recommend for interested readers. For this discourse I will skip the first stage and focus on some of the details of method development and data processing.

Here is a list of tips for conducting research that I have been following (or trying to follow) during my 30+ years of seismological research.

1) Write small programs. This is from the Unix philosophy of “small is better” and “do one thing and do it well”. I was fortunate to be introduced to the Unix operating system in early 1990s and was immediately attracted to its simplicity and, at the same time, power. Each Unix command seems to do only one trivial thing, yet different Unix commands can be connected through piping to accomplish complicated tasks. The advantages of small programs are obvious. They are relatively easy to create, debug, maintain, and improve. However, identifying which tasks to be implemented in small programs is not easy, especially for beginners. A general rule of thumb is that if you anticipate that a chunk of program might be used in other occasions or you are copying and pasting it from another program, you should make it as a subroutine or a standalone program.

2) Re-use existing programs. A main benefit of writing small programs is that they can be used by other programs. For this purpose, the program should be written for a general task with well-defined inputs and outputs. Re-using existing programs greatly reduces program development time and effort. It also provides valuable opportunities for testing and improving the existing programs in various situations.

3) Avoid duplication. Duplication increases the cost of program maintenance and often causes confusion down the line. Instead of creating a new program by copying an existing program and making a few changes for a different scenario, one should modify the existing program by adding an option for the new case.

4) Divide and conquer. The whole data processing stage from the raw data to final results is generally very complicated. I have seen many monolithic programs trying to get the job done in one piece, including plotting the results. This makes the program unnecessarily long and complicated therefore difficult to debug and to maintain. It also makes the program less flexible to be re-used and to satisfy different requirements of the user. Such monolithic programs obviously violate Rule #1 and #2 above. A better practice is to break the whole procedure into smaller parts and solve each part sequentially (Figure 2): the intermediate result from the previous part is used as the input to the next part. This allows each part to be developed and tested independently.

Figure  2.  The whole procedure from data to results should be broken into smaller parts (e.g., Proc1) and solved sequentially, with the intermediate result (e.g., Intm1) from the previous part serving as the input to the next part.

DownLoad: Full-Size Img PowerPoint

5) Record and document the work. One requirement for scientific research is that the results should be reproducible, given the same input data, processing procedures, and associated parameters. This means that all the procedures and parameters need be recorded, along with the dependent relationships among different procedures. Unix provides a nice tool called Makefile for this purpose. For example, the whole procedure in Figure 2 can be recorded in a Makefile as:

###############################################

# This Makefile does ...

# Author: ...

# Revision History:

# 　　...

# Notes:

###############################################

...

#### default parameters ####

area = ...

filter = ...

...

#### user defined parameters ####

include para.mk

#### Step 1 ...

Intm1: Data

commands to process data to produce Intm1

using the parameters.

#### Step 2 ...

Intm2: Intm1

...

...

#### Final step ...

Results: IntmN

...

Makefile uses the time stamps of the target (e.g. Intm1) and prerequisite (e.g. Data) to decide if the target needs to be updated. So, be careful not to alter the time stamps of files unintentionally. Comments should be added in Makefile to document the thoughts, revision history, and explanations of key components. The same is true for all your computer programs and scripts. You will be thankful for the documentation later when you need to track a bug in your programs or to modify them for improvement.

6) Test with synthetic data. A great way to test a new program or procedure is to use an input for which the output is known. For forward problems, models with analytic solutions or calibration with other verified methods can be used. For inverse problems, it is often done by generating synthetic “data” using a “true” model, provided that the forward calculation is available. Noise-free synthetic data are good for verify the correctness of the program. Random noise can also be added to the synthetic data to test the robustness of the method.

7) Visualize the data and results. A picture is worth a thousand words. Since most of us are visual learners, plotting the data and results in different perspectives helps us to gain insight about them and to identify anomalies or problems in them. Figures are also the most effective way to present the data and results to others. Figures need to be objective but also aesthetic. It usually takes time and multiple trials to find the right aspect ratio, exaggeration, color, etc. to make a satisfactory figure. Like all other research products, figures should be reproducible. The parameters and steps for making the figure should be recorded and documented. This requirement rules out most interactive tools for making figures. I prefer using the Unix-style Generic Mapping Tools (GMT) for its versatility and producing high-quality figures (Wessel and Smith, 1991).

8) Backup your work. This should be done regularly and every time before upgrading your computer. I like to use MacOS’s Time Machine App as it allows rolling back in time in case a modified program does not work.

I hope these advices will be helpful to young scientists in their endeavor of research.

Resources

The link to the video presentation which this Perspective is based on can be found at https://www.koushare.com/live/details/35565.