Re: ccplot errors

[Peter K. <pet...@wa...>]

Hi Yin,

If it does not cause any problems, then I believe it is not necessary.
The code is mostly type agnostic, with the exception of certain
arguments to functions implemented in C (layermap & interpolate2d). The
arguments specifying extent in interpolate2d are parsed by
PyArg_ParseTuple, which does the conversion from double to float without
complaining. It is silently reducing precision, but this should not be a
problem (as the precision in products is 32-bit anyway).

ccplot is in need of more attention. In the next version 1.5, PyNIO is
to be ditched in favour of a cython module interfacing directly with
libhdf and libhdfeos. The benefit is that all other dependencies are
easily installed and available on windows. I'm currently working on a
set of unit tests, as there are many different use cases, and any
slightly more extensive changes to the source code are likely to break
some of them.

Regards,

Peter

On 05/28/2013 03:56 PM, yinjinfang88 wrote:
> Hi Peter,
>         Thank you very much for your help. It works now. However, there
> is a different data type of  ve1 and ve2.
> ccplot -x 500..1000 -c cloudsat-reflectivity.cmap  -o cloudsat-reflec.png cloudsat-reflec  2009037050924_14779_CS_2B-GEOPROF_GRANULE_P_R04_E02.hdf 
> print(ve1.dtype)    ----> int16
> print(ve2.dtype)    ----> int16
>  
> If the hight is limited by the parameter "-y 0..10000'', the data type
> of vel and ve2 becomes as float64. 
> ccplot -x 500..1000 -y 0..10000 -c cloudsat-reflectivity.cmap  -o cloudsat-reflec.png cloudsat-reflec  2009037050924_14779_CS_2B-GEOPROF_GRANULE_P_R04_E02.hdf  
> 
> print(ve1.dtype)    ----> float64
> print(ve2.dtype)    ----> float64
>  
>           As mentioned above, the data type of vel and ve2 changes with
> the ccplot command with different parameters. Can we fix the data type
> of vel and ve2 at the beginning of the ccplot file.
>  
>                    Yin 
>  
>  
> ------------------------------------------------------------------------
> yinjinfang88
>  
> *From:* Peter Kuma <mailto:pet...@wa...>
> *Date:* 2013-05-28 04:29
> *To:* yinjinfang88 <mailto:yin...@16...>
> *CC:* ccplot-general <mailto:ccp...@li...>
> *Subject:* Re: ccplot errors
> Hi Yin,
>  
> Thank you for doing additional testing. That is a rather perplexing bug.
> It is actually caused by a change in behaviour between numpy 1.6.2 and
> 1.7.1.
>  
> python
> Python 2.7.3 (default, Jan  2 2013, 13:56:14)
> [GCC 4.7.2] on linux2
>>>> import numpy as np
>>>> np.__version__
> '1.6.2'
>>>> x, y = np.meshgrid(np.arange(0, 2, dtype=np.int16), np.arange(3, 5,
> dtype=np.float32))
>>>> print x.dtype, y.dtype
> int16 float32
>  
> vs.
>  
> python
> Python 2.7.3 (default, Jan  2 2013, 13:56:14)
> [GCC 4.7.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import numpy as np
>>>> np.__version__
> '1.7.1'
>>>> x, y = np.meshgrid(np.arange(0, 2, dtype=np.int16), np.arange(3, 5,
> dtype=np.float32))
>>>> print x.dtype, y.dtype
> int64 float64
>  
> The newer version does upcasting to 64 bits. I'm not sure if this is the
> intended behaviour, perhaps a bug report should be filed against numpy.
>  
> In any case, this can be worked around by casting X, Y explicitly. I
> think your fix is essentially good, although I'd prefer casting with
> astype, as it creates contiguous arrays.
>  
> Attached is a patch. Please let me know if it works for you.
>  
> You are most welcome to modify the source code of ccplot, it is open
> source software, it makes me happy to see contributions and bug reports
> from other people.
>  
> I'll answer your other question about cloud mask soon.
>  
> Btw. there is a new program in the making that is supposed to complement
> ccplot in browsing larger amount of granules. It is a web app, with
> server-side importing of granules.
>  
> https://github.com/peterkuma/ccbrowse
> browse.ccplot.org (demo example, please open in recent firefox or chrome)
>  
> Support for CloudSat is kind of secondary at the moment, as it requires
> CALIPSO granule to be imported first, so that relative time shift can be
> calculated correctly. It can be installed and used locally as well.
>  
> Regards,
>  
> Peter