[webservices] dataselect wrong data returned to multithreaded client

[Bruce Weertman]

Anthony:

Thanks for pointing out the problem with the incorrect component incident angles.

This problem was caused by a typo in the source code for the ws-tracedsp webservice. 
Buried in the code, "depth" was being used instead of "dip" !

Sorry about that. 

The problem has been fixed in the new version of ws-tracedsp (1.4.5) which is now in production.
This in turn fixes the problem win ws-timeseries.

There is no reason to believe that this issues is related to the problem that Philip Crotwell reported (see below).

Please note:  cached data on our side may continue to report incorrect values for the hour until the cache is flushed out.

Cheers,

Bruce Weertman
 
--------------------------------------
Software Engineer
IRIS DMC
1408 NE 45h St, Suite 201
Seattle, WA 98105

bruce at iris.washington.edu
(206) 547-0393


On Jul 17, 2012, at 12:51 AM, Anthony Lomax wrote:

> Hi all,
> 
> I see a possibly related problem with channel inclination.  The following request should return a BHZ channel, but the component inclination in the sac header is 90.0 - my understanding from the SAC manual is that this should be 0.0 for Z component UP:
> 
> CMPINC     F     Component incident angle (degrees from vertical).
> 
> http://www.iris.edu/ws/timeseries/query?net=IU&sta=MAKZ&loc=00&cha=BHZ&start=2012-07-17T07:28:26.02&dur=844&output=sacbl
> 
> Part of the sac header.
> 
> CMPAZ = 0.0
> CMPINC = 90.0
> KSTNM = MAKZ
> KCMPNM = BHZ
> KNETWK = IU
> 
> Thanks,
> 
> Anthony
> 
> 
> On 2012/07/16 22:29, Philip Crotwell wrote:
>> Hi
>> 
>> I have been doing some tests with the dataselect web service from a
>> multithreaded client (SOD) and found that occasionally I would get
>> data records back in one thread that were not the channel asked for.
>> Luckily I had a check in place from some earlier issues that compared
>> the channel codes in the request with those in the result. Here is an
>> example. It appears that the thread that requested data from BORG got
>> data from ARU.
>> 
>> 
>> 2012-07-16 15:51:26,794 - Channel id in returned seismogram doesn not
>> match channelid in request.
>> req=II.1986-01-01T00:00:00.000GMT.BORG.00.BHZ.2003-08-29T00:00:00.000GMT
>> seis=II.1986-01-01T00:00:00.000GMT.ARU.00.BHZ.2003-08-29T00:00:00.000GMT
>> 
>> The request, if it helps, was
>> net=II&sta=BORG&loc=00&cha=BHZ&start=2009-05-16T01:08:44&end=2009-05-16T01:26:26
>> 
>> This is a bit scary as I suspect many clients do not check the
>> returned data to make sure it actually corresponds to their original
>> request. I have not seen this with a single threaded client, so
>> perhaps that is a clue.
>> 
>> I will try to do some more testing and see if I can provide any more details.
>> 
>> thanks,
>> Philip
>> _______________________________________________
>> webservices mailing list
>> 
>> webservices at iris.washington.edu
>> http://www.iris.washington.edu/mailman/listinfo/webservices
>> 
>> 
>> 
> 
> -- 
> Sent from my iClayTablet 
> 
> 
>    Anthony Lomax 
>    161 Allée du Micocoulier, 06370 Mouans-Sartoux, France 
>    tel: +33 (0)4 93 75 25 02    e-mail: anthony at alomax.net    web: http://www.alomax.net 
> 
>    Science & Special Topics: http://www.alomax.net/science 
>    ALomax Scientific: http://www.alomax.net/alss 
> 
> 
> _______________________________________________
> webservices mailing list
> webservices at iris.washington.edu
> http://www.iris.washington.edu/mailman/listinfo/webservices