[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
970416: netCDF installation problems
- Subject: 970416: netCDF installation problems
- Date: Wed, 16 Apr 97 16:14:27 -0600
Joerg,
>Date: Wed, 16 Apr 1997 13:36:59 -0700 (PDT)
>From: Joerg Kaduk <address@hidden>
>To: address@hidden
>Organization: Stanford University
>Keywords: 199704160532.XAA03476
>Subject: Re: 970416: netCDF installation problems
In the above message, you wrote:
>
> Hi Steve,
> thanks very much for your answer to my installation trouble!
>
> > The above should have been "setenv CPPFLAGS -DNDEBUG" (no "=").
>
> Uhh, sorry about that! `guess it was too late yesterday evening for
> my brain to still keep sh and csh syntax apart :-(
>
> Now:
>
> stipa.Stanford.EDU% uname -a
> SunOS stipa.Stanford.EDU 5.5.1 Generic_103640-06 sun4m sparc
> SUNW,SPARCstation-LX
>
> > Which "cc" are you using (i.e. what's its absolute
> > pathname and version)? Do you have a "c89"?
>
> stipa.Stanford.EDU% which cc
> /usr/ucb/cc
WHOAA!!! Line 10 of the INSTALL file says:
Select an ANSI C compiler ...
/usr/ucb/cc isn't an ANSI compiler; therefore, all bets are off.
>
> A a look at that script and a grep for cc suggests that it uses
> exclusively /usr/ccs/bin/ucbcc ... which is linked to
> /opt/SUNWspro/SC4.0/bin/acc
>
> There are cc acc and c89 on that system... For some reason they all
> say their version was
> SC4.0 18 Oct 1995 C 4.0
> They are different though (filesize)...?
>
> > You're welcome. Just send me the answers to my questions and we should
> > have you up and running soon.
> Hey, sounds great! Now I did delete config.cache and run configure again.
> I append the stuff below. Not much changed (nothing easily detectable...)
> Then I used: setenv CC /opt/SUNWspro/SC4.0/bin/c89
> and rerun configure (again cache removed...) This resulted in IEEE used
> - see below - and a new libsrc/ncconfig.h which hasn't been recreated in the
> other case. Right now make is running and it seems fine...
> Can you give me a hint what the hack is the difference between all these
> compilers?
Some conform to the C standard (e.g. "c89") and others don't (e.g.
"/usr/ucb/cc"). That makes all the difference in the world.
> ok make seemed to have worked...
> make test is running now and nothing complained so far.
> Can you tell me what make instell does
"make install" installs the package's components into the installation
"bin/", "include/", "lib/", and "man/" directories (taken from the
configure script's "--prefix=" option, if you specified one). This is
very common.
> and what the flag -DNDEBUG are doing?
-DNDEBUG turns off the "assert()" macro in the C code (which we use for
debugging purposes).
>
> So far the tests seem ok and the cmp 's haven't produced a line :-)
> ... all tests sucessful - no failures! Great!!
>
> I'll go ahead now and try linking my test and application...
> Thanks!
> If you can spare the time - I've got another question - more of an
> archiving/visualization question....
> I'm planning a largish model run - however on land only - say in a 1x1
> degree resolution. Since I'm running only land I do only want to store
> results on the land points only and not on the full 1x1 degree grid ...
> (for storage and processing time: I have about 15,000 grid elements
> compared to 360*(58+85)=51480 (all land is between -58 and 85 deg N and))
> Yet I'd love to use some standard plotting package and a storage format
> which allows to store all neccessary metadata with the data (that's
> why I'm looking into netCDF...). And last not least I'd love if that
> plotting package could recognize what's in the data file... Now
> ferret for example seems quite able to read netCDF and make sense out of it.
> But, if I don't store the full grid all these plotting packages seem
> to run into trouble. It would be fine if I'd stored a mask at the beginning
> of the data file giving the land points of the grid or say the coordinates
> of the land points. However I need to keep the overhead reasonable (so I
> can't store all the coordinates with each variable - I guess I have about
> 50 (or more) variables and want to store at least monthly over a couple of
> years... Finally it'll be totally great if that plotting/analysis software
> could make sense out of a vegetation map saved with the data...
> Now I realize that all this might be wishful thinking only, but...
> Would be great, if you had any ideas/suggestions (how exactely to save the
> data or maybe a more clever plotting package - although the next version
> of ferrel will seemingly be able to do all this ... I don't know when this
> will come out though.
I afraid I'm not up on all the various visualization packages and their
capabilities. I suggest you look into their descriptions on the netCDF
Web page.
>
> ok enough blabla, I hope that was al least partly interesting. Thanks
> I'm using and the general setup I'd be happy to get the information to
> you. Also I guess
>
> SunOS stipa.Stanford.EDU 5.5.1 Generic_103640-06 sun4m sparc
> SUNW,SPARCstation-LX
> CFLAGS = -O
> CC = /opt/SUNWspro/SC4.0/bin/c89 -DNDEBUG
> FC = f77
> might be the right entry in the list in INSTALL?
>
> Should I try acc again? As: CC = /opt/SUNWspro/SC4.0/bin/acc -DNDEBUG
I wouldn't.
>
> Maybe so far. Thanks again. I'll let you hear my progress and my next trouble
> ;-)
> Joerg
--------
Steve Emmerson <address@hidden>