DPL: improve type_to_task_name function

[ktf]

• Out of line and avoid usage of stringstream.
• Remove non-sense abbreviations

[github-actions]

REQUEST FOR PRODUCTION RELEASES:
To request your PR to be included in production software, please add the corresponding labels called "async-" to your PR. Add the labels directly (if you have the permissions) or add a comment of the form (note that labels are separated by a ",")

+async-label <label1>, <label2>, !<label3> ...

This will add <label1> and <label2> and removes <label3>.

The following labels are available
async-2023-pbpb-apass4
async-2023-pp-apass4
async-2024-pp-apass1
async-2022-pp-apass7
async-2024-pp-cpass0
async-2024-PbPb-apass1
async-2024-ppRef-apass1
async-2024-PbPb-apass2
async-2023-PbPb-apass5

[ktf]

Apart from some detectors and ALICE3 I most notably missed "MC" as an abbreviation. I suggest to add those in a separate PR. In any case, it should behave as before in the worst case scenario.

[mhemmer-cern]

Hello @ktf
I am happy to see EMCal/EMC in there. If there would be a possibility to add more abbreviations, from the PWGEM Photon side we would like to add PCM (photon conversion method) and PHOS (for the converted data and the early Run3 data where PHOS was included).
Thanks a lot for looking into this!

[ktf]

@mhemmer-cern yes, of course. As I said, please let's see this PR green and merge it and then we can add everything which is missing.

[vkucera]

How many wagons will break because of the changed device names?

[ktf]

Tested on hyperloop. Merging.

[mhemmer-cern]

I just did a quick test with one task that I have that is affected by this change.
I downloaded the config json, then updated the wagon to get the new task name and then just changed it in the downloaded file and uploaded it again. This way I was able to keep my configs.
An announcement with actions to take to ensure smooth transition should be send out to everyone in my opinion @ktf. Otherwise there could be a big confusion happening at the start next week.
As far as I could see the TPC and TOF PID service wagons are not affected since they already had the task names like that.

[ktf]

You mean that you have something which was -e-m-c and that becomes -emc?

[mhemmer-cern]

You mean that you have something which was -e-m-c and that becomes -emc?

exactly, it was task-pi0-flow-e-m-c and is now task-pi0-flow-emc.

[vkucera]

I have found 36 affected workflows. I suspect that the number of affected wagons is much larger.

[ktf]

I can remove "-emc" and "-emcal" from the list, if you prefer, and then we allow people to migrate with proper instructions and so on.

[mhemmer-cern]

I can remove "-emc" and "-emcal" from the list, if you prefer, and then we allow people to migrate with proper instructions and so on.

For me personally it is fine. I knew this change was coming and I was able to migrate properly. I just think that we should announce this change in the proper channel to make sure everyone affected is prepared.

[ddobrigk]

Hi everyone, indeed, this is a little dangerous. On the positive side, last time I had something like this, the task was broken but switching to the new executable (straight from the old executable) made Hyperloop retain all configurable values - but if one switches to the wrong executables, there might be troubles as the sync might destroy the existing configurations. I agree it would be better to announce this maybe tomorrow morning, just in case. Thanks!

[vkucera]

Hi everyone, indeed, this is a little dangerous. On the positive side, last time I had something like this, the task was broken but switching to the new executable (straight from the old executable) made Hyperloop retain all configurable values - but if one switches to the wrong executables, there might be troubles as the sync might destroy the existing configurations. I agree it would be better to announce this maybe tomorrow morning, just in case. Thanks!

I don't think it can work the same with devices. There is no way that Hyperloop can be told to port configuration of one JSON block into another one.

[ddobrigk]

Hi everyone, indeed, this is a little dangerous. On the positive side, last time I had something like this, the task was broken but switching to the new executable (straight from the old executable) made Hyperloop retain all configurable values - but if one switches to the wrong executables, there might be troubles as the sync might destroy the existing configurations. I agree it would be better to announce this maybe tomorrow morning, just in case. Thanks!

I don't think it can work the same with devices. There is no way that Hyperloop can be told to port configuration of one JSON block into another one.

You may be right, indeed: in my case it was only the executable name that changed ...