[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 20021104:NETCDF installation

>To: address@hidden
>From: nickitas georgas <address@hidden>
>Subject: Re: 20021105: ncvarid: ncid 12: Variable not found
>Organization: Hydroqual, Inc.
>Keywords: 200211051415.gA5EFVX11723

Nickitas,

> Thanks again for your input. I do use FORTRAN 77 for the model and the
> associated NETCDF output that I am trying to create (ECOMSED,
> http://www.hydroqual.com/Hydro/ecomsed/index.htm).
> I send you the model executable (compiled with the netCDF library), so that
> you can get an idea of the error message. The executable "ecomsed_cdf"
> (built with a Makefile in LINUX with a -g option for debugging) has to be in
> the same directory with the three ASCII files "corners", "model_grid", and
> "run_data", which I also provided. Note that when I used pgdbg to try and
> debug the model I got a response similar (but not identical) to what I got
> as a run time error:
> PGDBG: ncvarid: ncid 16: Variable not found
> I also send you the 2 FORTRAN subroutines that output NETCDF.

Sorry, but we just don't have the resources to debug something this
big.  The putcdf.f and tscdf.f subroutines you sent have over 350
calls to netCDF functions, any one of which you may have called with
the wrong number or type of parameters.  There are thousands of netCDF
users and we currently only have 1/4 time of one person for netCDF
support.  Also, due to security concerns, I can't just run a binary
sent by email, since we don't have any Linux systems isolated from
everything else that would permit this kind of testing.

Since you are using the netCDF-2 Fortran77 interface, which has been
in use for many years, I think the problem is probably a bug somewhere
in your code rather than in the netCDF library.  With a debugger or
print statements, you should be able to isolate the problem to a
particular call in a specific subroutine and make some progress on
determining the cause of the problem.

If you can isolate the problem to something smaller that would allow
us to easily reproduce the problem from source and demonstrate it was
a bug in the library, we could investigate it further and provide a
fix or work-around.  But we just don't have the resources to quickly
debug user problems in large codes ...

--Russ

_____________________________________________________________________

Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu