search

GRIFFINCollaboration / detectorSimulations

GEANT4 simulation code for the GRIFFIN array and it's suite of ancillary detection systems.
7 stars 13 forks source link

GRIFFIN Data Format Output #78

Open r3dunlop opened 10 years ago

r3dunlop commented 10 years ago

Adding the ability to output .mid files which follow the GRIFFIN data format specification.

bkatiemills commented 10 years ago

Awesome. Actually, #66 is relevant to this, too (a lot of stuff went down in that thread...) - @moukaddam and @evitts have recently merged the beginnings of our infrastructure for implementing data-like root tree outputs in the same format as what our sort code will chew raw data into (in other words, exactly what we want). Implementing the relevant classes for GRIFFIN would be a huge step forward and satisfy this long standing goal. The SPICE team cc'ed above are the experts in this, and I know @evan012345 was involved in that discussion as well. This is a very opportune time to do this, since the analogous thing is happening on the sort code side as well right now.

Try and have a look at the recent SPICE classes to understand them, and see if we can do the same for GRIFFIN.

r3dunlop commented 10 years ago

I was under the impression that for GRIFFIN we wanted to first output raw data (not the root trees) in order to test the sort code and have direct comparisons to experiment. I would assume this is the priority, with the next step being the ability to write root trees containing more information for a more thorough understanding of a simulated experiment.

bkatiemills commented 10 years ago

So, you're right, originally we wanted simulations to run the sort code on - but it turns out the DAQ people beat you to it! I was informed just this week that they've got a hardware chain up and running that will spit out raw GRIFFIN-style data we can hand to the sort code team. Therefore, we have to re-evaluate if this is the best use of your time, or if we're just reproducing effort.

Ultimately we will want to validate the physics results of the simulation, and that'll be done at the tree level rather than the raw level - it has to be. I think implementing the GRIFFIN classes (or classes for any other detector you're interested in) analogous to the SPICE classes would be the best use of your time; getting them off the ground is a first-tier priority for this project right now. @moukaddam and @carlu, you guys currently have point on simulation tree classes and validation exercises respectively, feel free to weigh in on what you think is most useful here: simulations producing raw data format, or GRSISPOON-style trees. I say trees, but we should all discuss this before @r3dunlop charges in here.

r3dunlop commented 10 years ago

Ok, that sounds good then. We can always add raw-level data later as I don't believe it will be much work once the GRIFFIN data stream is organized. I'll just piggy-back on what has been done with SPICE.

carlu commented 10 years ago

I personally don't see a major advantage to producing simulated raw data over going directly to a simulated tree. I can't think of any problems we could induce which would be revealed by sorting simulated raw data, but would not be revealed by comparing simulated and experimental fragment trees.

That said, my imagination is limited. I can;t remember now who really wanted the simulated raw data, possibly Greg.

Carl

On 21 March 2014 14:25, Ryan Dunlop notifications@github.com wrote:

Ok, that sounds good then. We can always add raw-level data later as I don't believe it will be much work once the GRIFFIN data stream is organized. I'll just piggy-back on what has been done with SPICE.

Reply to this email directly or view it on GitHubhttps://github.com/GRIFFINCollaboration/detectorSimulations/issues/78#issuecomment-38325858 .

bkatiemills commented 10 years ago

Did Greg ask for it? I made a lot of noises about it to satisfy Peter's demands for a raw GRIFFIN file to test on so he could develop the GRIFFIN preprocessor, but maybe there were other takers - I'll ask him next time I run into him.

carlu commented 10 years ago

Well ok, to be clear, I remember Greg suggesting some time ago (~1 year) that we generate raw TIGRESS format data from the TIGRESS simulation. This was at the time when Greg, Peter and I were starting to talk about the plan for the sort code which eventually became GRSISpoon.

I'm not sure if he is still thinking that way or if he's even given any consideration to the GRIFFIN case.

Maybe we need to ask people what they hope to accomplish by using the simulated raw data? And then decide what we do based on how important those jobs are and whether we can do them using only the simulated frag tree?

On 21 March 2014 16:55, Bill Mills notifications@github.com wrote:

Did Greg ask for it? I made a lot of noises about it to satisfy Peter's demands for a raw GRIFFIN file to test on so he could develop the GRIFFIN preprocessor, but maybe there were other takers - I'll ask him next time I run into him.

Reply to this email directly or view it on GitHubhttps://github.com/GRIFFINCollaboration/detectorSimulations/issues/78#issuecomment-38336388 .

moukaddam commented 10 years ago

Unless we want to test the parser from Midas to Root (The parsing is straight forward as far as I know), there's no use of simulating Midas files in my opinion.

On the other hand a fragmentTree could be used to make sure there's no bug in the final sorting code. (In this case the mapping of each segment in the simulation should be exactly the same as in the experiment, it's not necessary the case). However I agree with Carl, it will not offer any other "physics" advantage that I can think of right now.

Implementing a fragmentTree should not be so hard now that everything from MIDAS has the same format when converted to root. We could re-use the "TTigFragment" class with Geant to produce theses trees.

bkatiemills commented 10 years ago

I agree. @carlu, I'll certainly put raw format outputs on the docket if someone asks for them, but we don't have the bandwidth to do it just for yucks, we're understaffed as it is.

@r3dunlop, let us know how it goes doing for GRIFFIN what's been done for SPICE - if anything is mysterious please let us know; not only would I want to get you unstuck, but that will also be a good indication of where the code is difficult to understand. As you figure out the process to do this, please use a README.md file as your lab book - your goal will be to make a point form, step-by-step description of how you did this for GRIFFIN, to jumpstart the next person who has to do this for the other detectors. @moukaddam, if we really can just reuse the TTigFragment class as-is, point it out to @r3dunlop and get him started there.

r3dunlop commented 10 years ago

So I'm in the process of adding another ROOT Class for GRIFFIN. Is this what we want to do? Make multiple classes? I'm not very familiar with ROOT so I don't know what base we should start with to reach our end goals (Coincidences, etc.) Any thoughts that @BillMills @evan012345 @moukaddam has would be welcome!

r3dunlop commented 10 years ago

For example, I'm doing:

    //spice event
fSpiceData = new TSpiceData();

//GRIFFIN event
fGriffinData = new TGriffinData();

and I assume that will all go into one tree eventually via: 

fOutputTree = new TTree("Simulated_Data","Simulated Data Tree");

Is this what we are trying to do?

bkatiemills commented 10 years ago

Adding a ROOT class for GRIFFIN is definitely what we want - @moukaddam and @evitts are the experts in the details of the implementation. Just keep things well separated following the SPICE pattern (ie you'll probably be making a dataRootClass/TGRIFFINData.cpp file encapsulating this analogous to TSpiceData.cpp), push your work to your fork of the repo, and we can all have a look as you proceed if you have any questions or are unsure how to proceed.

I realize this is a pretty nebulous task - that's why it's important as you go along to produce that summary of what you ended up having to do to get this working, so we can move faster on the other dozen or so detection systems this has to be done for. By doing that you are not only implementing things for GRIFFIN, but helping streamline things for the rest of the collaboration. It'll be slow going, but there's no hurry.

@moukaddam and @evitts, it's in your interests to please help @r3dunlop get the documentation for this procedure established - the sooner that exists the sooner we can all stop bugging you and implement your pattern on our own :)

moukaddam commented 10 years ago

ok, a documentation will follow

moukaddam commented 10 years ago

@r3dunlop here's a first draft on the description of each class involved to add a detector in the root tree: https://github.com/GRIFFINCollaboration/detectorSimulations/wiki/Adding-a-new-branch-to-the-root-tree

I have explicitly mentioned where you need to implement the new class, and what is to be updated. Also you will find some hints and comments in the code. I will follow soon with a Diagram, let me know if you have any further question or if something is not clear. I'll updated according to your suggestions.

As @BillMills mentioned earlier, a TGriffinData.cpp(.h) has to be made and compiled in the dataRootClass. So the MakeFile has to be updated in this directory. There's a "slot" ready for the new classes from other detectors. Just replace "myDetector1Data" by "GriffinData" and uncomment. Let me know if you need help.

r3dunlop commented 10 years ago

@moukaddam Thank you very much for the detailed list of classes and methods so that I don't have to spend too much time trying to chase everything down. One thing that is missing from all of this are the changes required to the CMake file to have the multiple root classes compiled. I have not sat down yet to make this work but I will document what I did so that it can be added to the recipe.

bkatiemills commented 10 years ago

This is great work guys, keep it up!

moukaddam commented 10 years ago

@r3dunlop I haven't added another class yet, If you have a simple class for Griffin we can experiment on it. the procedure should'nt be so different than this :

include "RawG4Event.hh"

include "relative/path/to/dataRootClass/TSpiceData.h"

include "relative/path/to/dataRootClass/TNewData.h"

r3dunlop commented 10 years ago

@moukaddam It's the "update the CMakeLists.txt accordingly" part that I'm having trouble with. I have done everything else. It might be my inexperience with CMake, but I'm not finding it straight forward to have CMake deal with both Spice and Griffin.

moukaddam commented 10 years ago

@r3dunlop, I see what you mean, could you push your version to your directory on GitHub, so I can work on it on my machine.

r3dunlop commented 10 years ago

@moukaddam it's kind of a mess right now from experimentation. I'll try to clean it up and get it up there (it's no nicer to work with than the version you already have I'd bet).

r3dunlop commented 10 years ago

@moukaddam I've updated my GitHub directory but it has evidence of various attempts at making this work. Please let me know if you have any questions.

moukaddam commented 10 years ago

@r3dunlop I managed to add an S3 Class. I made some modifications to the CMakeLists, and prepared it for Griffin, you just need to uncomment some blocks. I tried to make it as friendly as possible, the manual to add a new class is in

The main problem was the handling of arguments in cmake. For the dictionaries we had to add them on the same line, if copy-paste is used the latter will replace the former.. Let me know if everything worked well.

r3dunlop commented 10 years ago

Good Stuff! My problem turned out to be the CMake commands linking the dict*.cxx files.