For ease of experimenting I extracted some sample data from the DC1 tuple into a simple binary file. The file contains 922782 events, with 4 floats, for time, energy, ascension and declination for each event.

The file can be found on SLAC Unix in ~tonyj/work/glast/glast.dat

It can be read with the attached Java file.

As a sanity check I wrote the world's dumbest analysis program, which simply memory maps the data file, loops over all the data, and applies some simple cuts. No indexing, no bining, no smarts. On my 2Ghz amd64 linux machine it took 149ms to analyze the data file.

Main.java
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.nio.ByteBuffer;
import java.nio.ByteOrder;
import java.nio.FloatBuffer;
import java.nio.channels.FileChannel;
import java.nio.channels.FileChannel.MapMode;

/**
 *
 * @author tonyj
 */
public class Main
{
   public static void main(String[] args) throws IOException
   {
      File file = new File(args[0]);
      FileInputStream in = new FileInputStream(file);
      FileChannel channel = in.getChannel();
      ByteBuffer buffer = channel.map(MapMode.READ_ONLY,0,file.length());
      buffer.order(ByteOrder.BIG_ENDIAN);
      final int size = buffer.getInt();
      FloatBuffer floats = buffer.asFloatBuffer();
      
      int nAccept = 0;
      float eCut = (float) Math.exp(4);
      long start = System.currentTimeMillis();
      for (int i=0; i<4*size; i += 4)
      {
         float time = floats.get(i);
         if (time < 20000 || time > 70000) continue;
         float energy = floats.get(i+1);
         if (energy < eCut) continue;
         float rightAscension = floats.get(i+2);
         float declination = floats.get(i+3);
         float dRA = rightAscension-180;
         float dDec = declination-0;
         if (dRA*dRA + dDec*dDec > 15*15) continue;
         nAccept++;
         //System.out.printf("%g %g %g %g\n",time,energy,dRA,dDec);
      }
      long stop = System.currentTimeMillis();
      System.out.println("Elapsed "+(stop-start)+"ms");
      System.out.println("Accepted "+nAccept+"/"+size);
      in.close();
      
   }
   
}

Elapsed 149ms
Accepted 2716/922782

Analysis program and plots are attached.

  • No labels

4 Comments

  1. Tom Stephens

    As you get further into your testing remember that time needs to be a double not a float to maintain the precision requirements we have.

    1. Tony Johnson

      Good point, thanks for pointing it out. BTW is there a good reason we are using a double rather than a long for the time measurement? I don't know what the intrinsic resolution of the detector is, but you can easily store ns reolution in a long and still have it span far longer than the lifetime of Glast, or any of the Glast collaborators for that matter.

  2. Tom Stephens

    I assume by long you mean an integer variable and not a shorter floating point variable type. The reason is our precision requirements. We always need to maintain times to microsecond precision and time is in seconds so we must use a floating point value not an integer. The reason for double over float is the length of the mission. With an expected 10 year mission, the integer seconds of the Mission Elapsed Time (MET) kept in the TIME column amounts to 9 digits (after about 3.2 years) plus 6 decimal places for the precision requirments gives a requrirement of 15 significant digits in the data format which I don't think you can achieve with a float so a double is needed.

    1. Tony Johnson

      Yes, by long I meant a 64 bit integer. So I guess my question is simply why store the time as a real number of seconds rather than an integer number of micro or nano seconds? In HEP we would normally do the latter, since integers are generally easier to deal with, but maybe in the astrophysics community people are more used to seconds?