[Clas_cascades] st offset in ffread

Paul Mattione pmatt at jlab.org
Thu Apr 8 10:09:14 EDT 2010


The STZOFF below is wrong, it should be -41.0.  I didn't realize it at  
the time, but since the start counter was shifted forward by 9 cm for  
the eg3 experiment (from it's typical position), it needs to be  
-41.0.  Most other experiments the STZOFF will be at the target center.

  - Paul

On Apr 8, 2010, at 9:09 AM, Hovanes Egiyan wrote:

Hi Zhiwen,

the correct variable is CLAS_CALDB_RUNINDEX, try that one.

The GSIM keys you are quoting in your last e-mail are most likely
to produce a wrong target area configuration for eg3. I think they  
will produce
g11 configuration with the whole target assembly center shifted in Z,  
and
will not take into account the differences within the target area.

Hovanes.


Zhiwen Zhao wrote:
> Hi, Paul
>
> I dig out an old email ( see bottom), in which you suggest it should  
> be
> ***********************************
> TGPOS 0.0 0.0 0.0    #IT MUST BE THIS!!!!! (real target position  
> read from caldb)
> STZOFF -50.0
> ***********************************
>
> I am looking into this because I have some timing problem for my  
> simulation
> Particle vertex position and timing all look fine
> But to match particle vertex time calculated by TOF, the event  
> starttime has to be about -56/c_light, while the target center is at  
> -50
>
> I am wondering if it can caused by two things:
> 1. the setting in GSIM as we discussed
> 2. The use of right runindex
>
> For 2, eg3 should use calib_user.RunIndexEG3Sim for gsim and gpp and  
> user_ana
> I tried "setenv CALDB_RUNINDEX calib_user.RunIndexEG3Sim", but it  
> doesn't make it happen, they are still use RunIndex
> Any idea?
>
> Thanks
>
> Zhiwen
>
>
> On 4/7/2010 11:08 AM, Paul Mattione wrote:
>
>> It is correct.  For some reason gsim doesn't want/need the  
>> additional 4.06 cm offset that caldb has.  Maybe it already takes  
>> it into account.  Both g11 and g13 are doing it that way and it  
>> works fine.
>>
>> - Paul
>>
>> On Apr 7, 2010, at 4:06 AM, Zhiwen Zhao wrote:
>>
>> Dear Eg3er
>>
>> I notice that the st offset in CALDB is -45.06
>> But it's -41 in our general ffread file, eg.
>> http://clasweb.jlab.org/rungroups/eg3/wiki/index.php/Ffread_file_for_xi-pi-
>> Is that a mistake or something else?
>>
>> Thanks
>>
>> Zhiwen
>> _______________________________________________
>> Clas_cascades mailing list
>> Clas_cascades at jlab.org
>> https://mailman.jlab.org/mailman/listinfo/clas_cascades
>>
>>
> ================old  
> email===============================================
> I'm pretty sure the difference is automatically accounted for: i.e.  
> gsim ALREADY automatically shifts it by that amount, so if you set  
> STZOFF to -45.06 it'll shift it twice (to -40.12) and it'll be  
> messed up.  I got this understanding from Pawel who got it from  
> Franz so I'm pretty sure it's correct, but feel free to ask others.
>
>  - Paul
>
> On Apr 21, 2008, at 12:52 PM, Zhiwen Zhao wrote:
>
> hi, Paul
>
> Where do you get the STZOFF -50.0?
> It's currently -45.06 in database.
>
> Best Regards
>
>
>             Zhiwen Zhao
>
>
> Paul Mattione wrote:
> No, I adjusted for eg3.
> - Paul
> On Apr 18, 2008, at 5:27 PM, Zhiwen Zhao wrote:
> Thanks Paul
> But those values you mentioned are for g13, not eg3, right?
> Best Regards
>            Zhiwen Zhao
> Paul Mattione wrote:
> Some ST/Target info is read from your ffread & tcl files, some from  
> the runindex.  You need to make sure that the target & st positions  
> in the caldb are the correct values for eg3 in runs 1->10.
> In ffread card for gsim:
> TGPOS 0.0 0.0 0.0    #IT MUST BE THIS!!!!! (real target position  
> read from caldb)
> STZOFF -50.0
> In tcl file for user_ana:
> set TargetPos(3) -50.0;
> set TargetLen 40.0;
> #ST INFO GRABBED FROM caldb!!!!!
> I had to sort through all this crap for g13.  I hope this helps.
> - Paul
> On Apr 18, 2008, at 1:22 PM, Zhiwen Zhao wrote:
> Hi, Hovanes
> If in one's analysis code only eloss is related to reading constants  
> CALDB, it will be ok if just let eloss called with any real run  
> number in eg3 run period with main Runindex because the target and  
> St parameters were unchanged for the whole eg3 run period.
> This applies to real data and simulated data.
> In this case, runindexeg3a wouldn't be needed.
> Please let me know if my understanding is right.
> 1. GSIM need the ST parameters in ffread card, not in CALDB
> 2. cooking need the ST parameters in CALDB, not in the tcl file.
> So if use main Runindex to cook simulated data, the ST bank won't be  
> built correctly?
> Thanks
> Best Regards
>          Zhiwen Zhao
> Hovanes Egiyan wrote:
> Hi Zhiwen,
> I looked at your web page.
> The DB entries were copied to runindexeg3a to be able to run private  
> analysis
> codes requiring eloss corrections.  The target and ST parameters are  
> important
> for eloss. Cooking and GSIM should be run with the main  runindex  
> table.  The
> target and ST parameters in GSIM are supposed to be set in FFREAD  
> card.
> The only possible issue is the ST reconstruction of the GSIM data  
> (which I personally
> do not use).  The entries in the main runindex for ST for run 10  
> will not be
> correct.    I think we should create a runindex with a complete set  
> of tables
> of main runindex, but change the ones that are red and related to  
> the target and
> the start counters for run 10.
> I was out of town, I do not know what exactly was discussed.
> eloss is not applied  in  cooking, the momenta from cooked files
> should be corrected for the energy loss and momenta.
> Hovanes.
> Zhiwen Zhao wrote:
> hi, Hovanes
>
> We had a discussion about if eloss has been implemented in the  
> cooking code or cooking procedure.
> Can you clarify that?
>
> Thanks
>
> Best Regards
>
>
>         Zhiwen Zhao
>
> ================old  
> email===============================================
> _______________________________________________
> Clas_cascades mailing list
> Clas_cascades at jlab.org
> https://mailman.jlab.org/mailman/listinfo/clas_cascades
>




More information about the Clas_cascades mailing list