Thanks Michael. Does that mean these runs we will not be able to recrunch?
In that case I would use the old ntuples to append my list.
Thanks,
n
Michael Kohl wrote:
>Hi Nik,
>
>these runs are part of a re-recrunch list that I am lrd'ing on bud15 and
>bud16, however slow (because of H2 recrunch) and in case of most of the
>runs of this list the crunch job gets stuck (eternal loop) which I only
>recognize after some time.
>
>Regards,
>
> Michael
>
>
>On Sun, 3 Oct 2004, Nikolas Meitanis wrote:
>
>
>
>>Hello,
>>It appears to me that several (if not many) of the D2 runs have not been
>>successfully REcRrrunched. These are runs that didnt succeed in the
>>first iteration of the recrunch last week and had to be crunched again.
>>
>>7898 8494 8565 8570 8865 8916 9155 9287 9554
>>
>>I cannot find a tag for them in the v3_4_1 . Have they been placed
>>anywhere else by any chance?
>>
>>Thanks,
>>n
>>
>>
>>Michael Kohl wrote:
>>
>>
>>
>>>Hello,
>>>
>>>whoever is in charge of maintaining the H2 auto-recruncher:
>>>
>>>>From the logfiles in ~elog/recrunch_log I see that until September 29 the
>>>command "lrn +SQL" was used, correctly implying a query to database for
>>>both calibrations and the correct electronics map. (=runs 6347-6909 =
>>>40runs)
>>>Since September 30 however, the command seems to have been "lrn" only.
>>>Since the default in $BLAST_PARAM/blastrc still is to *not* query the
>>>database for anything, neither the right time offsets nor (even worse) the
>>>right electronics map was used, for 546(!) runs so far ....
>>>
>>>Please correct me if I'm wrong! Otherwise these 546 runs have to be
>>>recrunched again.
>>>
>>>Regards,
>>>
>>> Michael
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
>
This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:31 EST