The flags are just read from a set of maps stored in the event header which is added during the evio2lcio conversion.

Would be easy to debug this hypothesis about the flags…

if (flag == null || flag[0] == 0) {
    LOGGER.info(“Flag “ + flagName + “ is null or set to 0.”);
    skipEvent();
}

If it is skipping that many events then I would guess you are correct that the flag is set to 0 (or not set though this seems unlikely).

Perhaps the tracking needs some “max iteration” settings in several places after which it will break out of combinatoric loops.  Certainly 3000+ raw hits cannot be handled correctly in our current algorithm (and probably the event is bad anyways).  

On Dec 7, 2017, at 1:37 PM, Maurik Holtrop <[log in to unmask]> wrote:

Hi Y’all,

I am trying to debug what is going on with at least one of the events that Rafo indicated is hanging up recon. I am finding this perhaps harder than it needs to be by getting a little lost in the code.

I am looking at the evio file: hps_005783.evio.105, which I filter with eviocopy, a very low level evio utility that simply copies events from the input file to the output file, skipping an indicated number of events. 

I created two filtered file. In file A, I skip to event 27207410, and then write out 200 events.
In file B, I skip to 27207411, so one event later, and write out 199 events.

Here is the issue:

When reading file A, or any file that starts with an event earlier, the code immediately reads events and processes them. Putting debug statements in RawTrackerHitFitter shows that raw events are read and processed, and for the first 6 events around 50 to 200 hits are processed. All looks normal. Then we get to event 27207416, which has  Rawhits: 3352  processed hits: 3617, and by the time recon tries the combinatorics on this it gets itself all tangled up in a mess and never exits.

When reading file B, which starts ONE EVENT LATER, all the events are skipped until 27207419, so the problem event is simply skipped. Running this through the debugger, I find that the “svt_bias_good” flag is not set, or is it?

The bit of code that checks for this is the “EventFlagFilter.java”:

package org.hps.recon.filtering;

import org.lcsim.event.EventHeader;

/**
 * Accept only events where all of the specified flags exist and have a value of
 * 1.
 *
 * @author Sho Uemura <meeg@slac.stanford.edu>
 * @version $Id: $
 */
public class EventFlagFilter extends EventReconFilter {

    String[] flagNames = {"svt_bias_good", "svt_position_good", "svt_burstmode_noise_good", "svt_event_header_good", "svt_latency_good"};

    public void setFlagNames(String[] flagNames) {
        this.flagNames = flagNames;
    }

    @Override
    public void process(EventHeader event) {
        incrementEventProcessed();
        if (flagNames != null) {
            for (String flagName : flagNames) {
                int[] flag = event.getIntegerParameters().get(flagName);
                if (flag == null || flag[0] == 0) {
                    skipEvent();
                }
            }
        }
        incrementEventPassed();
    }
}


I do not understand how it gets the relevant information from the EventHeader object, since this is just an interface. 

My Java skills stop there. 

Please help.

Thanks,
Maurik
 



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