GDF API
Keywords: sic-gdfv2

Next: Obsolete routines Up: Changes for programmers Previous: UV data format usage Contents

##
GDF API

Beside the definition of the GDFV2, the GDF API has been revised and simplified. It is listed in appendix D. As the API provides many tools, some redundancy exists, and one may legitimately ask which is the best way to do things. As usual, the answer depends on what you are doing, and also pretty much on the actual size of your UV data sets. Here are some guidelines.

- Developing a new task.
  Use the integrated API `gdf_read_gildas` as much as possible. It provides consistency checks which you do not have to duplicate. The drawback is that it reads all data at once.

- Consolidating a task.
  If your task requires some consistency checking before doing computations, consider using the integrated API `gdf_read_gildas` with optional argument `data = .false.`, and read the data later. The drawback is that you have to allocate the data array yourself. This can be done through `gdf_allocate`.

- Accessing indifferently a .UVT or .TUV data set.
  Use the integrated API `gdf_read_uvdataset` as much as possible. To do so, you must use `gdf_copy_header` or `gdf_transpose_header` to generate the output header from the input one, depending on whether a transposition is required or not.

- Handling large data sets.
  If your application is likely to need to handle large data sets, you should make use of the abilities of the GDF API to read GDF files by blocks through the `blc(:)` and `trc(:)` arrays. Many operations are actually sequential, so this can use much less memory, and can be faster than considering the whole data set.

Next: Obsolete routines Up: Changes for programmers Previous: UV data format usage Contents