Closed bieryAtFnal closed 2 years ago
Wow, I didn't understand why would you bother changing frags to fragx in 1 but now it makes sense. I don't know if I would have ever caught that one and I agree with you this is likely why I was seeing that not all the fragments were getting to the DQM_TRB.
On 3 I agree with you on that it doesn't matter if you use the new naming or the old one since it's a unique one for each either way, I see that you left the new one so I'll try to remember this in case we want to make other changes in the future that change this part.
For reference, here are the changes that I made today on this branch (which, of course, built on the changes that Juan had already made):
if enable_dqm
conditions around some of the dqm-related sections of mdapp_multiru_gen.py. These were needed because when I ran the configuration generation without the --enable-dqm command-line option, I saw errors.datareq_dqm_{idx}
network endpoints. This included moving where they are defined (in mdapp_multiru_gen.py) and changing their contents.host_df
, when they should be usinghost_ru
(both the DQM process and the Readout process on running on the same host, but those may be different than the DF host). We probably didn't see any problem caused by this in our development testing, because we were using the same host for RU and DF.