Keywords: sic-gdfv2

Next: Restriction on the use Up: The new layout Previous: Data Format Identification Contents

### Dap positions and size

The list of possible `daps` entities is defined in appendix C, with the associated codes used to tagged them. This list can be extended as required.

The `dap` position as well as its length can vary. For example, the `item` dap would be located at `h%gil%column_pointer(code_uvt_item)`, and it could be a `real(4)` or `real(8)` number depending on the value of `h%gil%column_size(code_uvt_item)`.

The `daps` element can be located either before the complex visibilities, or after, but not intermixed with them. Accordingly, there can be `h%gil%nlead` leading columns before the complex visibility values and `h%gil%ntrail` trailing columns after. Note that these number indicates the number of 32-bit columns, so if any of the `dap` is a 64-bit number (`h%gil%column_size(code_uvt_dap) = 2`), `nlead+ntrail` will be greater than the number of non-zero values in `h%gil%column_size(:)`.

The existence of `daps` entities of different lengths raise a specific issue when transposing a UV tables. By default in GILDAS, transpositions are applied on the global data type. For UV tables, this is `fmt_r4`, i.e. 32 bit entities. Assume we start with a natural (UVT) order, with for example a 64 bit quantity. After transposition to TUV order, the first 32 bit of are in the first column, and the last 32 bits in the second. This is incoherent. Thus a second transposition is required on these specific columns to establish the contiguity of the 64-bit values. This is handled transparently by the GIO library, in `gdf_transpose` as well as in `gdf_read_gildas`.

Subsections

- Restriction on the use of `real(8)` daps
- Are `real(4)` U,V,W coordinates sufficient?

Next: Restriction on the use Up: The new layout Previous: Data Format Identification Contents