This page has descriptions of the file formats that we use in various places.
SRF info format
The .info files that accompany .srf files are in HDF5 format. The filenames match with the exception of the extension.
All information is stored as attributes.
There are 4 types of SRF files that can be created, all SRF files are created directly or indirectly via createSRF.py.
Type 1 | point source. appears as 1 plane with 1 subfault. |
---|---|
Type 2 | finite fault. a single plane created from point source attributes, it has an are determined by a magnitude scaling relation. |
Type 3 | finite fault. a single plane created with specified parameters. |
Type 4 | finite fault. a multiple plane fault. planes can be internally generated together and cut up (like plane extensions that continue at a different strike angle) or: separate cases where multiple SRFs are combined. where separate cases are used, each can have a delay time to synchronise rupture initiation time between cases. |
Common Attributes (always available)
attribute | description |
---|---|
type | 1: point source, 2: finite fault from point source info, 3: single plane, 4: multiple plane |
dt | slip time step (s) |
rake | rake angles (type 1-3: single value, type 4: 2D list for cases, fault planes) |
mag | magnitude (type 1-3: single value, type 4: list for each case) |
hlon | hypocentre longitude for first fault (degrees) |
hlat | hypocentre latitude for first fault (degrees) |
hdepth | hypocentre depth for first fault (km) |
corners | 4 corners (longitude, latitude) for each plane. derived parameter (shape of array is nplane, 4 corners, 2 lonlat values). |
SRF Plane Attributes (lists with a length matching number of fault planes)
naming taken from qcore/srf.py
attribute | description |
---|---|
centre | top centre longitude, latitude |
nstrike | number of subfaults along strike |
ndip | number of subfaults along dip |
length | length (along strike) of fault plane (km) |
width | width (along dip) of fault plane (km) |
strike | strike angle (degrees) |
dip | dip angle (degrees) |
shyp | hypocentre location along strike from top centre (km), -999.9 for plane extentions |
dhyp | hypocentre location along dip from top edge (km), -999.9 for plane extentions |
dtop | depth of top edge (km) |
dbottom | depth to bottom of plane, derived parameter (km) |
Type 1 (point source) Attributes
attribute | description |
---|---|
vs | vs at centroid depth (km/s) |
rho | density |
Type 2 (finite fault from point source data) Attributes
attribute | description |
---|---|
mwsr | magnitude scaling relation name |
Type 2+ (finite faults) Attributes
attribute | description |
---|---|
vm | velocity model used (basename) |
shyp0 | distance along strike (km) to hypocentre for each case from top left corner (strike = 0, dip = 0) |
dhyp0 | distance along dip (km) to hypocentre for each case from top left corner (strike = 0, dip = 0) |
Optional Attributes (need to check if they exist)
attribute | description |
---|---|
tect_type | tectonic type, taken from the NHM file in nhm2srf.py. known options: ACTIVE_SHALLOW VOLCANIC SUBDUCTION_INTERFACE |
LF/HF/BB binary format
These files store timeseries data. All formats follow a style derived from the LF seis format produced by EMOD3D:
- station size, common metadata
- station list with station metadata
- timeseries
Numbers are 4 bytes in length and may be little or big endian. You can see or use the existing interfaces that also take care of endianness at github:ucgmsim/qcore/qcore/timeseries.py::LFSeis, HFSeis, BBSeis.
File size can be derived knowing the format and the number of stations, and shape of time-series (all necessary values are at the beginning of the file).
The second section is repeated for each station.
The LF format contains unnecessarily repeated common metadata in the station list section (in italics below).
In BB, stations are ordered to match the station input file used in the LF. This means if there was an 'index of station in input file' in BB, it would run incrementally from 0. This is also the case for HF however it is based on the station file given which should therefore be the same (same order of stations) and this is currently a requirement for BB.
HF and BB have gaps between the first 2 sections to allow future additions to section 1 without breaking backwards compatibility.
LF | HF | BB |
---|---|---|
i4 number of stations TOTAL 4 BYTES | i4 number of stations
i4 number of ray methods
i4 first ray method used TOTAL 288 BYTES | i4 number of stations TOTAL 788 BYTES |
START OFFSET 4 BYTES i4 index of station in input file TOTAL 48 BYTES * NUM_STATIONS | START OFFSET 512 BYTES f4 longitude of station (degrees) TOTAL 24 BYTES * NUM_STATIONS | START OFFSET 1280 BYTES f4 longitude of station (degrees) TOTAL 44 BYETS * NUM_STATIONS |
START OFFSET 0 FROM ABOVE f4 velocity (cm/s) timeseries in array dimensions: TOTAL 4 BYTES * PRODUCT_OF_DIMENTIONS | START OFFSET 0 FROM ABOVE f4 acceleration (cm/s^2) timeseries in array dimensions: TOTAL 4 BYTES * PRODUCT_OF_DIMENTIONS | START OFFSET 0 FROM ABOVE f4 acceleration (g) timeseries in array dimensions: TOTAL 4 BYTES * PRODUCT_OF_DIMENTIONS |
XYTS.e3d binary format
This file is produced by EMOD3D and contains a timeseries of ground motions on the XY plane. Unlike the LF seis files, this contains data at all grid points and may have a decimated resolution specified when running EMOD3D through the e3d.par file with the parameters dxts and dyts.
Numbers are 4 bytes in length and may be little or big endian. You can see or use the existing interfaces that also take care of endianness at github:ucgmsim/qcore/qcore/xyts.py::XYTSFile.
File size can be derived knowing the format and the shape of time-series (all necessary values are at the beginning of the file).
The gridpoints are based on a model which is an area with equidistant gridpoints in the X, Y, and Z directions. It is centred on a position (longitude, latitude) and may be rotated.
- simulation metadata
- INTEGERS
- number of first x gridpoint
- number of first y gridpoint
- number of first z gridpoint
- number of first timestep
- number of x gridpoints
- number of y gridpoints
- number of z gridpoins (always 1 by definition of X-Y file)
- number of timesteps
- FLOATS
- x spacing between given gridpoints (km)
- y spacing between given gridpoints (km)
- original (pre-decimated) grid spacing between gridpoints used in simulation (km)
- timestep in timeseries (s)
- model rotation of gridpoints (degrees)
- model centre latitude (degrees)
- model centre longitude (degrees)
- x spacing between given gridpoints (km)
- INTEGERS
- timeseries
- float array of velocities in the dimentions of timesteps, components (x, y, z), y grid positions, x grid positions.
Intensity Measure calculation
The IM calculation code will produce a number of text files (decided as of 25/05/2018). We will summarize them in the following.
Intensity measure files
There are two types of IM files: per station and aggregate. The per station one has the following format:
component, IM_1, IM_2, ...., IM_N
Note: The per station file does not have the station name, as it is the file name.
The aggregate one has all the stations on a single place:
station, component, IM_1, IM_2, ...., IM_N
Empirical IMs
As above the empirical intensity measures have a similar format:
station, component, IM_1, IM_1_sigma, IM_2, IM_2_sigma, ...., IM_N, IM_N_sigma
Notes: 1) the component for empirical IMs is always 'geom' 2) only total sigma is saved to the csv file
Rrup file
The file format for this is:
station, lat, lon, rrup, rjbs, rx
Note: we don't have rx calculations yet, so we may dump an invalid value just to conform with the format.
Metadata file
So far the requirements indicate that we need:
identifier, rupture, type, date, version