get/put_vara usage?

[Smith, Brian E.]

Well, this change seems to make it a lot happier:

   ncmpi_def_dim(ofh, "lon", lon, &dims[0]);
   ncmpi_def_dim(ofh, "lat", lat, &dims[1]);

I'm not entirely sure why though, because I did have:
ncmpi_inq(fh, &num_dims, &num_vars, &num_attrs, &num_unlim);
for(i = 0; i < num_dims; i++)
{
   ncmpi_inq_dim(fh, i, dimname, &dlen);
   ncmpi_def_dim(ofh, dimname, dlen, &dim_id); 
}
as part of setup_global_dims_attrs(), so shouldn't the inq_dim on the output file be ok?


On Nov 27, 2012, at 2:12 PM, Smith, Brian E. wrote:

> I am new to (p)netCDF and am having trouble trying to make use of get/put_vara to extract "slices" of a 4D variable from some data I've been given. I've read the docs and looked at the examples but things still aren't working for me.
> 
> The variable looks like: var[time][elev][lat][lon] with time being an "unlimited" variable
> 
> My code is essentially:
> 
>   open_files(&fh, &ofh); // open the input file for read, open the output file for write.
>   setup_global_dims_attrs(fh, ofh); // inq_var then def_var lat/lon/elev/time then copies their atributes
> 
>   /* Define my output variable dimensions */
>   ncmpi_inq_dimid(ofh, "lon", &dims[0]);
>   ncmpi_inq_dimid(ofh, "lat", &dims[1]);
>   ncmpi_def_dim(ofh, "plev", elev2-elev1, &dims[2]);
>   ncmpi_def_dim(ofh, "time", time2-time1, &dims[3]);
>   ncmpi_def_var(ofh, outname, type, ndims, dims, &outid);
> 
>   ncmpi_enddef(ofh);
> 
>   copy_global_dims(fh, ofh); //inq var on input, inq var on output, get_var on input, put_var on output for lat/lon/elev/time variables
> 
> MPI_Offset start[4], count[4], outstart[4];
> start = {time1, elev1, 0, 0};
> count  = (time2-time1, elev2-elev1, lat, lon};
> outstart = {0,0,0,0};
> total = count[0] * count[1] * count[2] * count[3];
> float data = malloc(sizeof(float) * total);
> ncmpi_get_vara_float_all(fh, varid, start, count, data);
> ncmpi_put_vara_float_all(ofh, varid, outstart, count, data);
> cllose_files(fh, ofh)
> 
> 
> However, this just results in junk in the output file. There is no practical way to verify the read worked correctly unfortunately, so I can't tell if the read or the write call is incorrect. 
> 
> I would certainly appreciate any help.
> 
> Thanks.
>