System : Linux
REST version : v2.2.10
Hi：
l used Decay0 to create the events of double-beta decay of Xe136 to excited states of Ba136. So the generated events in .dat program had both of electron and gamma’s information.
However, the existing restG4 program could just read out the electron,not the gamma.
For example:
Xe136bb0n21+.data is the new .dat program l created. And each event had the information of
two electron and one gamma.
First point : the REST WARNING is probably caused by the + inside your input file generator. Change the name to something different and try. For example : Xe136bb0n21Plus.data.
Second point : The format you generated seems to be not the same as the ones we have under data/generator. See, for example Xe136bb0n.dat.
I imagine, your format is a fixed format generated by the latest version of Decay0?
Third point : Actually, we only read the electron particle id pId=3 from the Decay0 file. However, this is easy to integrate.
Solution : We can upgrade the TRestG4Metadata code to read the format you are providing. If you agree to contribute/upload this data file and an analogue Xe136nldbd.dat to the repository.
If you do so, please, provide any details inside the README file, as how the data was generated, the type of events, the number of events, author, experiment, and/or any information you consider relevant.
Once you upload the file to the repository REST_v2/data/generator/ I will update the TRestG4Metadata code to be able to read the new format.
I imagine to solve this problem by adding a package like “restDecay0”, and cooperate with decay0 library. For example, we define like:
Then TRestParticleSource will call for decay0 event generation during PrimaryGeneratorAction during restG4 run, and generate as many events as we want.
First point:l tried it again and found that we should add the absolute path of .data in the generator and "+"was irrespective.
Second point:Yeah. Accurately, l downloaded and installed the latest version of Decay from github
Third point:Yes. Now the problem is that the program cannot recognize the gamma.
And l have already updated the related .dat file to REST_v2/data/generator/
Thank you for your help!
I have added a patch to v2.2.10_dev so that the new Decay0 file format is accepted by restG4 (See commit : afd30d94). This is just a quick solution. @nkx proposal to integrate Decay0 libraries into restG4 would be much better solution. I add this to the TODO.md list
Only gammas and electrons are recognised in the new format. Time is not considered also.
This implementation is not adding behaviors to libRestMetadata.so. It just adds a library libRestDecay0.so to $REST_PATH/libs, which is called only when decay0 is called. If we remove libRestDecay0.so manually, every thing still work. This is same as AxionLib, isn’t it?
I already added cmake flag in main CMakeLists.txt. Same as before, we can use cmake ${PATH_TO_REST_SOURCE} -DREST_G4=ON -DREST_DECAY0=ON to enable package compiling all in once.
Sure, but it is adding a new functionality to TRestG4Metadata, it adds a new feature, the possibility to use Decay0 inside REST G4 classes. It looks like an option of REST G4 related classes, or what it will be in future included inside libRestG4.so.
Yes, but RestAxionLib is a library, not a package. What it will contain, or contains, libRestDecay0.so? If it is just a class that allows TRestG4Metadata and related G4 classes to integrate Decay0 I would say it can just be put together. Except that you expect it to grow independently in the future.
Package: a small and independent program or project that makes use of REST libraries. But does not add functionality to REST libraries.
REST Library: A set of classes that inherit from TRestEvent, TRestEventProcess and TRestMetadata. And other helper necessary classes in the same context. A library might define a new TRestEvent type, but usually no more than 2 new types.
But we might define a new concept in our development scheme:
Plugin: An optional feature that is added through a cmake option, as for example support for Garfield++ or Decay0, to an existing REST library.
The decay0 functionality is more like a plugin of the future libRestG4 library. Seems more similar to integrating Garfield++into REST Detector libraries.
I agree that plugin is the most accurate word to describe this library. I think TRestGas, restDataBaseImpl, restDecay0 and future’s libRestG4.so shall all be identified as plugin. Then, do we need another directory to keep this kind of libraries/classes? If we just mix the concept of plugin with package, I think it is OK to store them both in directory “package”.
Also, if we decide to make a libRestG4.so in future, there will be no more package contained in REST.
I think libRestG4 will enter in the definition of library, it defines a type TRestG4Event, it defines processes, TRestG4AnalysisProcess and TRestG4ToHitsProcess and it defines metadata classes TRestG4Metadata, TRestPhysicsList, etc. Then, restDecay0 will be an option that can be plugged into libRestG4 to add Decay0 generation features inside the library. restDataBaseImpl might be a plugin, I did not go deep on this particular implementation.
Yes TRestGas might be considered also a plugin (but not 100% sure) of the future libRestDetector itself. In future, even processes might do use of Garfield++.
