Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GRIFFIN Data Format Output #78

Open
r3dunlop opened this issue Mar 21, 2014 · 23 comments
Open

GRIFFIN Data Format Output #78

r3dunlop opened this issue Mar 21, 2014 · 23 comments

Comments

@r3dunlop
Copy link
Member

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

@bkatiemills
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member

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
Copy link
Member Author

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
Copy link
Contributor

carlu commented Mar 21, 2014

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 [email protected] 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//issues/78#issuecomment-38325858
.

@bkatiemills
Copy link
Member

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
Copy link
Contributor

carlu commented Mar 22, 2014

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 [email protected] 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//issues/78#issuecomment-38336388
.

@moukaddam
Copy link

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
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member Author

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
Copy link
Member

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
Copy link

ok, a documentation will follow

@moukaddam
Copy link

@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
Copy link
Member Author

@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
Copy link
Member

This is great work guys, keep it up!

@moukaddam
Copy link

@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 :

  • Declare the root class in the CMakeLists.txt on top (Add a newline)
  • Update the CMakeLists.txt accordingly
  • The files corresponding to the user-writing-class goes in the folder dataRootClass/
  • Update the linkdef.h file to include the new class
  • Change the Makefile in dataRootClass/ to compile the new files, 'make clean' and 'make' to create the libraries
  • Finally, in ./src/RootManager.hh, add the header of the new class and use it

#include "RawG4Event.hh"
#include "relative/path/to/dataRootClass/TSpiceData.h"

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

@r3dunlop
Copy link
Member Author

@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
Copy link

@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
Copy link
Member Author

@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
Copy link
Member Author

@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
Copy link

@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
Copy link
Member Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants