LCIO events have int parameters with keys svt_bias_good,
svt_position_good, svt_burstmode_noise_good - 0 if the event is bad (bias
off, SVT not at the position defined for the run, noisy event), 1 if the
event is good.
This sample code should work (I haven't run this, it may not work):
int[] biasFlag = event.getIntegerParameters().get("svt_bias_good")
if (biasFlag==null) System.out.println("no bias flag available, this
should not happen");
else System.out.println("flag value is "+biasFlag[0]);
Something similar should work for the LCIO C++ API. I don't know if these
flags have made it into the DST yet.
On Mon, 31 Aug 2015, Nathan Baltzell wrote:
> I submitted a second test pass with 8GB limit on job size (won?t be
> finished for at least 12 hours):
>
> /work/hallb/hps/data/engrun2015/tpass2.1
>
>
> Also, there was a pass2 question raised again whether there is flag
> in each event to tell if SVT bias/position is correct?
>
>
>
> On Aug 31, 2015, at 10:48, Nathan Baltzell <[log in to unmask]> wrote:
>
>> These farm jobs had a disk usage limit of 5 GB set in their xml submission file (same as pass1).
>> I can raise it and see what happens.
>>
>>
>>
>> On Aug 31, 2015, at 10:27, Maurik Holtrop <[log in to unmask]> wrote:
>>
>>> Hi Matt,
>>>
>>> I agree with Stepan that *eventually* we will need to pair down the amount of information in the output quite significantly, but for the pass2 trial this is less important.
>>>
>>> Until we figure out what it is we really want to keep in the output, you could split the job into two smaller ones, so we end up with a 0a and 0b file, etc.
>>>
>>> For paring down the output, we should also consider cutting events, not only the information in the events. I suspect we take a lot of events that aren?t all that useful.
>>>
>>> Best,
>>> Maurik
>>>
>>>
>>>> On Aug 31, 2015, at 9:42 AM, Graham, Mathew Thomas <[log in to unmask]> wrote:
>>>>
>>>>
>>>> Well, it looks like the jobs failed around event ~225000 (so, almost made it through) with "Caused by: java.io.IOException: File too large??they are ~5GB, so I guess that?s the ulimit. I guess we?re adding too much stuff?more track types (+associated recon particles) and the GBL output. We could ask to have the file size limit increased or start paring down our recon files, either by cutting out information or events. Thoughts?
>>>>
>>>>> On Aug 29, 2015, at 6:57 PM, Nathan Baltzell <[log in to unmask]> wrote:
>>>>>
>>>>> FYI, here is a test pass on run 5772 with current trunk in preparation for pass2:
>>>>>
>>>>> /work/hallb/hps/data/engrun2015/tpass2
>>>>>
>>>>> Everyone should run their code on it to check for problems.
>>>>>
>>>>> -Nathan
>>>>>
>>>>> ########################################################################
>>>>> Use REPLY-ALL to reply to list
>>>>>
>>>>> To unsubscribe from the HPS-SOFTWARE list, click the following link:
>>>>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
>>>>
>>>>
>>>> ########################################################################
>>>> Use REPLY-ALL to reply to list
>>>>
>>>> To unsubscribe from the HPS-SOFTWARE list, click the following link:
>>>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
>>>
>>
>> ########################################################################
>> Use REPLY-ALL to reply to list
>>
>> To unsubscribe from the HPS-SOFTWARE list, click the following link:
>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
>
> ########################################################################
> Use REPLY-ALL to reply to list
>
> To unsubscribe from the HPS-SOFTWARE list, click the following link:
> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
>
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the HPS-SOFTWARE list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=HPS-SOFTWARE&A=1
