Closed TarekHC closed 6 years ago
Hi @TarekHC
This should be rather straight forward to do. What I have in mind is to write a generic data source class with method of getting event tree, EA and header info ...etc. And we can make subclass for VEGAS and ED separately so that the vegas/ED library are only loaded on initialization of such objects.
I will spend some time on this over the next few days to get a rough version out. We can make necessary modifications to the interface depends on what the ED data requires later.
That sounds perfect. Sorry to add the extra complication!
I'm slowly understanding the h̶o̶r̶r̶i̶b̶l̶e̶ way eventDisplay stores IRFs... Ufff...
Incidentally, now that we are discussing ED.
If my understanding is correct (I've been using v480 up till now so this might be out dated), there's no equivalent of stage5 data files ( post gamma-hadron cut events but before theta2 cuts) stored in the ED output files.
What's the file that the converter is going to read from ? If it's mscw file then we need to write some code to do cuts that is consistent with ED ....
If my understanding is correct (I've been using v480 up till now so this might be out dated), there's no equivalent of stage5 data files ( post gamma-hadron cut events but before theta2 cuts) stored in the ED output files.
I believe anasum files do contain gamma-like events before theta2 cut. I'm 100% sure ED v500 does, and 80% sure ED v480e does... (maybe 50%...)
I think you are right ... Sorry for the confusion ... I was thinking about running simulation files through anasum (which doesn't really work for 480...) .
Given the way this code has developed it should be doable and I think it is worth the effort to get everything into one place. @tony32lin if you have a plan in mind that is great. I should be able to get a bit of time for this next week (writing talks for COSPAR and catching up after vacation this week so slightly distracted).
@TarekHC I've pushed the changes to isolate VEGAS from the DL3 writing. You can give it a try now. With the flag --ed, the command line tool will give you an Exception saying that ED mode hasn't been implemented and should not be complaining about VEGAS at all. This is the desired behaviour as the top level modules does not require either VEGAS to be imported (just stay away from stuff inside vegas folder and you will be safe).
The command line tool might need some overhaul now that we need to accommodate ED mode. It starts to look a little messy.
Awesome, thanks! I will try to play around with it a bit!
Hi @ralphbird @tony32lin
I'm not sure if the scope is still to use the same exporter for VEGAS and ED. But looking a bit into the code, I believe I'm finding in many places calls to the VEGAS libraries.
Would it be possible to put all VEGAS specific methods within the VEGAS folder, and separate the pertinent data ROOT->python extraction from the python -> DL3?
If that is way too complicated, would it at least be possinble to have a global option for exporting VEGAS data, that allows me to run the code without VEGAS? (so VEGAS imports will only be executed if you want to export VEGAS files... Same with ED).
Again, this will require re-organization which equals work, so if it is a hassle, I'll just duplicate the repo. Although it probably makes no sense to duplicate the DL3 formatting step (as it would require double maintenance).
Thanks!