[version] bump version to 0.2.0

README.rst

@@ -61,6 +61,10 @@ Or conda::
 
 Extra packages will be required to enable the GPU mode. For the MPI mode, it's suggested to directly compile from the source. For more details about the Installation, you can refer to the Installing part of the document.
 
+Todo
+------------------
+The current bugs to fix or features to provide are listed in `TODO <https://github.com/ziyixi/pyfk/issues/5>`__.
+
 License
 -------
 

docs/introduction/tutorial.rst

@@ -61,7 +61,7 @@ Based on the ``SourceModel`` and ``SeisModel``, we can now initialize the ``Conf
             receiver_distance=np.arange(10, 40, 10))
     print(config_prem)
 
-For this example, we are using the ``model_prem`` and ``source_prem`` defined previously. And our output should be 512 points with 0.1 s interval. The receiver distances are 10km, 20km, and 30km. If you are planning to use degrees instead, simply set ``degrees=True``, and the ``receiver_distance`` will be automatically converted to the corresponding distance in km. The default values are set to be the same as ``FK``. One thing to note is that ``model_prem``, ``source_prem`` are deep copied into ``config_prem``, so you can reuse it in the future without wondering influencing ``config_prem``.
+For this example, we are using the ``model_prem`` and ``source_prem`` defined previously. And our output should be 512 points with 0.1 s interval. The receiver distances are 10km, 20km, and 30km. If you are planning to use degrees instead, simply set ``degrees=True``, and the ``receiver_distance`` will be automatically converted to the corresponding distance in km. The default values are set to be the same as ``FK``. One thing to note is that ``model_prem``, is deep copied into ``config_prem``, so you can reuse it in the future without wondering influencing ``config_prem``. However, ``source_prem`` is shared with ``config_prem``.
 
 Calculate Green's function
 ---------------------------

docs/parallel/parallel.rst

@@ -54,10 +54,14 @@ There might have a problem that the GPU memory is not big enough. It's possible
 
 The bottleneck of the GPU calculation is the data moving. Currently, there is no better way to solve this problem; using thread is not the way to go as the actual calculation on GPU is pretty fast. So it's not surprising if you look at the system monitor, and the GPU efficiency is only 0%, although we know it's running on GPU and it's fast. Look at the GPU memory usage, and you will get that we are using GPU.
 
+Usage tips
+^^^^^^^^^^^^^^^^
 There is also the possibility that the cluster has multiple GPUs installed, try to use ``nvidia-smi`` to find the free GPU that doesn't have much memory allocated, and at the start of your simulation script, put::
 
     from numba import cuda
     # select the second GPU for example (start from 0)
     cuda.select_device(1)
 
-It will use the second GPU instead of the first one.
+It will use the second GPU instead of the first one.
+
+Since PyFK uses numba to compile CUDA kernel with JIT, it also might be slower when running the code for the first time. Please be aware of that when performing the benchmark.

pyfk/__init__.py

@@ -12,4 +12,4 @@
     "generate_source_time_function",
     "mpi_info"]
 
-__version__ = "0.2.0-beta.6"
+__version__ = "0.2.0"