Add RHICf Run and Event number address in StRHICfDbMaker

[ggfdsa10]

PR 2. StRHICfDbMaker for RHICf Run and Event Number for the new STAR release

1. StRHICfCollection
   2) this PR
2. StMuDstMaker/StRHICfRawHit and StRHICfUtil
3. StRHICfRawHitMaker

[genevb]

I understand what it means to get the numbers, but what does it mean to get the numbers' addresses? Are these meant to return pointers?

[ggfdsa10]

These addresses simply return the index of the RHICf run and event number, in the order in which they are stored in the daq file (e.g. adc, tdc, etc.).

[genevb]

Thanks for the response, Seunghwan, but it remains unclear to me how the event number address is different from STAR's event ID, which is the count of STAR DAQ recorded events. Perhaps it is specific to the event count within a file, but that would then simply be a number you can get from the event's index within the MuDst or PicoDst.

Or when you say DAQ, do you mean the RHICf DAQ and not the STAR DAQ?

[ggfdsa10]

As I understand it, when we run RHICf in STAR at 2017 year, we get the RHICf data (not STAR Data, it is just made by an external trigger system) at the same time as we get the DAQ data in STAR format also saved in STAR which name is st_xxx_rhicf_stream, so what I said DAQ mean STAR DAQ.

As you know, we have already analyzed using external RHICf data, which has its own sequential events and run numbers, and these values are currently stored in indexes 0 and 1 of the RHICf detector raw data inside the data acquired for STAR format.

It was necessary to cross-check to avoid any possible mistakes in the future (e.g. in existing standalone code or analysis), which is why we needed the run and event numbers used in the RHICf standalone analysis outside of STAR.

So those run and event numbers were defined by external RHICf triggers or instruments, not by hardware or triggers on the STAR.

I hope that answers your question.
and I'm so sorry for the confusion.

Thank you

[genevb]

I now understand what is meant by "address", and that these are simply functions that give that address. I think it would have been just as easy (or easier) to define a constant to hold the values 0 and 1 instead of functions, but it's not a big deal to me which way it gets implemented. Let's move on.

[ggfdsa10]

Thank you very much for your approval,
and I want to request PRs for these revised things of the RHICf
As you know, there are two PRs left.
Can I push the merge?
If you are OK, I will keep going as soon as possible before MuDst production