Bear with me.
Afraid that I may have introduced some conflict between NetCDF packages of
different versions. Originally, I said that I had 4.2.1 installed, but
looking at my installed packages in my package manager I realized that
libnetcdf-devel and libnetcdf4 packages were in fact versions 4.0.1. These
two packages came from the openSUSE 12.1 OSS repository, whereas the other
netcdf 4.2.1 packages came from the Geo repository, which is usually much
more up to date. To add to my concern, when I typed nc-config --has-dap, I
got 'no', and nc-config --version gave me 'netCDF 4.0.1'.
I uninstalled the two 4.0.1 packages and reinstalled those that remained
(just for a fresh start) with my package manager. My system now looks like
this (zypper is a cmd line package manager for those not familiar with
suse, and 'i' indicates installed):
taylor@linux-ekge:~/Downloads/> zypper se --details netcdf
Loading repository data...
Reading installed packages...
S | Name | Type | Version | Arch | Repository
--+---------------------+------------+--------------+--------+-----------------------
| libnetcdf-devel | package | 4.0.1-14.1.3 | x86_64 |
openSUSE-12.1-Oss
| libnetcdf-devel | package | 4.0.1-14.1.3 | x86_64 |
openSUSE-12.1-12.1-1.4
| libnetcdf-devel | package | 4.0.1-14.1.3 | i586 |
openSUSE-12.1-Oss
| libnetcdf4 | package | 4.0.1-14.1.3 | x86_64 |
openSUSE-12.1-Oss
| libnetcdf4 | package | 4.0.1-14.1.3 | x86_64 |
openSUSE-12.1-12.1-1.4
| libnetcdf4 | package | 4.0.1-14.1.3 | i586 |
openSUSE-12.1-Oss
i | libnetcdf7 | package | 4.2.1-13.2 | x86_64 | Geo
v | libnetcdf7 | package | 4.2.1-13.2 | i586 | Geo
i | netcdf | package | 4.2.1-13.2 | x86_64 | Geo
v | netcdf | package | 4.0.1-14.1.3 | x86_64 |
openSUSE-12.1-Oss
v | netcdf | package | 4.2.1-13.2 | i586 | Geo
v | netcdf | package | 4.0.1-14.1.3 | i586 |
openSUSE-12.1-Oss
| netcdf | srcpackage | 4.2.1-13.2 | noarch | Geo
i | netcdf-devel | package | 4.2.1-13.2 | x86_64 | Geo
v | netcdf-devel | package | 4.2.1-13.2 | i586 | Geo
| netcdf-devel-static | package | 4.2.1-13.2 | x86_64 | Geo
| netcdf-devel-static | package | 4.2.1-13.2 | i586 | Geo
i | netcdf-doc | package | 4.2.1-13.2 | x86_64 | Geo
v | netcdf-doc | package | 4.2.1-13.2 | i586 | Geo
I then installed the NetCDF C++ API from this link
http://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-cxx4-4.2.tar.gz
and now the command nc-config --all yields the following:
This netCDF 4.2.1 has been built with the following features:
--cc -> gcc
--cflags -> -I/usr/include
--libs ->
--has-c++ -> no
--cxx ->
--has-c++4 -> yes
--cxx4 -> g++
--fc ->
--fflags ->
--flibs ->
--has-f90 -> no
--has-dap -> yes
--has-nc2 -> yes
--has-nc4 -> yes
--has-hdf5 -> yes
--has-hdf4 -> no
--has-pnetcdf-> no
--has-szlib ->
--prefix -> /usr
--includedir-> /usr/include
--version -> netCDF 4.2.1
Since I am now using a more current version of the NetCDF C++ API, it
appears that some of the syntax is different. I now have a testing program,
test_v2.cpp, that looks like this:
#include <iostream>
#include <cstdlib>
#include <cstring>
#include <netcdf> // Note that in original test.cpp file, this was
netcdfcpp.h
using namespace std;
using namespace netCDF; // Note that these two namespaces are new to
test_v2.cpp
using namespace netCDF::exceptions;
int main()
{
NcFile dataFile ("
http://goldsmr2.sci.gsfc.nasa.gov/opendap/hyrax/MERRA/MAT1NXSLV.5.2.0/1979/01/MERRA100.prod.assim.tavg1_2d_slv_Nx.19790101.hdf";,
NcFile::read);
cout <<dataFile.isNull()<<endl; // The method dataFile.is_valid() no
longer works with this new library
return 0;
}
...which I compile using the command g++ test_v2.cpp -lnetcdf_c++4
-lnetcdf. This is successful, and when I run the program I get the output
'0', presumably indicating that dataFile is actually a valid file, and that
I have successfully remotely accessed the MERRA file with it's OPeNDAP URL.
I am going to assume that the "nc-config --has-dap = no" thing, which I
mentioned above, is related to my inability to not open the file in my
earlier attempts, despite using the proper OPeNDAP URL, and not the http
service. Please tell me if this makes sense.
Anyways I just wanted to post this here to summarize. I expect I'm not yet
out of the woods and will have more specific questions later. Thank you
tons for your replies, Roy.
Taylor
On Sat, Jan 19, 2013 at 12:41 PM, Roy Mendelssohn - NOAA Federal <
roy.mendelssohn@xxxxxxxx> wrote:
> Hi Taylor:
>
> When you go to the Hyrax server you mentioned, there are different
> services that are provided. One is called the "http" service, which
> literally downloads the listed file. That service downloads an hdf file
> that we have already determined can't be read by the netcdf libraries.
>
> The second service is the OpeNDAP service. That is the service used by
> the netcdf libraries for remote access of a dataset, and which through the
> OpeNDAP service makes the remote file "look" like a netcdf file, even
> though it isn't. To access the file through this service, the URL must be
> that of the OPeNDAP service. If you are unsure of the URL for the service,
> if you go to the html page that I pointed you to, at the top is a box that
> gives you the base URL for the OPeNDAP service. I did not point you there
> because you had to go there everytime, but for you to put the correct URL.
> In fact, if you want a subset, you can select that in HTML page, but
> instead of downloading the file copy the URL and use it in your program.
>
> The key point is the URL I sent is the base URL for the OPeNDaP service,
> while the URL you are using is the base URL for the http service. If you
> want to use remote access in the netcdf libraries, you need to use the
> OPeNDAP URL. That access will in fact download anOPeNDAP binary, but that
> is irrelevant - with the proper calls you program will act as if the file
> were a netcdf file on your computer.
>
> You are trying to use a number of technologies that do take some time and
> effort to learn and to learn how they interact with one another. The
> netcdf libraries and the netcdf docs have some examples of using OPeNDAP to
> access remote files, and you might go through those, make certain you have
> code that works with those, and that you understand what is going on in the
> code.
>
> -Roy
>
> On Jan 19, 2013, at 9:01 AM, Taylor Binnington <tbinnington@xxxxxxxxx>
> wrote:
>
> > Thank you very much Roy. Let me see if I understand you correctly.
> >
> > You are proposing that I insert the hyrax/ directory into the URL for an
> OPeNDAP response. If I point my browser to either of the following URLs
> >
> >
> http://goldsmr2.sci.gsfc.nasa.gov/opendap/hyrax/MERRA/MAT1NXSLV.5.2.0/1979/01/MERRA100.prod.assim.tavg1_2d_slv_Nx.19790101.hdf
> >
> >
> http://goldsmr2.sci.gsfc.nasa.gov/opendap/MERRA/MAT1NXSLV.5.2.0/1979/01/MERRA100.prod.assim.tavg1_2d_slv_Nx.19790101.hdf
> >
> > then the HDF file is downloaded. I understand that appending .html takes
> me to a page where I can specify some options, subset, click on 'Get as
> NetCDF' (equivalent to appending .nc instead of .html, I believe) or
> 'Binary (DAP) Object (equivalent to appending .dods), etc. I could also
> bypass this step by incorporating my constraint into the URL, for example
> >
> >
> http://goldsmr2.sci.gsfc.nasa.gov/opendap/MERRA/MAT1NXSLV.5.2.0/1979/01/MERRA100.prod.assim.tavg1_2d_slv_Nx.19790101.hdf?XDim_EOSGRID[10:20]
> >
> > gets me some arbitrary subset of the data, in HDF format, stored on my
> computer.
> >
> > But I would like to know if I can remotely open such a file for reading
> (with or without including subsetting constraints in the URL itself) using
> my simple test.cpp script, included in my initial post. None of the three
> URLs included here are successful (meaning that my little test.cpp returns
> "Failed" in each case). I get the same "Failed" when I append .nc or .dods
> to the URL, with or without including the hyrax/ subdirectory in the path.
> >
> > Can I modify the line in test.cpp,
> >
> > NcFile dataFile ("
> http://goldsmr2.sci.gsfc.nasa.gov/opendap/hyrax/MERRA/MAT1NXSLV.5.2.0/1979/01/MERRA100.prod.assim.tavg1_2d_slv_Nx.19790101.hdf";,
> NcFile::ReadOnly);
> >
> > to achieve what I am trying to do? Thank you in advance.
> > Taylor
> >
> >
> > On Fri, Jan 18, 2013 at 7:50 PM, Roy Mendelssohn - NOAA Federal <
> roy.mendelssohn@xxxxxxxx> wrote:
> > Hi Taylor:
> >
> > Having a reproducible example helps. I believe the URL you are using
> will use the http service, which will indeed downlaod the HDF file. For
> the OpeNDAP response using instead (i didn't check that we are pointing at
> the same file):
> >
> >
> http://goldsmr2.sci.gsfc.nasa.gov/opendap/hyrax/MERRA/MAT1NXSLV.5.2.0/1979/01/MERRA100.prod.assim.tavg1_2d_slv_Nx.19790101.hdf
> >
> > The way I got this is from:
> >
> >
> http://goldsmr2.sci.gsfc.nasa.gov/opendap/hyrax/MERRA/MAT1NXSLV.5.2.0/1979/01/contents.html
> >
> > I asked for the html response, which takes me to a page that will show
> be the URL for an OPeNDAP request among other things, that is to the page:
> >
> >
> http://goldsmr2.sci.gsfc.nasa.gov/opendap/hyrax/MERRA/MAT1NXSLV.5.2.0/1979/01/MERRA100.prod.assim.tavg1_2d_slv_Nx.19790101.hdf.html
> >
> > If you only want part of the file, you can include the constraints in
> the URL.
> >
> > HTH.
> >
> > -Roy
> > On Jan 18, 2013, at 3:59 PM, Taylor Binnington <tbinnington@xxxxxxxxx>
> wrote:
> >
> > > Hello (again),
> > > I have netcdf-4.2.1-13.2 libraries installed on my openSUSE 12.1
> machine. I am trying to open a MERRA data file from within a C++ program,
> using OPeNDAP.
> > >
> > > A sample test.cpp program is below, which I compile using g++ test.cpp
> -lnetcdf_c++ ,
> > >
> > > #include<iostream>
> > > #include<netcdfcpp.h>
> > > int main()
> > > {
> > > NcFile dataFile ("
> http://goldsmr2.sci.gsfc.nasa.gov/opendap/MERRA/MAT1NXSLV.5.2.0/1979/01/MERRA100.prod.assim.tavg1_2d_slv_Nx.19790101.hdf";,
> NcFile::ReadOnly);
> > >
> > > if(!dataFile.is_valid()){
> > > cout << "Failed" << endl;
> > > return 2;}
> > > cout << "Okay" << endl;
> > > return 0;
> > > }
> > >
> > > returns "Failed". Opening the local file
> MERRA100.prod.assim.tavg1_2d_slv_Nx.19790101.hdf.nc (obtained by
> converting to *.nc from the same OPeNDAP server, as was recommended to me
> in this post:
> https://www.unidata.ucar.edu/mailing_lists/archives/netcdfgroup/2013/msg00008.html)
> returns "Okay". Material here (
> http://www.hdfeos.org/workshops/ws13/presentations/day3/PRACTICAL_METHODS_FOR_MAKING_HDF_DATA_USABLE.pdf,
> beginning on page 24) leads me to believe that I simply can not use NetCDF
> libraries to open MERRA files with OPeNDAP.
> > >
> > > How, if possible, can I modify test.cpp to remotely open a MERRA data
> file, without having to first download it to my computer? Thank you for any
> help.
> > >
> > > P.S. Please do not think that I have ignored earlier replies (I
> appreciate them!), I've spent quite a lot of time on this recently.
> > >
> > >
> > >
> > > --
> > > Taylor Binnington
> > > e. tbinnington@xxxxxxxxx
> > >
> > > _______________________________________________
> > > netcdfgroup mailing list
> > > netcdfgroup@xxxxxxxxxxxxxxxx
> > > For list information or to unsubscribe, visit:
> http://www.unidata.ucar.edu/mailing_lists/
> >
> > **********************
> > "The contents of this message do not reflect any position of the U.S.
> Government or NOAA."
> > **********************
> > Roy Mendelssohn
> > Supervisory Operations Research Analyst
> > NOAA/NMFS
> > Environmental Research Division
> > Southwest Fisheries Science Center
> > 1352 Lighthouse Avenue
> > Pacific Grove, CA 93950-2097
> >
> > e-mail: Roy.Mendelssohn@xxxxxxxx (Note new e-mail address)
> > voice: (831)-648-9029
> > fax: (831)-648-8440
> > www: http://www.pfeg.noaa.gov/
> >
> > "Old age and treachery will overcome youth and skill."
> > "From those who have been given much, much will be expected"
> > "the arc of the moral universe is long, but it bends toward justice"
> -MLK Jr.
> >
> >
> >
> >
> > --
> > Taylor Binnington
> > e. tbinnington@xxxxxxxxx
> >
>
> **********************
> "The contents of this message do not reflect any position of the U.S.
> Government or NOAA."
> **********************
> Roy Mendelssohn
> Supervisory Operations Research Analyst
> NOAA/NMFS
> Environmental Research Division
> Southwest Fisheries Science Center
> 1352 Lighthouse Avenue
> Pacific Grove, CA 93950-2097
>
> e-mail: Roy.Mendelssohn@xxxxxxxx (Note new e-mail address)
> voice: (831)-648-9029
> fax: (831)-648-8440
> www: http://www.pfeg.noaa.gov/
>
> "Old age and treachery will overcome youth and skill."
> "From those who have been given much, much will be expected"
> "the arc of the moral universe is long, but it bends toward justice" -MLK
> Jr.
>
>
--
Taylor Binnington
e. tbinnington@xxxxxxxxx
c. 647 926 4144
