cms-sw
Get a repository in cms-data?
Dear experts,
Regarding RPC DQM, we need some kind of "map" representing the status of disconnected RPC chamber for each part of detector (Wheel/Disks, sectors). With the map, we normalize summary map (i.e. make all 'green' by excluding disconnected chambers). It is going to be implemented in the DQM GUI for now, however, because it depends on time period (run number), we would like to migrate it to cmssw and read run-dependent map to calculate 'normalized summary map'.
To store such map, most likely in csv format, I would like to create a repository in cmd-data [1]. The repository will be 'DQM-RPCMonitorClient'. To do so, I wonder if there is specific procedure to create and grant the access for the repository.
Thanks in advance!
[1] https://github.com/cms-data
A new Issue was created by @minerva1993 Jiwon Park.
@Dr15Jones, @perrotta, @dpiparo, @makortel, @smuzaffar, @qliphy can you please review it and eventually sign/assign? Thanks.
cms-bot commands are listed here
@minerva1993 https://github.com/cms-data/DQM-RPCMonitorClient is available now
@smuzaffar
Thanks! Is there any documentation how it works? For example, by executing 'git cms-addpkg DQM/RPCMonitorCliend' for example, is it copied automatically to the working folder?
Cms data doesn't seem like the right solution for any data that is going to be run dependent. This sort of information is not already in the conditions db?
On Jun 16, 2022, at 4:16 PM, Malik Shahzad Muzaffar @.***> wrote:
@minerva1993 https://github.com/cms-data/DQM-RPCMonitorClient is available now
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.
Cms data doesn't seem like the right solution for any data that is going to be run dependent. This sort of information is not already in the conditions db? … On Jun 16, 2022, at 4:16 PM, Malik Shahzad Muzaffar @.***> wrote: @minerva1993 https://github.com/cms-data/DQM-RPCMonitorClient is available now — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.
Hello @davidlange6 , we are aware of it and will going to use it only for this year of data taking. With help of DB expert in RPC group, we will provide better way to do such work (eg. include it to global tag, or develop some automatized way to do it in cmssw level). In addition, the change of the map will not be drastic, considering that the gas leak of chambers are stabilized after the shut down period. Thanks!
So what is your model and needed timescale of deploying changes?
On Jun 16, 2022, at 4:32 PM, Jiwon Park @.***> wrote:
Cms data doesn't seem like the right solution for any data that is going to be run dependent. This sort of information is not already in the conditions db? … On Jun 16, 2022, at 4:16 PM, Malik Shahzad Muzaffar @.***> wrote: @minerva1993 https://github.com/cms-data/DQM-RPCMonitorClient is available now — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.
Hello @davidlange6 , we are aware of it and will going to use it only for this year of data taking. With help of DB expert in RPC group, we will provide better way to do such work (eg. include it to global tag, or develop some automatized way to do it in cmssw level). In addition, the change of the map will not be drastic, considering that the gas leak of chambers are stabilized after the shut down period. Thanks!
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.
So what is your model and needed timescale of deploying changes? … On Jun 16, 2022, at 4:32 PM, Jiwon Park @.> wrote: Cms data doesn't seem like the right solution for any data that is going to be run dependent. This sort of information is not already in the conditions db? … On Jun 16, 2022, at 4:16 PM, Malik Shahzad Muzaffar @.> wrote: @minerva1993 https://github.com/cms-data/DQM-RPCMonitorClient is available now — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread. Hello @davidlange6 , we are aware of it and will going to use it only for this year of data taking. With help of DB expert in RPC group, we will provide better way to do such work (eg. include it to global tag, or develop some automatized way to do it in cmssw level). In addition, the change of the map will not be drastic, considering that the gas leak of chambers are stabilized after the shut down period. Thanks! — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.
As far as I know, we disconnect ~1 chamber per two months in average. In the viewpoint of DQM, any new and known issue can be introduced to the dedicated twiki. But to avoid any confusion, and to spot new issues and changes from the plot, we would like to update such map if needed.
Of course we can do it solely on DQM GUI, but in that case there is an issue if we open (for example) Run2 DQM files in the latest GUI. The presented summary plot will be mis-normalized in that case.
Please let us know if there is any comments or questions, so that we can make better way. Thanks.
Hi @minerva1993 , I accidentally looked into this github issue... I'm Tamas from AlCaDB. I see the following tag in the GT
RPCEMapRcd - RPCEMap_v3
Couldn't this be used for what you need?
What you describe in this github issue is something that's really meant to be a CondFormat then a cms-data. I hope the eMap tag can be used for what you are describing and we can just have a new GT as a solution
New categories assigned: alca
@yuanchao,@francescobrivio,@malbouis,@tvami you have been requested to review this Pull request/Issue and eventually sign? Thanks
Hi @tvami , I discussed with RPC DPG experts and they will soon contact you for further discussion. Thanks for let us know about this payload.
Hi @tvami! I think the RPCEmap is used also for RPC detector configuration for global run, no? In this case I fear it might be danger to remove any chamber from there. From the other side the RPC chambers which are currently Off, are fully operational and disconnected because of the gas leak. But at some moment we can decide to put them On again... I had a look on the cmssw class of this map, but are there any possibility to see the content or schema of this record in order to see can we explore it in a safe way. Thanks! Roumyana
Hi Roumyana,
I think the RPCEmap is used also for RPC detector configuration for global run, no?
Sorry I'm not sure I understand this question. All conditions are used for all global runs as well as the local runs.
In this case I fear it might be danger to remove any chamber from there.
Can you elaborate on this please?
currently Off, are fully operational and disconnected because of the gas leak. But at some moment we can decide to put them On again...
That's exactly why the IOV structure exists. If this is your need, conditions are exactly meant for this.
are there any possibility to see the content or schema of this record in order to see can we explore it in a safe way.
This is a subsystem responsibility. Most subsystems created Payload Inspector plugins to see this. I can give general advice, but not specific for this payload. It is really RPC that should know what's in this payload.
I can offer on the other hand the following: we can create candidate GTs with a payload that has the needed channels off, you guys can run your tests and see what changes, we can also submit a CMS level full track validation to see the effect on other subsystems.
Anyway, seems like a lot of things, maybe we should discuss this at an AlCaDB meeting instead of a github issue?
I can give general advice, but not specific for this payload. OK, will be appreciated. Anyway, seems like a lot of things, maybe we should discuss this at an AlCaDB meeting instead of a github issue? I agree with you. It is better to discuss the details during the meeting. Thanks!
I added you to the agenda for next week: https://indico.cern.ch/event/1176067/#16-bad-rpc-chamber-tag-usage-f
Hi All! On the meeting here, didn't we agree that as a beginning we can go with a list of chambers off in the cms-data? And try to have this as CondFormat for the release cycle (HI and further)? Roumyana
On Jun 16, 2022, at 4:48 PM, Jiwon Park @.***> wrote:
So what is your model and needed timescale of deploying changes? … On Jun 16, 2022, at 4:32 PM, Jiwon Park @.> wrote: Cms data doesn't seem like the right solution for any data that is going to be run dependent. This sort of information is not already in the conditions db? … On Jun 16, 2022, at 4:16 PM, Malik Shahzad Muzaffar @.> wrote: @minerva1993 https://github.com/cms-data/DQM-RPCMonitorClient is available now — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread. Hello @davidlange6 , we are aware of it and will going to use it only for this year of data taking. With help of DB expert in RPC group, we will provide better way to do such work (eg. include it to global tag, or develop some automatized way to do it in cmssw level). In addition, the change of the map will not be drastic, considering that the gas leak of chambers are stabilized after the shut down period. Thanks! — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.
As far as I know, we disconnect ~1 chamber per two months in average. In the viewpoint of DQM, any new and known issue can be introduced to the dedicated twiki. But to avoid any confusion, and to spot new issues and changes from the plot, we would like to update such map if needed.
Of course we can do it solely on DQM GUI, but in that case there is an issue if we open (for example) Run2 DQM files in the latest GUI. The presented summary plot will be mis-normalized in that case.
Please let us know if there is any comments or questions, so that we can make better way. Thanks.
My concern is that it will take weeks for an update to propagate from cms data to your system... But maybe that ok for your use case.
Anyway, its clearly not an appropriate solution, but seems in any case to be a stop-gap solution as for some reason the information can not be easily added to the conditions db.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.
hi @minerva1993 , thanks to David's msg being delayed with month I got reminded about this. Shall we schedule a talk about this again soon? 12_6_X is a dev release, I think introducing a new cond format here would be a good time.
@tvami Hi, during integrity checks for inputs, unfortunately some issues were found and the work is being delayed (which need be resolved by the other experts). Also surrounding situation made me hard to work on this. (moving, graduating, jobs, etc.)
For now it is hard to say when it can be done, how about close the issue for now and ping later? This is must-be-done item for RPC, thus this item will not be buried.