Commit 2d544668 authored by Mijian Xu's avatar Mijian Xu 😷
Browse files

use obspy

parent f299bf2a
......@@ -2,8 +2,10 @@ bqmail
===========
Python scripts to request waveform data of events from IRIS
bqmail: send request mail of events data or continuous data to IRIS DMC.
bqmail: Send request mail of events data or custom data to IRIS DMC.
bqmail\_conti: Send request mail of continious data to IRIS DMC.
searchDMC: Search available stations in IRIS DMC.
uodateCatalog: Update CMT catalog automatic.
uodateCatalog: Update CMT catalog automaticly.
......@@ -9,6 +9,7 @@
# 2015/04/29
# 2015/05/01
# 2015/09/26
# 2015/11/06
#
def Usage():
......@@ -19,9 +20,11 @@ def Usage():
print('-Y -- Date range.')
print('-B -- Time before/after origal time of events in seconds.')
print('-C -- Channel (e.g., ?H?, HHZ, BH?). Default: BH?')
print('-P -- specify the lat/lon of station and require data by phase. e.g., 20/100/SKS')
print('-L -- Location identifier.')
print('-c -- Directory of date time file. formaat: "2015,01,04,1,0,0 2015,01,04,10,0,0"')
print('-c -- Directory of date time file. format: "2015,01,04,1,0,0 2015,01,04,10,0,0"')
print('-F -- File format (SEED or miniseed). Default: SEED')
print('-M -- Magnitude range.')
print('head.cfg -- Config file.')
print('Example: ./bqmail.py -NCB -SNJ2 -Y2015/2/3/2015/4/3 -B0/1000 head.cfg')
print(' ./bqmail.py -NIC -SBJT -Y2015/2/3/2015/4/3 -B-100/600 -L10 -Fminiseed head.cfg')
......@@ -31,7 +34,7 @@ import datetime
import os, re
import sys, getopt
import time
import taup
from obspy import taup
import distaz
try:
import configparser
......@@ -140,10 +143,12 @@ else:
if iscustom:
EVENT = open(datetimefile,'r')
for evenum in EVENT:
for evenum in EVENT.readlines():
evenum = evenum.strip('\n')
evenum_sp = re.split('\W|\s',evenum)
event.append(evenum_sp)
date_beg = datetime.datetime(int(evenum_sp[0]),int(evenum_sp[1]),int(evenum_sp[2]),int(evenum_sp[3]),int(evenum_sp[4]),int(evenum_sp[5]))
date_end = datetime.datetime(int(evenum_sp[6]),int(evenum_sp[7]),int(evenum_sp[8]),int(evenum_sp[9]),int(evenum_sp[10]),int(evenum_sp[11]))
event.append([date_beg.strftime('%Y %m %d %H %M %S'), date_end.strftime('%Y %m %d %H %M %S')])
else:
trange_sp = timerange.split('/')
btime = float(trange_sp[0])
......
......@@ -152,7 +152,7 @@ if isgmt:
center = [(max(netlats)+min(netlats))/2, (max(netlons)+min(netlons))/2]
gmt.write('#!/bin/sh\n')
gmt.write('ps=stations.ps\n\n')
gmt.write('gmt pscoast -Rg -JE%5.2f/%5.2f/5i -Ba30 -Dc -A10000 -Glightgray -Wthinnest -K > $ps\n' % (center[1], center[0]))
gmt.write('gmt pscoast -Rg -JN0/10i -Ba30 -Dc -A10000 -Glightgray -Wthinnest -K > $ps\n' % (center[1], center[0]))
gmt.write('gmt psxy -R -K -O -J -St0.03i -Gred3 -W0.3p >> $ps << eof\n')
for sta in stations:
gmt.write('%5.2f %5.2f\n' % (sta[3], sta[2]))
......
package obspy.taup
==================
Copyright
---------
GLPv3
Copyright (c) 2011-2015 by:
* The ObsPy Dev Team
Overview
--------
Travel time calculation tool for ObsPy.
ObsPy is an open-source project dedicated to provide a Python framework for
processing seismological data. It provides parsers for common file formats and
seismological signal processing routines which allow the manipulation of
seismological time series (see Beyreuther et al. 2010, Megies et al. 2011).
The goal of the ObsPy project is to facilitate rapid application development
for seismology.
For more information visit http://www.obspy.org.
# -*- coding: utf-8 -*-
"""
obspy.taup - Ray Theoretical Travel Times and Paths
===================================================
:copyright:
The ObsPy Development Team (devs@obspy.org)
:license:
GNU Lesser General Public License, Version 3
(http://www.gnu.org/copyleft/lesser.html)
This package started out as port of the Java TauP Toolkit by [Crotwell1999]_ so
please look there for more details about the algorithms used and further
information. It can be used to calculate theoretical arrival times for
arbitrary seismic phases in a 1D spherically symmetric background model.
Furthermore it can output ray paths for all phases and derive pierce points of
rays with model discontinuities.
Basic Usage
-----------
Let's start by initializing a :class:`~obspy.taup.tau.TauPyModel` instance.
Models can be initialized by specifying the name of a model provided by ObsPy.
Names of available builtin models (in ``obspy/taup/data`` folder) are provided
by :const:`~obspy.taup.BUILTIN_TAUP_MODELS`.
>>> from obspy.taup import TauPyModel
>>> model = TauPyModel(model="iasp91")
Model initialization is a fairly expensive operation so make sure to do it only
if necessary. Custom built models can be initialized by specifying an absolute
path to a model in ObsPy's ``.npz`` model format instead of just a model name.
See below for how to build a ``.npz`` model file.
Travel Times
^^^^^^^^^^^^
The models' main method is the
:meth:`~obspy.taup.tau.TauPyModel.get_travel_times` method; as the name
suggests it returns travel times for the chosen phases, distance, source depth,
and model. Per default it returns arrivals for a number of phases.
>>> arrivals = model.get_travel_times(source_depth_in_km=55,
... distance_in_degree=67)
>>> print(arrivals) # doctest: +NORMALIZE_WHITESPACE
28 arrivals
P phase arrival at 647.036 seconds
pP phase arrival at 662.230 seconds
sP phase arrival at 668.702 seconds
PcP phase arrival at 674.868 seconds
PP phase arrival at 794.975 seconds
PKiKP phase arrival at 1034.106 seconds
pPKiKP phase arrival at 1050.535 seconds
sPKiKP phase arrival at 1056.727 seconds
S phase arrival at 1176.947 seconds
pS phase arrival at 1195.500 seconds
SP phase arrival at 1196.827 seconds
sS phase arrival at 1203.128 seconds
PS phase arrival at 1205.418 seconds
SKS phase arrival at 1239.088 seconds
SKKS phase arrival at 1239.107 seconds
ScS phase arrival at 1239.515 seconds
SKiKP phase arrival at 1242.400 seconds
pSKS phase arrival at 1260.313 seconds
sSKS phase arrival at 1266.919 seconds
SS phase arrival at 1437.417 seconds
PKIKKIKP phase arrival at 1855.260 seconds
SKIKKIKP phase arrival at 2063.556 seconds
PKIKKIKS phase arrival at 2069.749 seconds
SKIKKIKS phase arrival at 2277.833 seconds
PKIKPPKIKP phase arrival at 2353.930 seconds
PKPPKP phase arrival at 2356.420 seconds
PKPPKP phase arrival at 2358.925 seconds
SKIKSSKIKS phase arrival at 3208.154 seconds
If you know which phases you are interested in, you can also specify them
directly which speeds up the calculation as unnecessary phases are not
calculated. Please note that it is possible to construct *any* phases that
adhere to the naming scheme which is detailed later.
>>> arrivals = model.get_travel_times(source_depth_in_km=100,
... distance_in_degree=45,
... phase_list=["P", "PSPSPS"])
>>> print(arrivals) # doctest: +NORMALIZE_WHITESPACE
3 arrivals
P phase arrival at 485.204 seconds
PSPSPS phase arrival at 4983.023 seconds
PSPSPS phase arrival at 5799.225 seconds
Each arrival is represented by an :class:`~obspy.taup.helper_classes.Arrival`
object which can be queried for various attributes.
>>> arr = arrivals[0]
>>> arr.ray_param, arr.time, arr.incident_angle # doctest: +ELLIPSIS
(453.7188..., 485.2041..., 24.3968...)
Ray Paths
^^^^^^^^^
To also calculate the paths travelled by the rays to the receiver, use the
:meth:`~obspy.taup.tau.TauPyModel.get_ray_paths` method.
>>> arrivals = model.get_ray_paths(500, 130)
>>> arrival = arrivals[0]
The result is a NumPy record array containing ray parameter, time, distance
and depth to use however you see fit.
>>> arrival.path.dtype
dtype([('p', '<f8'), ('time', '<f8'), ('dist', '<f8'), ('depth', '<f8')])
Pierce Points
^^^^^^^^^^^^^
If you only need the pierce points of ray paths with model discontinuities,
use the :meth:`~obspy.taup.tau.TauPyModel.get_pierce_points` method which
results in pierce points being stored as a record array on the arrival object.
>>> arrivals = model.get_pierce_points(500, 130)
>>> arrivals[0].pierce.dtype
dtype([('p', '<f8'), ('time', '<f8'), ('dist', '<f8'), ('depth', '<f8')])
Plotting
--------
If ray paths have been calculated, they can be plotted using the
:meth:`~obspy.taup.tau.Arrivals.plot` method:
>>> arrivals = model.get_ray_paths(source_depth_in_km=500,
... distance_in_degree=130)
>>> arrivals.plot() # doctest: +SKIP
.. plot::
:width: 50%
:align: center
from obspy.taup import TauPyModel
TauPyModel().get_ray_paths(500, 130).plot()
Plotting will only show the requested phases:
>>> arrivals = model.get_ray_paths(
... source_depth_in_km=500,
... distance_in_degree=130,
... phase_list=["Pdiff", "Sdiff", "pPdiff", "sSdiff"])
>>> arrivals.plot() # doctest: +SKIP
.. plot::
:width: 50%
:align: center
from obspy.taup import TauPyModel
TauPyModel().get_ray_paths(
500, 130,
phase_list=["Pdiff", "Sdiff", "pPdiff", "sSdiff"]).plot()
Additionally, Cartesian coordinates may be used instead of a polar grid:
>>> arrivals = model.get_ray_paths(source_depth_in_km=500,
... distance_in_degree=130,
... phase_list=["ttbasic"])
>>> arrivals.plot(plot_type="cartesian") # doctest: +SKIP
.. plot::
:width: 75%
:align: center
from obspy.taup import TauPyModel
TauPyModel().get_ray_paths(
500, 130, phase_list=["ttbasic"]).plot(plot_type="cartesian")
More examples of plotting may be found in the :doc:`ObsPy tutorial
</tutorial/code_snippets/travel_time>`.
Phase naming in obspy.taup
--------------------------
.. note::
This section is a modified copy from the Java TauP Toolkit documentation so
all credit goes to the authors of that.
A major feature of ``obspy.taup`` is the implementation of a phase name parser
that allows the user to define essentially arbitrary phases through the Earth.
Thus, ``obspy.taup`` is extremely flexible in this respect since it is not
limited to a pre-defined set of phases. Phase names are not hard-coded into the
software, rather the names are interpreted and the appropriate propagation path
and resulting times are constructed at run time. Designing a phase-naming
convention that is general enough to support arbitrary phases and easy to
understand is an essential and somewhat challenging step. The rules that we
have developed are described here. Most of the phases resulting from these
conventions should be familiar to seismologists, e.g. ``pP``, ``PP``, ``PcS``,
``PKiKP``, etc. However, the uniqueness required for parsing results in some
new names for other familiar phases.
In traditional "whole-Earth" seismology, there are 3 major interfaces: the free
surface, the core-mantle boundary, and the inner-outer core boundary. Phases
interacting with the core-mantle boundary and the inner core boundary are easy
to describe because the symbol for the wave type changes at the boundary (i.e.,
the symbol ``P`` changes to ``K`` within the outer core even though the wave
type is the same). Phase multiples for these interfaces and the free surface
are also easy to describe because the symbols describe a unique path. The
challenge begins with the description of interactions with interfaces within
the crust and upper mantle. We have introduced two new symbols to existing
nomenclature to provide unique descriptions of potential paths. Phase names are
constructed from a sequence of symbols and numbers (with no spaces) that either
describe the wave type, the interaction a wave makes with an interface, or the
depth to an interface involved in an interaction.
1. Symbols that describe wave-type are:
* ``P`` - compressional wave, upgoing or downgoing; in the crust or mantle,
``p`` is a strictly upgoing *P*-wave in the crust or mantle
* ``S`` - shear wave, upgoing or downgoing, in the crust or mantle
* ``s`` - strictly upgoing *S*-wave in the crust or mantle
* ``K`` - compressional wave in the outer core
* ``I`` - compressional wave in the inner core
* ``J`` - shear wave in the inner core
2. Symbols that describe interactions with interfaces are:
* ``m`` - interaction with the Moho
* ``g`` appended to ``P`` or ``S`` - ray turning in the crust
* ``n`` appended to ``P`` or ``S`` - head wave along the Moho
* ``c`` - topside reflection off the core mantle boundary
* ``i`` - topside reflection off the inner core outer core boundary
* ``ˆ`` - underside reflection, used primarily for crustal and mantle
interfaces
* ``v`` - topside reflection, used primarily for crustal and mantle
interfaces
* ``diff`` appended to ``P`` or ``S`` - diffracted wave along the core
mantle boundary
* ``kmps`` appended to a velocity - horizontal phase velocity (see 10
below)
3. The characters ``p`` and ``s`` **always** represent up-going legs. An
example is the source to surface leg of the phase ``pP`` from a source at
depth. ``P`` and ``S`` can be turning waves, but always indicate downgoing
waves leaving the source when they are the first symbol in a phase name.
Thus, to get near-source, direct *P*-wave arrival times, you need to specify
two phases ``p`` and ``P`` or use the "*ttimes* compatibility phases"
described below. However, ``P`` may represent a upgoing leg in certain
cases. For instance, ``PcP`` is allowed since the direction of the phase is
unambiguously determined by the symbol ``c``, but would be named ``Pcp`` by
a purist using our nomenclature.
4. Numbers, except velocities for ``kmps`` phases (see 10 below), represent
depths at which interactions take place. For example, ``P410s`` represents a
*P*-to-*S* conversion at a discontinuity at 410km depth. Since the *S*-leg
is given by a lower-case symbol and no reflection indicator is included,
this represents a *P*-wave converting to an *S*-wave when it hits the
interface from below. The numbers given need not be the actual depth; the
closest depth corresponding to a discontinuity in the model will be used.
For example, if the time for ``P410s`` is requested in a model where the
discontinuity was really located at 406.7 kilometers depth, the time
returned would actually be for ``P406.7s``. The code would note that this
had been done. Obviously, care should be taken to ensure that there are no
other discontinuities closer than the one of interest, but this approach
allows generic interface names like “410” and “660” to be used without
knowing the exact depth in a given model.
5. If a number appears between two phase legs, e.g. ``S410P``, it represents a
transmitted phase conversion, not a reflection. Thus, ``S410P`` would be a
transmitted conversion from *S* to *P* at 410km depth. Whether the
conversion occurs on the down-going side or up-going side is determined by
the upper or lower case of the following leg. For instance, the phase
``S410P`` propagates down as an ``S``, converts at the 410 to a ``P``,
continues down, turns as a *P*-wave, and propagates back across the 410 and
to the surface. ``S410p`` on the other hand, propagates down as a ``S``
through the 410, turns as an *S*-wave, hits the 410 from the bottom,
converts to a ``p`` and then goes up to the surface. In these cases, the
case of the phase symbol (``P`` vs. ``p``) is critical because the direction
of propagation (upgoing or downgoing) is not unambiguously defined elsewhere
in the phase name. The importance is clear when you consider a source depth
below 410 compared to above 410. For a source depth greater than 410 km,
``S410P`` technically cannot exist while ``S410p`` maintains the same path
(a receiver side conversion) as it does for a source depth above the 410.
The first letter can be lower case to indicate a conversion from an up-going
ray, e.g., ``p410S`` is a depth phase from a source at greater than 410
kilometers depth that phase converts at the 410 discontinuity. It is
strictly upgoing over its entire path, and hence could also be labeled
``p410s``. ``p410S`` is often used to mean a reflection in the literature,
but there are too many possible interactions for the phase parser to allow
this. If the underside reflection is desired, use the ``pˆ410S`` notation
from rule 7.
6. Due to the two previous rules, ``P410P`` and ``S410S`` are over specified,
but still legal. They are almost equivalent to ``P`` and ``S``,
respectively, but restrict the path to phases transmitted through (turning
below) the 410. This notation is useful to limit arrivals to just those that
turn deeper than a discontinuity (thus avoiding travel time curve
triplications), even though they have no real interaction with it.
7. The characters ``ˆ`` and ``v`` are new symbols introduced here to represent
bottom-side and top-side reflections, respectively. They are followed by a
number to represent the approximate depth of the reflection or a letter for
standard discontinuities, ``m``, ``c`` or ``i``. Reflections from
discontinuities besides the core-mantle boundary, ``c``, or inner-core
outer-core boundary, ``i``, must use the ``ˆ`` and ``v`` notation. For
instance, in the TauP convention, ``pˆ410S`` is used to describe a
near-source underside reflection. Underside reflections, except at the
surface (``PP``, ``sS``, etc.), core-mantle boundary (``PKKP``, ``SKKKS``,
etc.), or outer-core-inner-core boundary (``PKIIKP``, ``SKJJKS``,
``SKIIKS``, etc.), must be specified with the ``ˆ`` notation. For example,
``Pˆ410P`` and ``PˆmP`` would both be underside reflections from the 410km
discontinuity and the Moho, respectively. The phase ``PmP``, the traditional
name for a top-side reflection from the Moho discontinuity, must change
names under our new convention. The new name is ``PvmP`` or ``Pvmp`` while
``PmP`` just describes a *P*-wave that turns beneath the Moho. The reason
why the Moho must be handled differently from the core-mantle boundary is
that traditional nomenclature did not introduce a phase symbol change at the
Moho. Thus, while ``PcP`` makes sense since a *P*-wave in the core would be
labeled ``K``, ``PmP`` could have several meanings. The ``m`` symbol just
allows the user to describe phases interaction with the Moho without knowing
its exact depth. In all other respects, the ``ˆ`` - ``v`` nomenclature is
maintained.
8. Currently, ``ˆ`` and ``v`` for non-standard discontinuities are allowed only
in the crust and mantle. Thus there are no reflections off non-standard
discontinuities within the core, (reflections such as ``PKKP``, ``PKiKP``
and ``PKIIKP`` are still fine). There is no reason in principle to restrict
reflections off discontinuities in the core, but until there is interest
expressed, these phases will not be added. Also, a naming convention would
have to be created since “``p`` is to ``P``” is not the same as “``i`` is to
``I``”.
9. Currently there is no support for ``PKPab``, ``PKPbc``, or ``PKPdf`` phase
names. They lead to increased algorithmic complexity that at this point
seems unwarranted. Currently, in regions where triplications develop, the
triplicated phase will have multiple arrivals at a given distance. So,
``PKPab`` and ``PKPbc`` are both labeled just ``PKP`` while ``PKPdf`` is
called ``PKIKP``.
10. The symbol ``kmps`` is used to get the travel time for a specific
horizontal phase velocity. For example, ``2kmps`` represents a horizontal
phase velocity of 2 kilometers per second. While the calculations for these
are trivial, it is convenient to have them available to estimate surface
wave travel times or to define windows of interest for given paths.
11. As a convenience, a ``ttimes`` phase name compatibility mode is available.
So ``ttp`` gives you the phase list corresponding to ``P`` in ``ttimes``.
Similarly there are ``tts``, ``ttp+``, ``tts+``, ``ttbasic`` and ``ttall``.
Building custom models
----------------------
Custom models can be built from ``.tvel`` files using the
:func:`~obspy.taup.taup_create.build_taup_model` function.
"""
from __future__ import (absolute_import, division, print_function,
unicode_literals)
from future.builtins import * # NOQA
import os
# Convenience imports.
from .tau import TauPyModel # NOQA
from .taup import getTravelTimes, travelTimePlot # NOQA
# Internal imports.
from .taup_create import get_builtin_models as _get_builtin_models
BUILTIN_TAUP_MODELS = [
os.path.splitext(os.path.basename(path))[0]
for path in _get_builtin_models()]
if __name__ == '__main__':
import doctest
doctest.testmod(exclude_empty=True)
# -*- coding: utf-8 -*-
"""
C wrappers for some crucial inner loops of TauPy written in C.
"""
from __future__ import (absolute_import, division, print_function,
unicode_literals)
from future.builtins import * # NOQA
from future.utils import native_str
import ctypes as C
import numpy as np
from obspy.core.util.libnames import _load_CDLL
from .helper_classes import SlownessLayer, TimeDist
clibtau = _load_CDLL("tau")
clibtau.tau_branch_calc_time_dist_inner_loop.argtypes = [
# ray_params
np.ctypeslib.ndpointer(dtype=np.float64, ndim=2,
flags=native_str('C_CONTIGUOUS')),
# mask
np.ctypeslib.ndpointer(dtype=np.int32, ndim=2,
flags=native_str('C_CONTIGUOUS')),
# time
np.ctypeslib.ndpointer(dtype=np.float64, ndim=2,
flags=native_str('C_CONTIGUOUS')),
# dist
np.ctypeslib.ndpointer(dtype=np.float64, ndim=2,
flags=native_str('C_CONTIGUOUS')),
# layer, record array, 64bit floats. 2D array in memory
np.ctypeslib.ndpointer(dtype=SlownessLayer, ndim=1,
flags=native_str('C_CONTIGUOUS')),
# time_dist, record array, 64bit floats. 2D array in memory
np.ctypeslib.ndpointer(dtype=TimeDist, ndim=1,
flags=native_str('C_CONTIGUOUS')),
# max_i
C.c_int32,
# max_j
C.c_int32,
# max ray param
C.c_double
]
clibtau.tau_branch_calc_time_dist_inner_loop.restype = None
clibtau.seismic_phase_calc_time_inner_loop.argtypes = [
# degree
C.c_double,
# max_distance
C.c_double,
# dist
np.ctypeslib.ndpointer(dtype=np.float64, ndim=1,
flags=native_str('C_CONTIGUOUS')),
# ray_param
np.ctypeslib.ndpointer(dtype=np.float64, ndim=1,
flags=native_str('C_CONTIGUOUS')),
# search_dist_results
np.ctypeslib.ndpointer(dtype=np.float64, ndim=1,
flags=native_str('C_CONTIGUOUS')),
# ray_num_results
np.ctypeslib.ndpointer(dtype=np.int32, ndim=1,
flags=native_str('C_CONTIGUOUS')),
# count
C.c_int
]
clibtau.seismic_phase_calc_time_inner_loop.restype = C.c_int
clibtau.bullen_radial_slowness_inner_loop.argtypes = [
# layer, record array, 64bit floats. 2D array in memory
np.ctypeslib.ndpointer(dtype=SlownessLayer, ndim=1,
flags=native_str('C_CONTIGUOUS')),
# p
np.ctypeslib.ndpointer(dtype=np.float64, ndim=1,
flags=native_str('C_CONTIGUOUS')),
# time
np.ctypeslib.ndpointer(dtype=np.float64, ndim=1,
flags=native_str('C_CONTIGUOUS')),
# dist
np.ctypeslib.ndpointer(dtype=np.float64, ndim=1,
flags=native_str('C_CONTIGUOUS')),
# radius
C.c_double,
# max_i
C.c_int
]
clibtau.bullen_radial_slowness_inner_loop.restype = None
To (re)create models from all '.tvel' files in this folder run 'taup_create.py'.
ak135 - P
ak135 - S
0.000 5.8000 3.4600 2.7200
20.000 5.8000 3.4600 2.7200
20.000 6.5000 3.8500 2.9200
35.000 6.5000 3.8500 2.9200
35.000 8.0400 4.4800 3.3198
77.500 8.0450 4.4900 3.3455
120.000 8.0500 4.5000 3.3713
165.000 8.1750 4.5090 3.3985
210.000 8.3000 4.5180 3.4258
210.000 8.3000 4.5230 3.4258
260.000 8.4825 4.6090 3.4561
310.000 8.6650 4.6960 3.4864
360.000 8.8475 4.7830 3.5167
410.000 9.0300 4.8700 3.5470
410.000 9.3600 5.0800 3.7557
460.000 9.5280 5.1860 3.8175
510.000 9.6960 5.2920 3.8793
560.000 9.8640 5.3980 3.9410
610.000 10.0320 5.5040 4.0028
660.000 10.2000 5.6100 4.0646
660.000 10.7900 5.9600 4.3714
710.000 10.9229 6.0897 4.4010
760.000 11.0558 6.2095 4.4305
809.500 11.1353 6.2426 4.4596
859.000 11.2221 6.2798 4.4885
908.500 11.3068 6.3160 4.5173
958.000 11.3896 6.3512 4.5459
1007.500 11.4705 6.3854 4.5744
1057.000 11.5495 6.4187 4.6028
1106.500 11.6269 6.4510 4.6310
1156.000 11.7026 6.4828 4.6591
1205.500 11.7766 6.5138 4.6870
1255.000 11.8491 6.5439 4.7148
1304.500 11.9200 6.5727 4.7424
1354.000 11.9895 6.6008 4.7699
1403.500 12.0577 6.6285 4.7973
1453.000 12.1245 6.6555 4.8245
1502.500 12.1912 6.6815 4.8515
1552.000 12.2550 6.7073 4.8785
1601.500 12.3185 6.7326 4.9052
1651.000 12.3819 6.7573 4.9319
1700.500 12.4426 6.7815 4.9584
1750.000 12.5031 6.8052 4.9847
1799.500 12.5631 6.8286 5.0109
1849.000 12.6221 6.8515 5.0370
1898.500 12.6804 6.8742 5.0629
1948.000 12.7382 6.8972 5.0887
1997.500 12.7956 6.9194 5.1143
2047.000 12.8526 6.9418 5.1398
2096.500 12.9096 6.9627 5.1652
2146.000 12.9668 6.9855 5.1904
2195.500 13.0222 7.0063 5.2154
2245.000 13.0783 7.0281 5.2403
2294.500 13.1336 7.0500 5.2651
2344.000 13.1894 7.0720 5.2898
2393.500 13.2465 7.0931 5.3142
2443.000 13.3018 7.1144 5.3386
2492.500 13.3585 7.1369 5.3628
2542.000 13.4156 7.1586 5.3869
2591.500 13.4741 7.1807 5.4108
2640.000 13.5312 7.2031 5.4345
2690.000 13.5900 7.2258 5.4582
2740.000 13.6494 7.2490 5.4817
2740.000 13.6494 7.2490 5.4817
2789.670 13.6530 7.2597 5.5051
2839.330 13.6566 7.2704 5.5284
2891.500 13.6602 7.2811 5.5515
2891.500 8.0000 0.0000 9.9145
2939.330 8.0382 0.0000 9.9942
2989.660 8.1283 0.0000 10.0722
3039.990 8.2213 0.0000 10.1485
3090.320 8.3122 0.0000 10.2233
3140.660 8.4001 0.0000 10.2964
3190.990 8.4861 0.0000 10.3679
3241.320 8.5692 0.0000 10.4378
3291.650 8.6496 0.0000 10.5062
3341.980 8.7283 0.0000 10.5731
3392.310 8.8036 0.0000 10.6385
3442.640 8.8761 0.0000 10.7023
3492.970 8.9461 0.0000 10.7647
3543.300 9.0138 0.0000 10.8257
3593.640 9.0792 0.0000 10.8852
3643.970 9.1426 0.0000 10.9434
3694.300 9.2042 0.0000 11.0001
3744.630 9.2634 0.0000 11.0555