[data-issues] Re: LB.TPH bad compression in pond

[Philip Crotwell]

Hi Rob

Looks like this is another one that slipped passed. I presume this is  
either the same issue as US recompression or something similar. At  
any rate, LB.DAC claims to be stiem2 in the pond but isn't.

thanks,
Philip

Event: New Ireland Region, P.N.G. | 11/16/2000 07:45:32 GMT | Mag:  
6.5 | Depth 33.00 km | (-4.827, 153.226) LB. 
19961223T00:00:00.000Z.DAC.  .BHZ.19961223T00:00:00.000Z , LB. 
19961223T00:00:00.000Z.DAC.  .BHN.19961223T00:00:00.000Z , LB. 
19961223T00:00:00.000Z.DAC.  .BHE.19961223T00:00:00.000Z ,  Processor  
had a system failure
edu.iris.Fissures.FissuresException: IDL:iris.edu/Fissures/ 
FissuresException:1.0 Codec Exception: encoded data length is not  
multiple of 64 bytes (4048)


On May 22, 2006, at 10:26 AM, Philip Crotwell wrote:

>
> Hi
>
> It looks like LB.TPH might also be suffering from the same issue as  
> US, where the data in the POND is not compressed with the same  
> algorithm as is listed in the database. I am guessing this as  
> earlier LB data seems to be in USNSN compression. Is it being  
> recompressed in the same manner as US data?
>
> Several other LB stations seem to be effected in the same way as  
> TPH: DAC, BMN, LDS.
>
> thanks,
> Philip
>
> Event: East Of Kuril Islands | 02/21/1997 23:40:24 GMT | Mag: 6.1 |  
> Depth 33.00 km | (43.829, 149.167) LB. 
> 19961223T00:00:00.000Z.DAC.  .BHZ.19961223T00:00:00.000Z Data  
> retrieval in progress
> edu.iris.dmc.seedcodec.SteimException: encoded data length is not  
> multiple of 64 bytes (4048)
>
> Event: Kyushu, Japan | 12/16/1998 00:18:45 GMT | Mag: 5.5 | Depth  
> 42.00 km | (31.287, 131.286) LB.19961223T00:00:00.000Z.TPH.  .BHE. 
> 19961223T00:00:00.000Z Data retrieval in progress
> edu.iris.Fissures.FissuresException: IDL:iris.edu/Fissures/ 
> FissuresException:1.0 Codec Exception: encoded data length is not  
> multiple of 64 bytes (4048)
>
>