You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[QC-977] Select automatically the correct params (#1865)
* [QC-977] Select automatically the correct params based on the current activity.
* test
* doc
* Update Framework/src/CustomParameters.cxx
Co-authored-by: Piotr Konopka <piotr.jan.konopka@cern.ch>
* Update Framework/src/CustomParameters.cxx
Co-authored-by: Piotr Konopka <piotr.jan.konopka@cern.ch>
---------
Co-authored-by: Piotr Konopka <piotr.jan.konopka@cern.ch>
* Return the value for the given key, runType and beamType (the two latter optional). If it does not exist, returns the default value if provided or an empty string.
@@ -995,7 +996,7 @@ The following tasks will be merged correctly:
995
996
```
996
997
The same approach can be applied to other actors in the QC framework, like Checks (`checkName`), Aggregators(`aggregatorName`), External Tasks (`taskName`) and Postprocessing Tasks (`taskName`).
997
998
998
-
## Definition and access of task-specific configuration
999
+
## Definition and access of user-specific configuration
999
1000
1000
1001
A task can access custom parameters declared in the configuration file at `qc.tasks.<task_id>.extendedTaskParameters` or `qc.tasks.<task_id>.taskParameters`. They are stored inside an object of type `CustomParameters` named `mCustomParameters`, which is a protected member of `TaskInterface`.
1001
1002
@@ -1026,10 +1027,10 @@ The new syntax is
1026
1027
"myOwnKey1": "myOwnValue1b",
1027
1028
"myOwnKey2": "myOwnValue2b"
1028
1029
},
1029
-
"pp": {
1030
+
"PROTON-PROTON": {
1030
1031
"myOwnKey1": "myOwnValue1c"
1031
1032
},
1032
-
"PbPb": {
1033
+
"Pb-Pb": {
1033
1034
"myOwnKey1": "myOwnValue1d"
1034
1035
}
1035
1036
},
@@ -1043,7 +1044,21 @@ It allows to have variations of the parameters depending on the run and beam typ
1043
1044
to ignore the run or the beam type.
1044
1045
The beam type is one of the following: `PROTON-PROTON`, `Pb-Pb`, `Pb-PROTON`
1045
1046
1046
-
The values can be accessed this way:
1047
+
The values can be accessed in various ways.
1048
+
1049
+
### Access optional values with or without activity
1050
+
1051
+
```c++
1052
+
// returns an Optional<string> if it finds the key `myOwnKey` for the runType and beamType of the provided activity.
1053
+
auto param = mCustomParameters.atOptional("myOwnKey", activity); // activity is "PHYSICS", "Pb-Pb" , returns "myOwnValue1d"
1054
+
// same but passing directly the run and beam types
1055
+
auto param = mCustomParameters.atOptional("myOwnKey", "PHYSICS", "Pb-Pb"); // returns "myOwnValue1d"
1056
+
// or with only the run type
1057
+
auto param = mCustomParameters.atOptional("myOwnKey", "PHYSICS"); // returns "myOwnValue1b"
1058
+
```
1059
+
1060
+
### Access values directly specifying the run and beam type
1061
+
1047
1062
```c++
1048
1063
mCustomParameters["myOwnKey"]; // considering that run and beam type are `default` --> returns `myOwnValue`
A task can access custom parameters declared in the configuration file at `qc.tasks.<task_id>.taskParameters`. They are stored inside a key-value map named mCustomParameters, which is a protected member of `TaskInterface`.
1071
-
1072
-
1090
+
## Definition of new arguments
1073
1091
1074
1092
One can also tell the DPL driver to accept new arguments. This is done using the `customize` method at the top of your workflow definition (usually called "runXXX" in the QC).
0 commit comments