These are beyond what I know much about, particularly since I am not familiar
at all with the C++ library. I think a lot of the netcdf folk have been on
vacation. I will leave it to people more knowledgeable to reply to these
questions.
-Roy
On Jan 19, 2013, at 8:09 PM, Taylor Binnington <tbinnington@xxxxxxxxx> wrote:
> 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
**********************
"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.
