Date: Wed, 05 Jun 2013 15:39:31 -1000
From: Glen Petitpas 
To: Ken Young 
Cc: "Marrone, Daniel P - (dmarrone)" , Jun-Hui Zhao ,
     Glen Petitpas , "cqi@cfa.harvard.edu" 
Subject: Re: track with crate loss


Hi

I am so used to getting spontaneous newFiles when there are correlator 
problems, I am not used to seeing such serious problems *without* a 
newFile happening at some point.

I am fine with restartCorrelator (and perhaps even dopplerTrack) being 
modified to newFile if things are different. We've had similar problems 
loading data recently with different tunings in the same file as well.

Cheers
Glen

On 06/05/2013 03:35 PM, Ken Young wrote:
> On Wed, 5 Jun 2013, Marrone, Daniel P - (dmarrone) wrote:
>
>> Hi Taco,
>>
>> I had hoped that it would be less work than that somehow.
>> The MIR reading did work, it claimed to have to fix something about
>> 4-7, as I noted in my email to Charlie. So perhaps there was some ill
>> effect of having to restart the correlator with fewer crates.
>
> Yes, I'm virtually certain the issue was restarting the track with a
> different number of chunks.     I'm not trying to blow off this problem;
> if reading via MIR doesn't fix it, I'm certainly willing to spend a day
> (or two) to write some special purpose code to recover the track.   Let
> me know if you can't process it via MIR.
>
> I guess what I need to do is modify the restartCorrelator command so that
> it checks the requested configuration against the current configuration,
> and if they differ it should issue an automatic newFile to prevent one
> file from having more than one correlator configuration.   Does anyone see
> a problem with this "fix"?
>
> Taco