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

20010829: MCIDAS - IMGCOPY questions.....



>From: Mike Voss <address@hidden>
>Organization: SJSU
>Keywords: 200108291527.f7TFR3115078 McIDAS IMGCOPY

Mike,

Long time no hear!

>I have a user trying to make NETCDF files from AREA files using the
>IMGCOPY command. His questions were beyond my ability to help. Could
>you look at his questions and provide some support if possible? We are
>running MCIDAS 7.7 on a Sparc 2.7 machine.

OK.

>Thank You,

Talk to you later..

Giovanni,

>>Ciao Mike,
>>
>>now I'm able to reproduce yesterday's funny things, but here are my
>>questions:
>>
>>I created 2 dataset to be able to convert area images to netcdf files in
>>my specific directory using the command DSSERVE with the keyword DIRFILE, but
>>the destination images are always in my working directory for Mcidas,
>>regardless of the keyword. 

The DIRFILE= keyword for DSSERVE is currently used for input only.  It does
not control the location of output files unless the output file is in AREA
format.

>>It's not clear to me if a configuration file for the TYPE image of the
>>NETCDF format exists.

If you mean that you are looking to be able to tailor how the netCDF looks,
then you are correct.  The output file format is fixed.  There is no
formalism that would allow one to define a CDL that would control how
information is written to the output file.

>When I do an IMGCOPY to a netcdf dataset what
>>configuration does it use?

It is hardcoded.  Here are the comments at the beginning of the netCDF
output:

** Remarks:
**
** This is an ADDE server which can be used to convert McIDAS area
** format data into NetCDF format.  Details about the implementation
** of this server follow.
**
** If the TRACE flag is set to some positive value on the command line,
** the server will write a log file to /tmp.  The file will be named
** by subserver name concatenated with the process id.  So an example
** log file might be called (absolute path) /tmp/ncdfaput25296.  This
** feature is purely for debugging purposes.
**
** As far as naming the output files, the current implementation just
** takes the output ADDE descriptor name, concatenates the position
** number padded to four leading digits, and adds a suffix of ".nc".
** So, for the following copy command:
**   IMGCOPY GOES8S/NH.-1 NCDF/GVAR.3 BAND=4
** the output file name would be GVAR0003.nc.
**
** The exact format of the output NetCDF file is certainly not carved
** in stone.  Which area metadata to include, how to format and store
** data and navigation, are all subject to debate.


>>and which parameters can I get out of areas
>>images other than brit counts? 

The output data calibration possibilities are based on the calibration
type of the source image.  I think that the best explanation is the
actual code from ncdfaput.cp:

  /* data units depends on calibration type */

  if (strncmp((char *) &areaDir[CAL_TYPE], "RAD", 3) == 0) {
      /* This section should be replaced by a call to something like clabel */
      if (strncmp((char *) &areaDir[CAL_UNIT],"wp**",4) == 0 || strncmp((char 
*) &area
Dir[CAL_UNIT],"WP**",4) == 0  )
         {
                ncattput (ncId, dataId, NAN_UNITS, NC_CHAR,
                          sizeof("Watts/meter**2/steradian"),
                          (void *) "Watts/meter**2/steradian");
         }
      else if (strncmp((char *) &areaDir[CAL_UNIT],"mw**",4) == 0 || 
strncmp((char *)
&areaDir[CAL_UNIT],"MW**",4) == 0  )
         {
                ncattput (ncId, dataId, NAN_UNITS, NC_CHAR,
                          sizeof("Milliwatts/meter**2/steradian/(cm-1)"),
                          (void *) "Milliwatts/meter**2/steradian/(cm-1)");
         }
     else if (strncmp((char *) &areaDir[CAL_UNIT],"wm**",4) == 0 || 
strncmp((char *) &
areaDir[CAL_UNIT],"WM**",4) == 0  )
         {
                ncattput (ncId, dataId, NAN_UNITS, NC_CHAR,
                          sizeof("Watts/meter**2/steradian/micron"),
                          (void *) "Watts/meter**2/steradian/micron");
         }
     else
         {
                ncattput (ncId, dataId, NAN_UNITS, NC_CHAR,
                          sizeof("Unknown"),
                          (void *) "Unknown");
         }
  }

  if (strncmp((char *) &areaDir[CAL_TYPE], "TEMP", 4) == 0) {
    ncattput (ncId, dataId, NAN_UNITS, NC_CHAR,
      sizeof("degrees K"),
      (void *) "degrees K");
  }

  if (strncmp((char *) &areaDir[CAL_TYPE], "BRIT", 4) == 0) {
    ncattput (ncId, dataId, NAN_UNITS, NC_CHAR,
      sizeof("brightness counts"),
      (void *) "brightness counts");
  }

  if (strncmp((char *) &areaDir[CAL_TYPE], "ALB ", 4) == 0) {
    ncattput (ncId, dataId, NAN_UNITS, NC_CHAR,
      sizeof("percent"),
      (void *) "percent");
  }

  if (strncmp((char *) &areaDir[CAL_TYPE], "RAW", 3) == 0) {
    ncattput (ncId, dataId, NAN_UNITS, NC_CHAR,
      sizeof("unitless"),
  }


>>Why is data:type always VISR even though I use BAND=ALL and I don't specify
>>STYPE=VISR?

This would have to be caused by the source data type.

>>Why do I always have the same headers even if I set DOC=YES? the goes images
>>don't need calibration information?

What gets written to the file is hardcoded in the ouput routine.  It
might be most useful for you to read through the code for the routine
that actually writes the data.  Again, this can be found in
~mcidas/mcidas7.7/src/ncdfaput.cp.

>>thanks a lot!

Sorry I can't be of more help.  If you need further clarification of how
the netCDF output is supposed to work, please send me (address@hidden)
questions directly.  I will answer what I can and query SSEC about the rest.

>>*****************************************************************************
>>Giovanni Leoncini
>>Graduate Student
>>Meteorology Department                     
>>San Jose State University
>>One Washington Square,                         tel :  408-924-5199
>>San Jose, CA, 95112                           email:  address@hidden
>>*****************************************************************************

Tom Yoksas


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.