Standard Guide for Analytical Data Interchange Protocol for Chromatographic Data

SIGNIFICANCE AND USE
6.1 General Coding Guidelines—The NetCDF libraries are supplied to developers as source code. End users receive the libraries in compiled binary form as part of a vendor's application.  
6.1.1 Some vendors found that compilation using the huge memory model under Microsoft Windows on MS-DOS was needed because of an array pointer passing its boundary. Many vendors chose to write a conversion program as a stand-alone DOS application, whereby the conversion program used only text-mode screen I/O. Some vendors are now using it in their MS-Windows applications.  
6.1.2 Developers setting out to write a program to convert their data files to the Chromatographic Data Protocol should use the NetCDF utilities ncgen and ncdump. Applying the ncgen utility to the CHROMSTD.CDL template will generate the skeletal code needed to create the NetCDF file. The programmer can then modify the code to create a program that reads the netDCF file from another vendor. After developers create the NetCDF file they should use the ncdump program to generate the ASCII representation of the data files, and examine it to ensure the data is being correctly put into the file.  
6.2 Make Files for NetCDF Libraries and Utilities—In general the compilation is straightforward. The make files were modified after they were received from the Unidata Corporation, because they did not compile the first time on PCs. The changes needed to get the Unidata distribution to run on DOS are (1) rename the file MAKEFILE to UNIX.MK, and (2) rename MSOFT.MK to MAKEFILE, and then run NMAKE. The default switches in the Unidata distribution use the switches for the floating point coprocessor and Microsoft Windows options.  
6.2.1 The protocol contain some complete makefile examples for Microsoft C V6.0 running on DOS. The Microsoft C V6.0 compiler manual should be consulted for the exact meaning of the compiler and linker options.  
6.2.2 The VMS and SunOS compilation instructions are in directories for those operatin...
SCOPE
1.1 This guide covers the implementation of the Chromatographic Data Protocol in analytical software applications. Implementation of this protocol requires:  
1.1.1 Specification E1947, which contains the full set of data definitions. The chromatographic data protocol is not based upon any specific implementation; it is designed to be independent of any particular implementation, so that implementations can change as technology evolves. The protocol is implemented in stages, to speed its acceptance through actual use.  
1.1.2 Specification E1947 contains a full description of the contents of the data communications protocol, including the analytical information categories with data elements and their attributes for most aspects of chromatographic tests.  
1.2 The Analytical Information Categories are a practical convenience for breaking down the standardization process into smaller, more manageable pieces. It is easier for developers to build consensus and produce working systems based on smaller information sets, without the burden and complexity of the hundreds of data elements contained in all the categories. The categories also assist vendors and end users in using the guide in their computing environments.  
1.3 The NetCDF Data Interchange System is the container used to communicate data between applications in a way that is independent of both computer architectures and end-user applications. In essence, it is a special type of application designed for data interchange.  
1.4 The Common Data Language (CDL) Template for Chromatography is a language specification of the chromatography dataset being interchanged. With the use of the NetCDF utilities, this human-readable template can be used to generate an equivalent binary file and the software subroutine calls needed for input and output of data in analytical applications.

General Information

Status
Historical
Publication Date
31-Jul-2014
Current Stage
Ref Project

Buy Standard

Guide
ASTM E1948-98(2014) - Standard Guide for Analytical Data Interchange Protocol for Chromatographic Data
English language
8 pages
sale 15% off
Preview
sale 15% off
Preview
Guide
REDLINE ASTM E1948-98(2014) - Standard Guide for Analytical Data Interchange Protocol for Chromatographic Data
English language
8 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)


NOTICE: This standard has either been superseded and replaced by a new version or withdrawn.
Contact ASTM International (www.astm.org) for the latest information
Designation: E1948 − 98 (Reapproved 2014)
Standard Guide for
Analytical Data Interchange Protocol for Chromatographic
Data
This standard is issued under the fixed designation E1948; the number immediately following the designation indicates the year of
original adoption or, in the case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. A
superscript epsilon (´) indicates an editorial change since the last revision or reapproval.
1. Scope 2. Referenced Documents
2.1 ASTM Standards:
1.1 This guide covers the implementation of the Chromato-
graphic Data Protocol in analytical software applications. E1947 Specification for Analytical Data Interchange Proto-
col for Chromatographic Data
Implementation of this protocol requires:
2.2 Other Standard:
1.1.1 Specification E1947, which contains the full set of
data definitions. The chromatographic data protocol is not NetCDF User’s Guide
based upon any specific implementation; it is designed to be
3. Features of the Chromatographic Data Interchange
independent of any particular implementation, so that imple-
Implementation Guide
mentations can change as technology evolves. The protocol is
implemented in stages, to speed its acceptance through actual 3.1 The chromatographic data protocol consists of: (1) the
use. data contents (what is being transferred), and (2) the data
container (how it is being transferred).
1.1.2 Specification E1947 contains a full description of the
contents of the data communications protocol, including the
3.2 Analytical Information Categories—To make the stan-
analytical information categories with data elements and their
dardization process more manageable, fiveAnalytical Informa-
attributes for most aspects of chromatographic tests.
tion Categories were defined:
1.2 The Analytical Information Categories are a practical
1. Raw Data
2. Final Results
convenience for breaking down the standardization process
3. Full Data Processing Method
into smaller, more manageable pieces. It is easier for develop-
4. Full Chemical Method
ers to build consensus and produce working systems based on
5. Good Laboratory Practices Information
smaller information sets, without the burden and complexity of
3.2.1 This guide covers implementation of Raw Data (Cat-
the hundreds of data elements contained in all the categories.
egory 1) and Final Results (Category 2). The development
The categories also assist vendors and end users in using the
committee has completed implementation and testing of infor-
guide in their computing environments.
mation in these categories.
1.3 The NetCDF Data Interchange System is the container
3.3 Chromatography Data Elements—Each data element
used to communicate data between applications in a way that
specifies a piece of information that is to be stored or
is independent of both computer architectures and end-user
transferred to another system. A data element has a name, a
applications. In essence, it is a special type of application
definition, and may have some default attributes, such as its
designed for data interchange.
datatype, the analytical information category to which it
belongs, and whether it is mandatory or recommended. A data
1.4 The Common Data Language (CDL) Template for
element may also reference other data elements.
Chromatography is a language specification of the chromatog-
raphy dataset being interchanged. With the use of the NetCDF
3.4 NetCDF Data Interchange System—NetCDF is a data
utilities, this human-readable template can be used to generate
interchange system designed specifically for the requirements
an equivalent binary file and the software subroutine calls
of scientific data. It was developed to meet the requirements of
needed for input and output of data in analytical applications.
high-performance, large dataset interchange over networks, in
For referenced ASTM standards, visit the ASTM website, www.astm.org, or
This guide is under the jurisdiction of ASTM Committee E13 on Molecular contact ASTM Customer Service at service@astm.org. For Annual Book of ASTM
Spectroscopy and Separation Science and is the direct responsibility of Subcom- Standards volume information, refer to the standard’s Document Summary page on
mittee E13.15 on Analytical Data. the ASTM website.
Current edition approved Aug. 1, 2014. Published August 2014. Originally Available from Russell K. Rew, Unidata Program Center, University Corpora-
approved in 1998. Last previous edition approved in 2009 as E1948 – 98 (2009). tion for Atomospheric Research, P. O. Box 3000, Boulder, CO 80307-3000,
DOI: 10.1520/E1948-98R14. http://www2.ucar.edu.
Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959. United States
E1948 − 98 (2014)
a machine- and network-independent way. NetCDF is imple-
mented in the portable C programming language, and is made
to be available on all popular scientific computers and operat-
ing systems. It achieves platform-independence through the
use of the XDR protocol for byte-stream encoding. XDR
(eXternal Data Representation) was developed by Sun Micro-
systems as part of the Network File System (NFS) and is now
in the public domain. NetCDF has a particular advantage over
many other approaches, such as ASCII flat files or structured
ASCII files, because it uses the abstraction of a data access
interface or abstractApplication Programming Interface (API).
This API lets the application developer deal with data more in
terms of logical entities, instead of having to think about
specific details of encoding and decoding data. This guide
FIG. 1 Usage of NetCDF Utilities
specifies the use of version 2.0 or later, and the exchange
software should determine only that the version of NetCDF is
version 2.0 or greater.
3.6.2 Developers typically start with the CDL source code
3.5 Common Data Language—ANetCDF data file has both
description of the data file they wish to interchange. Then the
binary and human-readable representations. The human-
ncgen utility with the -n option generates the NetCDF binary
readable form is anASCII-encoded file written in the NetCDF
file. Developers then use ncgen with the -c option to generate
system’s Common Data Language (CDL). CDL is a data
the C source code needed for the subroutines to read and write
description language, which is a simplified type of program-
this particular dataset (specified by the CDL template.) These
ming language without any action statements. The main
read/write subroutines make up the NetCDF Application Pro-
purpose of a data description language is the specification of
gramming Interface (API). These routines are simply cut and
data structures. CDL is a generic data description language for
pasted into the target application(s).The programmer then uses
scientificdata;itisnotapplication-specific.Thebasicconstruct
the API to read or write data in NetCDF datasets.
in CDL is that of a multidimensional array, to which many
3.6.3 If FORTRAN is the programming language being
types of metadata can be attached. Metadata is additional data
used, the ncgen utility with the -f option can generate the
about the data, that is, attributes about the data that help turn it
FORTRAN source code wrappers needed to embed the
into useful information.
NetCDF library code into FORTRAN applications.
3.5.1 For the protocol, a template for chromatography
3.6.4 Once the application populates the data file with its
written in CDL is supplied to developers. The CDL template
data, that file can be transferred to another system. If a
provides an easily comprehended text version of the structure
developer or end user needs a human-readable version of the
and contents of a binary NetCDF file. Developers use this
binary dataset, the binary file can be fed into the ncdump
template with certain NetCDF utilities to generate the software
utility, which regenerates the original CDL source code. The
code (subroutine calls) needed to use the NetCDF toolkit. The
ncdump utility has an option switch to regenerate the CDL
generated code can then be cut and pasted in the end-user
code with or without the actual experimental data. Some
application.
datasets can be enormous and there may be no reason to view
3.5.2 For a full description of the Common Data Language,
the entire dataset. In this way, data are easily encoded into
see the NetCDF User’s Guide.
NetCDF files and the required routines to read and write those
3.6 NetCDF Utilities—The NetCDF data interchange sys-
data are incorporated into applications.
tem has two very powerful utilities called “ncgen” and “nc-
3.6.5 There is another way to build NetCDF data files.
dump” that eliminate much work for developers.
Using the NetCDF Application Programming Interface, it is
3.6.1 After the template for a particular analytical technique
possible to build NetCDF binary files one data element at a
dataset (in this case chromatography) is written in CDL, it is
time.However,thatmethodisgenerallymoretime-consuming,
fed into ncgen. There are several options with ncgen, the first
and it is not recommended except for those situations where
of which creates the binary file and populates it with fields
applications can fully automate the process.
specified by the CDL template. Other ncgen options generate
code for the C language subroutines required for an application
4. Chromatographic Data Protocol Distribution Kit
to read and write data in the NetCDF file, and the FORTRAN
4.1 Information on how to obtain the kit will be posted on
wrapper code needed for FORTRAN programs. The ncdump
the ASTM web site (www.astm.org) under Committee E49.
utility reads the binary files generated by ncgen (which were
then populated by the application using the NetCDF libraries), 4.2 TheAnalyticalDataInterchangeProtocolforChromato-
and then generates their ASCII-encoded, human-readable rep- graphic Data Distribution Kit contains:
resentation. ncdump is routinely used to check the contents of 4.2.1 Software Disks—NetCDF distribution kit from Uni-
NetCDF files, and debug applications that use NetCDF. It can data (with the modified makefile needed to make the kit
also be used to export data to reporting programs. Fig. 1 compile out of the box), and the Chromatographic Data
illustrates the usage of the NetCDF utilities. Protocol CDL Template.
E1948 − 98 (2014)
4.2.2 NetCDF User’s Guide—supplied by Unidata Program text-mode screen I/O. Some vendors are now using it in their
Center. MS-Windows applications.
4.2.3 Specification E1947.
6.1.2 Developers setting out to write a program to convert
4.2.4 Guide E1948.
their data files to the Chromatographic Data Protocol should
4.2.5 Registration Card, used for tracking and user updates.
use the NetCDF utilities ncgen and ncdump. Applying the
ncgen utility to the CHROMSTD.CDL template will generate
5. Hardware and Software the skeletal code needed to create the NetCDF file. The
programmer can then modify the code to create a program that
5.1 This section describes the hardware and software con-
reads the netDCF file from another vendor. After developers
figurations used for testing. In general, the NetCDF system
create the NetCDF file they should use the ncdump program to
puts very few requirements on the hardware, because most
generate the ASCII representation of the data files, and
routines are left on disk. Only routines being used at any
examine it to ensure the data is being correctly put into the file.
particulartimearekeptinmemory.Anylimitationsfoundwere
typically those not imposed by NetCDF but ones imposed by
6.2 Make Files for NetCDF Libraries and Utilities—In
the operating system or environment.
generalthecompilationisstraightforward.Themakefileswere
5.1.1 Hardware (Personal Computers)—The personal com-
modified after they were received from the Unidata
puter system hardware used for testing was:
Corporation, because they did not compile the first time on
5.1.1.1 Intel 80286 processor,
PCs. The changes needed to get the Unidata distribution to run
5.1.1.2 640K minimum,
on DOS are (1) rename the file MAKEFILE to UNIX.MK, and
5.1.1.3 monochrome, EGA, VGA graphics,
(2) rename MSOFT.MK to MAKEFILE, and then run
5.1.1.4 20 megabyte minimum, 80 megabyte hard-disk is
NMAKE. The default switches in the Unidata distribution use
typical, and
the switches for the floating point coprocessor and Microsoft
5.1.1.5 a mouse (optional).
Windows options.
5.1.1.6 NetCDF works well on AT-class machines and
6.2.1 The protocol contain some complete makefile ex-
higher. NetCDF does not have the items in 5.1.1.1 – 5.1.1.5 as
amples for Microsoft C V6.0 running on DOS. The Microsoft
requirements. These are just the minimum, base-level systems
C V6.0 compiler manual should be consulted for the exact
that were used.
meaning of the compiler and linker options.
5.1.2 Software—NetCDF runs on MS-DOS, OS/2,
6.2.2 The VMS and SunOS compilation instructions are in
Macintosh, Windows 95, and Windows NT operating systems
directories for those operating systems.
for personal computers. NetCDF was originally ported from
6.3 NetCDF Library Build Order—The NetCDF libraries
UNIX to DOS running on an IBM-PS/2 Model 80. It was
must be built in a specific order. The correct order to build the
recently ported to the Macintosh OS. NetCDF is written is the
NetCDF directories is:
C programming language, and there are FORTRAN jackets
available for applications that want to use FORTRAN calls. UTIL
XDR
The personal computer software employed for testing and
SRC
developing NetCDF applications were:
NCDUMP
NCGEN
5.1.2.1 Microsoft DOS V3.3 or above,
NCTEST
5.1.2.2 Microsoft C Compiler V6.0,
5.1.2.3 Microsoft Windows V3.0, 6.3.1 The UTIL and XDR makefiles work as distributed
5.1.2.4 Microsoft Windows SDK, and using NMAKE with Microsoft C V6.0.
5.1.2.5 NetCDF Version 2.0.1.
5.1.3 Workstations and Servers—NetCDF runs easily on
7. CDL Template Structure
UNIX workstations such as Sun 3, Sun 4, VAXstations,
7.1 A NetCDF template is built from CDL statements and
DECstation 3100, VAXstation II running ULTRIX or VMS,
structured into three sections: (1) dimension declarations, (2)
and IBM RS/6000. There are no particular hardware require-
variable declarations, and (3) the data section.
ments for workstation class machines, since all workstations
7.2 AfewpointsofclarificationabouttheCDLlanguageare
have the minimum hardware outlined for personal computers
in 5.1.1. given here to facilitate understanding of the CDL Generic
Chromatography Template given in Fig. 2. For more in-depth
information on CDL, please consult the NetCDF User’s Guide.
6. Significance and Use
7.2.1 A NetCDF template starts with the word “NetCDF”
6.1 General Coding Guidelines—The NetCDF libraries are
followed by the dataset name.
...


This document is not an ASTM standard and is intended only to provide the user of an ASTM standard an indication of what changes have been made to the previous version. Because
it may not be technically possible to adequately depict all changes accurately, ASTM recommends that users consult prior editions as appropriate. In all cases only the current version
of the standard as published by ASTM is to be considered the official document.
Designation: E1948 − 98 (Reapproved 2009) E1948 − 98 (Reapproved 2014)
Standard Guide for
Analytical Data Interchange Protocol for Chromatographic
Data
This standard is issued under the fixed designation E1948; the number immediately following the designation indicates the year of
original adoption or, in the case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. A
superscript epsilon (´) indicates an editorial change since the last revision or reapproval.
1. Scope
1.1 This guide covers the implementation of the Chromatographic Data Protocol in analytical software applications.
Implementation of this protocol requires:
1.1.1 Specification E1947, which contains the full set of data definitions. The chromatographic data protocol is not based upon
any specific implementation; it is designed to be independent of any particular implementation, so that implementations can change
as technology evolves. The protocol is implemented in stages, to speed its acceptance through actual use.
1.1.2 Specification E1947 contains a full description of the contents of the data communications protocol, including the
analytical information categories with data elements and their attributes for most aspects of chromatographic tests.
1.2 The Analytical Information Categories are a practical convenience for breaking down the standardization process into
smaller, more manageable pieces. It is easier for developers to build consensus and produce working systems based on smaller
information sets, without the burden and complexity of the hundreds of data elements contained in all the categories. The categories
also assist vendors and end users in using the guide in their computing environments.
1.3 The NetCDF Data Interchange System is the container used to communicate data between applications in a way that is
independent of both computer architectures and end-user applications. In essence, it is a special type of application designed for
data interchange.
1.4 The Common Data Language (CDL) Template for Chromatography is a language specification of the chromatography
dataset being interchanged. With the use of the NetCDF utilities, this human-readable template can be used to generate an
equivalent binary file and the software subroutine calls needed for input and output of data in analytical applications.
2. Referenced Documents
2.1 ASTM Standards:
E1947 Specification for Analytical Data Interchange Protocol for Chromatographic Data
2.2 Other Standard:
NetCDF User’s Guide
3. Features of the Chromatographic Data Interchange Implementation Guide
3.1 The chromatographic data protocol consists of: (1) the data contents (what is being transferred), and (2) the data container
(how it is being transferred).
3.2 Analytical Information Categories—To make the standardization process more manageable, five Analytical Information
Categories were defined:
1. Raw Data
2. Final Results
3. Full Data Processing Method
4. Full Chemical Method
5. Good Laboratory Practices Information
This guide is under the jurisdiction of ASTM Committee E13 on Molecular Spectroscopy and Separation Science and is the direct responsibility of Subcommittee E13.15
on Analytical Data.
Current edition approved Oct. 1, 2009Aug. 1, 2014. Published December 2009August 2014. Originally approved in 1998. Last previous edition approved in 20042009
as E1948 – 98 (2004).(2009). DOI: 10.1520/E1948-98R09.10.1520/E1948-98R14.
For referenced ASTM standards, visit the ASTM website, www.astm.org, or contact ASTM Customer Service at service@astm.org. For Annual Book of ASTM Standards
volume information, refer to the standard’s Document Summary page on the ASTM website.
Available forfrom Russell K. Rew, Unidata Program Center, University Corporation for Atomospheric Research, P. O. Box 3000, Boulder, CO 80307-3000,
http://www2.ucar.edu.
Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959. United States
E1948 − 98 (2014)
3.2.1 This guide covers implementation of Raw Data (Category 1) and Final Results (Category 2). The development committee
has completed implementation and testing of information in these categories.
3.3 Chromatography Data Elements—Each data element specifies a piece of information that is to be stored or transferred to
another system. A data element has a name, a definition, and may have some default attributes, such as its datatype, the analytical
information category to which it belongs, and whether it is mandatory or recommended. A data element may also reference other
data elements.
3.4 NetCDF Data Interchange System—NetCDF is a data interchange system designed specifically for the requirements of
scientific data. It was developed to meet the requirements of high-performance, large dataset interchange over networks, in a
machine- and network-independent way. NetCDF is implemented in the portable C programming language, and is made to be
available on all popular scientific computers and operating systems. It achieves platform-independence through the use of the XDR
protocol for byte-stream encoding. XDR (eXternal Data Representation) was developed by Sun Microsystems as part of the
Network File System (NFS) and is now in the public domain. NetCDF has a particular advantage over many other approaches,
such as ASCII flat files or structured ASCII files, because it uses the abstraction of a data access interface or abstract Application
Programming Interface (API). This API lets the application developer deal with data more in terms of logical entities, instead of
having to think about specific details of encoding and decoding data. This guide specifies the use of version 2.0 or later, and the
exchange software should determine only that the version of NetCDF is version 2.0 or greater.
3.5 Common Data Language—A NetCDF data file has both binary and human-readable representations. The human-readable
form is an ASCII-encoded file written in the NetCDF system’s Common Data Language (CDL). CDL is a data description
language, which is a simplified type of programming language without any action statements. The main purpose of a data
description language is the specification of data structures. CDL is a generic data description language for scientific data; it is not
application-specific. The basic construct in CDL is that of a multidimensional array, to which many types of metadata can be
attached. Metadata is additional data about the data, that is, attributes about the data that help turn it into useful information.
3.5.1 For the protocol, a template for chromatography written in CDL is supplied to developers. The CDL template provides
an easily comprehended text version of the structure and contents of a binary NetCDF file. Developers use this template with
certain NetCDF utilities to generate the software code (subroutine calls) needed to use the NetCDF toolkit. The generated code
can then be cut and pasted in the end-user application.
3.5.2 For a full description of the Common Data Language, see the NetCDF User’s Guide.
3.6 NetCDF Utilities—The NetCDF data interchange system has two very powerful utilities called “ncgen” and “ncdump” that
eliminate much work for developers.
3.6.1 After the template for a particular analytical technique dataset (in this case chromatography) is written in CDL, it is fed
into ncgen. There are several options with ncgen, the first of which creates the binary file and populates it with fields specified by
the CDL template. Other ncgen options generate code for the C language subroutines required for an application to read and write
data in the NetCDF file, and the FORTRAN wrapper code needed for FORTRAN programs. The ncdump utility reads the binary
files generated by ncgen (which were then populated by the application using the NetCDF libraries), and then generates their
ASCII-encoded, human-readable representation. ncdump is routinely used to check the contents of NetCDF files, and debug
applications that use NetCDF. It can also be used to export data to reporting programs. Fig. 1 illustrates the usage of the NetCDF
utilities.
3.6.2 Developers typically start with the CDL source code description of the data file they wish to interchange. Then the ncgen
utility with the -n option generates the NetCDF binary file. Developers then use ncgen with the -c option to generate the C source
code needed for the subroutines to read and write this particular dataset (specified by the CDL template.) These read/write
FIG. 1 Usage of NetCDF Utilities
E1948 − 98 (2014)
subroutines make up the NetCDF Application Programming Interface (API). These routines are simply cut and pasted into the
target application(s). The programmer then uses the API to read or write data in NetCDF datasets.
3.6.3 If FORTRAN is the programming language being used, the ncgen utility with the -f option can generate the FORTRAN
source code wrappers needed to embed the NetCDF library code into FORTRAN applications.
3.6.4 Once the application populates the data file with its data, that file can be transferred to another system. If a developer or
end user needs a human-readable version of the binary dataset, the binary file can be fed into the ncdump utility, which regenerates
the original CDL source code. The ncdump utility has an option switch to regenerate the CDL code with or without the actual
experimental data. Some datasets can be enormous and there may be no reason to view the entire dataset. In this way, data are
easily encoded into NetCDF files and the required routines to read and write those data are incorporated into applications.
3.6.5 There is another way to build NetCDF data files. Using the NetCDF Application Programming Interface, it is possible to
build NetCDF binary files one data element at a time. However, that method is generally more time-consuming, and it is not
recommended except for those situations where applications can fully automate the process.
4. Chromatographic Data Protocol Distribution Kit
4.1 Information on how to obtain the kit will be posted on the ASTM web site (www.astm.org) under Committee E49.
4.2 The Analytical Data Interchange Protocol for Chromatographic Data Distribution Kit contains:
4.2.1 Software Disks—NetCDF distribution kit from Unidata (with the modified makefile needed to make the kit compile out
of the box), and the Chromatographic Data Protocol CDL Template.
4.2.2 NetCDF User’s Guide—supplied by Unidata Program Center.
4.2.3 Specification E1947.
4.2.4 Guide E1948.
4.2.5 Registration Card, used for tracking and user updates.
5. Hardware and Software
5.1 This section describes the hardware and software configurations used for testing. In general, the NetCDF system puts very
few requirements on the hardware, because most routines are left on disk. Only routines being used at any particular time are kept
in memory. Any limitations found were typically those not imposed by NetCDF but ones imposed by the operating system or
environment.
5.1.1 Hardware (Personal Computers)—The personal computer system hardware used for testing was:
5.1.1.1 Intel 80286 processor,
5.1.1.2 640K minimum,
5.1.1.3 monochrome, EGA, VGA graphics,
5.1.1.4 20 megabyte minimum, 80 megabyte hard-disk is typical, and
5.1.1.5 a mouse (optional).
5.1.1.6 NetCDF works well on AT-class machines and higher. NetCDF does not have the items in 5.1.1.1 – 5.1.1.5 as
requirements. These are just the minimum, base-level systems that were used.
5.1.2 Software—NetCDF runs on MS-DOS, OS/2, Macintosh, Windows 95, and Windows NT operating systems for personal
computers. NetCDF was originally ported from UNIX to DOS running on an IBM-PS/2 Model 80. It was recently ported to the
Macintosh OS. NetCDF is written is the C programming language, and there are FORTRAN jackets available for applications that
want to use FORTRAN calls. The personal computer software employed for testing and developing NetCDF applications were:
5.1.2.1 Microsoft DOS V3.3 or above,
5.1.2.2 Microsoft C Compiler V6.0,
5.1.2.3 Microsoft Windows V3.0,
5.1.2.4 Microsoft Windows SDK, and
5.1.2.5 NetCDF Version 2.0.1.
5.1.3 Workstations and Servers—NetCDF runs easily on UNIX workstations such as Sun 3, Sun 4, VAXstations, DECstation
3100, VAXstation II running ULTRIX or VMS, and IBM RS/6000. There are no particular hardware requirements for workstation
class machines, since all workstations have the minimum hardware outlined for personal computers in 5.1.1.
6. Significance and Use
6.1 General Coding Guidelines—The NetCDF libraries are supplied to developers as source code. End users receive the
libraries in compiled binary form as part of a vendor’s application.
6.1.1 Some vendors found that compilation using the huge memory model under Microsoft Windows on MS-DOS was needed
because of an array pointer passing its boundary. Many vendors chose to write a conversion program as a stand-alone DOS
application, whereby the conversion program used only text-mode screen I/O. Some vendors are now using it in their MS-Windows
applications.
6.1.2 Developers setting out to write a program to convert their data files to the Chromatographic Data Protocol should use the
NetCDF utilities ncgen and ncdump. Applying the ncgen utility to the CHROMSTD.CDL template will generate the skeletal code
E1948 − 98 (2014)
needed to create the NetCDF file. The programmer can then modify the code to create a program that reads the netDCF file from
another vendor. After developers create the NetCDF file they should use the ncdump program to generate the ASCII representation
of the data files, and examine it to ensure the data is being correctly put into the file.
6.2 Make Files for NetCDF Libraries and Utilities—In general the compilation is straightforward. The make files were modified
after they were received from the Unidata Corporation, because they did not compile the first time on PCs. The changes needed
to get the Unidata distribution to run on DOS are (1) rename the file MAKEFILE to UNIX.MK, and (2) rename MSOFT.MK to
MAKEFILE, and then run NMAKE. The default switches in the Unidata distribution use the switches for the floating point
coprocessor and Microsoft Windows options.
6.2.1 The protocol contain some complete makefile examples for Microsoft C V6.0 running on DOS. The Microsoft C V6.0
compiler manual should be consulted for the exact meaning of the compiler and linker options.
6.2.2
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.