[BLAST_ANAWARE] runs to reconstruct

From: Chris Crawford (chris2@lns.mit.edu)
Date: Mon Mar 31 2003 - 17:14:57 EST


hi everyone,
  here is a list of runs which we should use to test the reconstruction.
 its broken down into golden runs, asymmetry runs with full holding
field, medium holding field, and deuterium runs. ( . indicates bad run
inbetween)

    - golden
      3063 . 3065 3066 3067 3068 . 3070 ... 3074 . 3076 3077 3078 3079
       3080 . 3082 . 3084 3085 3086 3087 3088 3089 . 3091
       3092 3093 3094 3095 3096 3097 3098 . 3100 3101 3102
       3103 3104 3105 3106 3107 . 3109
    - others
      3073
    - full
      3200 . 3202 3203 3204 3205 3206 . 3208 3209 . 3211 3213 3214 3215 .
       3217 .. 3220 3221 3222 3223 . 3225 3226 3227 . 3229 3230 3231 3232
       3233 3234 . 3239 3240 3241 3242 3243 . 3246 3247 3248 3249 3250
       3251 3252 . 3254 3255 . 3257 3258 3259 3260 3261 . 3263 3264 3265
       3266 3267 3268 3269 3270 ... 3274 3275 3276 3277 . 3279 3280 .. 3283
       3284 3285 3286
    - half
       3290 3291 3292 3293 3294 3295 . 3297 3298 3299 3300 3301 3302 3303
        3304 . 3306 3307 3308 3309 3310
    - deut
      3319 3320 3321 3322 . 3324 3325 3326 3327 3328 3329
       3330 3331 3332 3333 . 3335 3336 3337 3338 3339
       3340 . 3341 3342 3343 3344 3345 . 3347 .

--chris

Frederick T. Lee wrote:

>Chris,
>
>Here are the list of golden runs:
>
> 3063, 3065, 3066, 3067, 3068, 3070, 3074, 3076, 3077, 3078,
> 3079, 3080, 3082, 3084, 3085, 3086, 3087, 3088, 3089, 3091,
> 3092, 3093, 3094, 3095, 3096, 3097, 3098, 3100, 3101, 3102,
> 3103, 3104, 3105, 3106, 3107, 3109
>
>I guess we have to meet tomorrow morning.
>
>
>-T
>
>
>zhangchi wrote:
>
>
>
>
>>Hi, all,
>>
>>tommorrow, anytime in the morning on campus is good for me. I have class
>>2:30-4:00. By the way, I will probably not go to the wednesday meeting.
>>
>>Chris, to answer your questions:
>>
>>1st. To implement Tong's key list in a flexible enough manner, I want to
>>do the following change in TBLRecon:
>>
>>There will be a pool of TBLTracks* as an array of size 99 as before. This
>>way, we do not need to create TBLTracks per event.
>>
>>However, the pool will be made private and for any use, the
>>current position of the array will be replaced by a vector<TBLTracks*>,
>>TBLTracks will also remember the key list of the Wc1Track passed to it.
>>
>>This way, a track with larger Chi2 can be easily removed. vector is not
>>really suitable for the purpose but it supports index operation so no
>>other part of programms need to be changed. Shall we agree on using stl
>>more and using iterators, I think a multimap/set would be more appropriate
>>here. But that s for later.
>>
>>The above structure will allow us to: initiate all the Track objects once
>>at the beginning, at the same time allow us to erase bad tracks while the
>>program progresses.
>>
>>I want to ask about you guy's opinion upon the above change.
>>
>>2nd. I am not sure the current codes are robust enough for crunching.
>>Crunching process is somehow sensitive to parameters we supply. For
>>instance, I tried to reduce the max number of hits in a cluster from 20 to
>>15. Naively, I think it should reduce the run time, but it in fact stuch
>>the program. Because it reduced the final number of fast fit. If # of fast
>>fit reduces from above the cut (say 1000) to a little bit below the cut
>>(say 950) then the program will go about to treat the all 950 of them and
>>get stuck.
>>
>>The program can get through 3070 with newton, but hardly anything else. I
>>v beem working on them. I hope by Wednesday, I can run newton through all
>>the good runs.
>>
>>I think Newtoning bad runs does not make much sense.
>>
>>Chi
>>
>>
>
>
>



This archive was generated by hypermail 2.1.2 : Mon Feb 24 2014 - 14:07:29 EST