#!F-adobe-helvetica-medium-r-normal--18*
#!N 
#!CNavyBlue 
#!N  #!Rcdf CDF Files #!N #!EC #!N #!N CDF is a 
data abstraction for self-describing multidimensional Arrays. It represents a simpler data 
model than that of Data Explorer, one similar to that of 
the Array Object. Data are accessed in CDF through an applications 
programming interface, available as C and FORTRAN libraries from the National 
Space Science Data Center, NASA/Goddard Space Flight Center, Greenbelt, MD. Data 
in CDF may be stored in a number of physical formats 
(e.g., native or portable binary, single or multiple files, row or 
column majority), but the interface is the same. Hence, data in 
a CDF written in a format "foreign" to the workstation on 
which Data Explorer is running are converted automatically during the Import 
process. #!N #!N Data Explorer provides support for importing Fields stored 
as CDF r-variables. To import data from a CDF, specify the 
CDF name as the  #!F-adobe-times-bold-r-normal--18*   name #!EF parameter in the Import 
Configuration dialog box (not the file name, since the CDF may 
be in multiple-file format). If the CDF has more than one 
variable, which is typical, Data Explorer categorizes each variable as positions, 
series, or data as appropriate. Variables that vary in one dimension 
only and are not record-variant are considered positions, and become the 
positions component in a Field Object. In many cases, these variables 
may have the CDF variable mnemonics of LATITUDE and LONGITUD, which 
are mapped to the first (x) and second (y) components of 
the positions vector, if they exist. This mapping permits direct use 
of these data with cartographic and other tools for the earth 
and space sciences that are publicly available for use with Data 
Explorer. Otherwise, the first  #!F-adobe-times-medium-i-normal--18*   n #!EF variables categorized as positions 
(where  #!F-adobe-times-medium-i-normal--18*   n #!EF is the dimensionality of the CDF dimensions) 
are used to form the positions component. Any additional such variables 
are treated as data variables. If there are no positions-type variables, 
the positions component will be a regular grid with origin of 
0 and increments of 1 in each axis, where the number 
of axes corresponds to the dimensionality of the imported CDF r-variable. 
#!N #!N If there are records in the CDF, each record 
is imported as a series member. In many cases there is 
a variable with the mnemonic EPOCH, which corresponds to a time 
stamp for each record in the CDF. If so, the double 
representing msec since 0 AD in each value of EPOCH is 
stored as the series position attribute. If not, the first variable 
that is record-variant and nondimensional-variant is considered the series variable. This 
variable is imported as the series position attribute. If there is 
no time variable, the series position starts at 1 and increments 
by 1 per series member, so that there is one member 
for each record in the CDF. The series position attribute, containing 
the time stamp, may be accessed with the Attribute module. #!N 
#!N You can specify the name or names of the data 
variable in the  #!F-adobe-times-medium-i-normal--18*   variable #!EF parameter of the Import tool 
and the corresponding variable(s) will be imported. In the same way, 
you can use  #!F-adobe-times-medium-i-normal--18*   start #!EF ,  #!F-adobe-times-medium-i-normal--18*   end #!EF , 
and  #!F-adobe-times-medium-i-normal--18*   delta #!EF to import a subset of CDF records. 
#!N #!N Variable and global attributes present in the CDF are 
imported as Object attributes. These attributes may be accessed through the 
Attribute and Inquire modules (e.g., to build metadata-driven applications). #!N #!N 
Variables that vary in all dimensions and are record-variant are considered 
data variables. Any variable that is not a position or time 
variable is also considered a data variable, allowing every variable to 
be imported. If you want the positions to be a variable 
other than the one chosen by Data Explorer, you can use 
Replace or Rename to switch the components (e.g., two or more 
sets of positions information are stored for different coordinate systems). Each 
data variable becomes a data component in a Field Object. Hence, 
there is one Field for each data variable in the Group 
imported. Since Data Explorer can handle data more flexibly than CDF, 
some assumptions are imposed upon certain classes of data that may 
be imported: #!N #!I0 #!N  #!F-adobe-times-medium-r-normal--18*   #!N #!N #!I30 #!N o 
Since data stored in CDF are not distinguished as cell-centered or 
node-based, all data components are treated as the latter, (i.e., data 
dep positions). The Post module may be used to transform a 
Field to cell-centered (i.e., data dep connections). #!N #!I30 #!N o 
Since CDF does not "natively" support Fields other than rank=0, all 
data variables are treated as scalars. The Compute module can be 
used to construct the appropriate vector representation from multiple scalar Fields. 
#!N #!I30 #!N o The connections component depends on the dimensionality 
of the data variable such that 0 = none, 1 = 
lines, 2 = quads, 3 = cubes, and so on. #!N 
#!I30 #!N o Each positions variable is considered a term of 
a Product Array to form the positions component. #!N #!I30 #!N 
o All variables of 0 dimension are imported as the data 
component of a Field with no positions and no connections. If 
the LATITUDE and/or LONGITUD variables exist, the other variables are considered 
data components of Fields with positions and no connections, where the 
positions are those latitude and longitude variables. You can construct an 
appropriate Field with positions and connections from the variables that are 
imported through modules like Construct, Regrid, and Connect. #!N #!I30 #!N 
o All variables of 1 dimension are imported as the data 
component of a Field of lines, where the positions would typically 
be a scalar (i.e., the one independent variable). If the LATITUDE 
and LONGITUD variables exist, then the positions are a 2-vector constructed 
from the latitude and longitude Arrays, but still a line. #!N 
#!N One-dimensional variables in CDF may be of one of three 
distinct classes, which are NOT distinguished in the way they are 
stored in a CDF file: 1) true 1-dimensional or line data; 
2) indexed point data; or 3) indexed mesh data. You must 
know which class the variable belongs to in order to ensure 
that Data Explorer processes the data in an appropriate fashion. The 
first class is handled correctly. For the second and third class, 
the connections component of any imported Field(s) may be meaningless. You 
can use the Remove module to eliminate it and treat the 
Field as scattered or point data (i.e., use Regrid or Connect 
to create a more appropriate mesh). #!N #!N Treating such data 
as a collection of points is consistent with the original design 
philosophy of CDF and CDF applications. The third case actually represents 
an irregular mesh, which Data Explorer can support directly. Unfortunately, the 
connectivity information (i.e., the mesh structure) is typically not stored in 
the CDF, so Import cannot directly reconstruct the original mesh. Hence, 
the data must be treated as point data unless you have 
information, external to the CDF, that can be used to recreate 
the original mesh structure. #!N #!I0 #!N #!EF #!N #!N #!N 
#!N  #!F-adobe-times-medium-i-normal--18*   Next Topic #!EF #!N #!N  #!Lnetcdf,dxall665 h netCDF Files  #!EL  #!N  #!F-adobe-times-medium-i-normal--18*   #!N 

