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
Gildas manager
2015-03-19