3.6. b2conditionsdb: Conditions DB interface

This script provides a command line interface to all the tasks related to the Conditions database: manage globaltags and iovs as well as upload new payloads or download of existing payloads.

The usage of this program is similar to git: there are sub commands like for example tag which groups all actions related to the management of global tags. All the available commands are listed below.

usage: b2conditionsdb [-h] [--debugging] [--help-full] [--base-url BASE_URL]
                      {diff,download,dump,iov,legacydownload,tag,upload} ...

Optional Arguments

--debugging

Enable debugging of http traffic

--base-url

URI for the base of the REST API, if not given a list of default locations is tried

3.6.1. Sub-command b2conditionsdb diff

This command allows to compare two globaltags. It will show the changes in a format similar to a unified diff but by default it will not show any context, only the new or removed payloads. Added payloads are marked with a + in the first column, removed payloads with a -

If --full is given it will show all payloads, even the ones common to both globaltags. The differences can be limited to a given run and limited to a set of payloads names using --filter or --exclude. If the --regex option is supplied the search term will be interpreted as a python regular expression where the case is ignored.

Changed in version release-03-00-00: modified output structure and added --human-readable

Changed in version after: release-04-00-00 added parameter --checksums and --show-ids

b2conditionsdb diff [-h] [--debugging] [--help-full] [--base-url BASE_URL]
                    [--full] [--run N N] [--human-readable] [--checksums]
                    [--show-ids] [-f SEARCHTERM] [-e EXCLUDE] [-r]
                    TAGNAME1 TAGNAME2

Required Arguments

TAGNAME1

base for comparison

TAGNAME2

tagname to compare

Optional Arguments

--debugging

Enable debugging of http traffic

--base-url

URI for the base of the REST API, if not given a list of default locations is tried

--full

If given print all iovs, also those which are the same in both tags

--run

exp and run numbers to limit showing iovs to a ones present in a given run

--human-readable

If given the iovs will be written in a more human friendly format. Also repeated payload names will be omitted to create a more readable listing.

--checksums

If given don’t show the revision number but the md5 checksum

--show-ids

If given also show the payload and iov ids for each iov

-f, --filter

only payloads matching this pattern will be included. Pattern is case insensitive

-e, --exclude

payloads matching this pattern will be excluded. Pattern is case insensitive

-r, --regex

if given, –filter or –exclude options will be interpreted as a python regular expression (see https://docs.python.org/3/library/re.html)

3.6.2. Sub-command b2conditionsdb download

This command allows to download the information from one or more globaltags from the central database to be used locally.

The command requires at least one tag name to download. It will check for existing payloads in the output directory and only download payloads which are not present or don’t have the excpeted checksum.

By default this script will create a local directory called conditions/ which contains a metadata.sqlite with all the payload information of all selected globaltags and sub directories containing all the payload files.

This can be changed by specifying a different name for the metadata file using the -o argument but the payloads will always be saved in sub directoies in the same directory as the sqlite file.

Changed in version release-04-00-00: Previously this command was primarily intended to download payloads for one globaltag and optionally create a text file with payload information as well as download all necessary file. This has been changed and will now create a sqlite file containing the payload metadata. If you need the old behavior please use the command b2conditionsdb legacydownload

b2conditionsdb download [-h] [--debugging] [--help-full] [--base-url BASE_URL]
                        [-o DATABASEFILE] [-f] [--append]
                        [--no-download | --only-download]
                        [--delete-extra-payloads] [--ignore-missing]
                        [-j NPROCESS] [--retries RETRIES]
                        [--tag-pattern | --tag-regex]
                        [TAGNAME [TAGNAME ...]]

Required Arguments

TAGNAME

globaltag to download

Optional Arguments

--debugging

Enable debugging of http traffic

--base-url

URI for the base of the REST API, if not given a list of default locations is tried

-o, --dbfile

Name of the database file to create (default: “conditions/metadata.sqlite”)

-f, --force

Don’t ask permission if the output database file exists

--append

Append to the existing database file if possible. Otherwise the content in the database file will be overwritten

--no-download

Don’t download any payloads, just fetch the metadata information

--only-download

Assume the metadata file is already filled, just make sure all payloads are downloaded

--delete-extra-payloads

if given this script will delete all extra files that follow the payload naming convention AB/{name}_r{revision}.root if they are not referenced in the database file.

--ignore-missing

Ignore missing globaltags and download all other tags

-j

Number of concurrent connections to use for file download (default: 1)

--retries

Number of retries on connection problems (default: 3)

--tag-pattern

if given, all globaltags which match the shell-style pattern TAGNAME will be downloaded: * stands for anything, ? stands for a single character.

--tag-regex

if given, all globaltags matching the regular expression given by TAGNAME will be downloaded (see https://docs.python.org/3/library/re.html).

3.6.3. Sub-command b2conditionsdb dump

New in version release-03-00-00.

This command will dump the payload contents stored in a given payload. One can either specify the payloadId (from a previous output of b2conditionsdb iov), the payload name and its revision in the central database, or directly specify a local database payload file.

Examples

Dump the content of a previously downloaded payload file:

$ b2conditionsdb dump -f centraldb/dbstore_BeamParameters_rev_59449.root

Dump the content of a payload by name and revision directly from the central database:

$ b2conditionsdb dump -r BeamParameters 59449

Dump the content of the payload by name which is valid in a given globaltag for a given experiment and run:

$ b2conditionsdb dump -g BeamParameters main_2021-08-04 0 0

Or directly by payload id from a previous call to b2conditionsdb iov:

$ b2conditionsdb dump -i 59685

Usage

Depending on whether you want to display a payload by its id in the database, its name and revision in the database or from a local file provide one of the arguments -i, -r, -f or -g

Changed in version after: release-04-00-00 added argument -r to directly dump a payload valid for a given run in a given globaltag

b2conditionsdb dump [-h] [--debugging] [--help-full] [--base-url BASE_URL]
                    ([-i PAYLOADID | -r NAME REVISION | -f FILENAME | -g NAME
                    GLOBALTAG EXP RUN)] [--show-typenames]
                    [--show-streamerinfo]

Optional Arguments

--debugging

Enable debugging of http traffic

--base-url

URI for the base of the REST API, if not given a list of default locations is tried

-i, --id

payload id to dump

-r, --revision

Name and revision of the payload to dump

-f, --file

Dump local payload file

-g, --valid

Dump the payload valid for the given exp, run number in the given globaltag

--show-typenames

If given show the type names of all classes. This makes output more crowded but can be helpful for complex objects.

--show-streamerinfo

If given show the StreamerInfo for the classes in the the payload file. This can be helpful to find out which version of a payload object is included and what are the members

3.6.4. Sub-command b2conditionsdb iov

This command lists all IoVs defined in a given globaltag. The list can be limited to a given run and optionally searched using –filter or –exclude. If the –regex option is supplied the search term will be interpreted as a python regular expression where the case is ignored.

Changed in version release-03-00-00: modified output structure and added --human-readable

Changed in version after: release-04-00-00 added parameter --checksums and --show-ids

b2conditionsdb iov [-h] [--debugging] [--help-full] [--base-url BASE_URL]
                   [--run N N] [--detail] [--human-readable] [--checksums]
                   [--show-ids] [-f SEARCHTERM] [-e EXCLUDE] [-r]
                   TAGNAME

Required Arguments

TAGNAME

globaltag for which the the IoVs should be listed

Optional Arguments

--debugging

Enable debugging of http traffic

--base-url

URI for the base of the REST API, if not given a list of default locations is tried

--run

exp and run numbers to limit showing iovs to a ones present in a given run

--detail

if given show a detailed information for all IoVs including details of the payloads

--human-readable

If given the iovs will be written in a more human friendly format. Also repeated payload names will be omitted to create a more readable listing.

--checksums

If given don’t show the revision number but the md5 checksum

--show-ids

If given also show the payload and iov ids for each iov

-f, --filter

only payloads matching this pattern will be included. Pattern is case insensitive

-e, --exclude

payloads matching this pattern will be excluded. Pattern is case insensitive

-r, --regex

if given, –filter or –exclude options will be interpreted as a python regular expression (see https://docs.python.org/3/library/re.html)

3.6.5. Sub-command b2conditionsdb legacydownload

This command allows to download a globaltag from the central database to be used locally, either als lookup directory for payloads or as a standalone local database if –create-dbfile is specified.

The command requires the TAGNAME to download and optionally an output directory which defaults to centraldb in the local working directory. It will check for existing payloads in the output directory and only download payloads which are not present or don’t have the excpeted checksum.

One can filter the payloads to be downloaded by payload name using the –filter, –exclude and –regex options.

New in version release-04-00-00: This has been renamed from download and is kept for compatibility

Deprecated since version release-04-00-00: Downloading a globaltag should be done in the new format creating sqlite database files

b2conditionsdb legacydownload [-h] [--debugging] [--help-full]
                              [--base-url BASE_URL] [-c] [-f SEARCHTERM]
                              [-e EXCLUDE] [-r] [-j NPROCESS]
                              [--retries RETRIES]
                              [--tag-pattern | --tag-regex]
                              TAGNAME [DIR]

Required Arguments

TAGNAME

globaltag to download

DIR

directory to put the payloads into (default: “centraldb”)

Optional Arguments

--debugging

Enable debugging of http traffic

--base-url

URI for the base of the REST API, if not given a list of default locations is tried

-c, --create-dbfile

if given save information about all payloads in DIR/database.txt

-f, --filter

only payloads matching this pattern will be included. Pattern is case insensitive

-e, --exclude

payloads matching this pattern will be excluded. Pattern is case insensitive

-r, --regex

if given, –filter or –exclude options will be interpreted as a python regular expression (see https://docs.python.org/3/library/re.html)

-j

Number of concurrent connections to use for file download (default: 1)

--retries

Number of retries on connection problems (default: 3)

--tag-pattern

if given, all globaltags which match the shell-style pattern TAGNAME will be downloaded: * stands for anything, ? stands for a single character. If -c is given as well the database files will be DIR/TAGNAME.txt

--tag-regex

if given, all globaltags matching the regular expression given by TAGNAME will be downloaded (see https://docs.python.org/3/library/re.html). If -c is given as well the database files will be DIR/TAGNAME.txt

3.6.6. Sub-command b2conditionsdb tag

This command allows to list, show, create modify or clone globaltags in the central database. If no other command is given it will list all tags as if “b2conditionsdb tag show” was given.

b2conditionsdb tag [-h] [--debugging] [--help-full] [--base-url BASE_URL]
                   {clone,create,invalidate,list,merge,modify,publish,runningupdate,show,state}
                   ...

Optional Arguments

--debugging

Enable debugging of http traffic

--base-url

URI for the base of the REST API, if not given a list of default locations is tried

Sub-command b2conditionsdb tag clone

This command allows to clone a given globaltag with a new name but still containing all the IoVs defined in the original globaltag.

b2conditionsdb tag clone [-h] [--debugging] [--help-full]
                         [--base-url BASE_URL]
                         TAGNAME NEWNAME

Required Arguments

TAGNAME

globaltag to be cloned

NEWNAME

name of the cloned globaltag

Optional Arguments

--debugging

Enable debugging of http traffic

--base-url

URI for the base of the REST API, if not given a list of default locations is tried

Sub-command b2conditionsdb tag create

This command creates a new globaltag in the database with the given name and description. The name can only contain alpha-numeric characters and the characters ‘+-_:’.

b2conditionsdb tag create [-h] [--debugging] [--help-full]
                          [--base-url BASE_URL] [-u USER]
                          TYPE TAGNAME DESCRIPTION

Required Arguments

TYPE

type of the globaltag to create, usually one of DEV or RELEASE

TAGNAME

name of the globaltag to create

DESCRIPTION

description of the globaltag

Optional Arguments

--debugging

Enable debugging of http traffic

--base-url

URI for the base of the REST API, if not given a list of default locations is tried

-u, --user

username who created the tag. If not given we will try to supply a useful default

Sub-command b2conditionsdb tag invalidate

This command sets the state of a globaltag to INVALID. This will disqualify this tag from being used in user analysis. A confirmation dialog will be shown.

Deprecated since version release-04-00-00: Use tag state $name INVALID instead

b2conditionsdb tag invalidate [-h] [--debugging] [--help-full]
                              [--base-url BASE_URL]
                              TAGNAME

Required Arguments

TAGNAME

globaltag to be invalidated

Optional Arguments

--debugging

Enable debugging of http traffic

--base-url

URI for the base of the REST API, if not given a list of default locations is tried

Sub-command b2conditionsdb tag list

This command allows to list all globaltags, optionally limiting the output to ones matching a given search term. By default invalidated globaltags will not be included in the list, to show them as well please add –with-invalid as option. Alternatively one can use –only-published to show only tags which have been published

If the –regex option is supplied the search term will be interpreted as a python regular expression where the case is ignored.

b2conditionsdb tag list [-h] [--debugging] [--help-full] [--base-url BASE_URL]
                        [--detail] [--with-invalid | --only-published]
                        [-f SEARCHTERM] [-e EXCLUDE] [-r]

Optional Arguments

--debugging

Enable debugging of http traffic

--base-url

URI for the base of the REST API, if not given a list of default locations is tried

--detail

show detailed information for all tags instead of summary table

--with-invalid

if given also invalidated tags will be shown

--only-published

if given only published tags will be shown

-f, --filter

only tags matching this pattern will be included. Pattern is case insensitive

-e, --exclude

tags matching this pattern will be excluded. Pattern is case insensitive

-r, --regex

if given, –filter or –exclude options will be interpreted as a python regular expression (see https://docs.python.org/3/library/re.html)

Sub-command b2conditionsdb tag merge

This command allows to merge a number of globaltags into a single globaltag. Payloads from later globaltags in the list of arguments are used to fill gaps present in earlier globaltags.

The result is equivalent to having multiple globaltags setup in the conditions access for basf2 (highest priority goes first).

Warning:

The order of the globaltags is highest priority first, so payloads from globaltags earlier on the command line will be taken with before globaltags from later tags.

This command requires that all globaltags are overlap free.

For each globaltag in the list we copy all payloads to the output globaltag if there is no payload of that name valid for the given interval of validity in any previous globaltags in the list.

If the payload overlaps partially with a payload from a previous globaltag in the list the interval of validity is shortened (and possibly split) to not overlap but to just fill the gaps.

For example:

globaltag A contains

payload1, rev 2, valid from 1,0 to 1,10
payload1, rev 3, valid from 1,20 to 1,22
payload2, rev 1, valid from 1,0 to 1,-1

globaltag B contains

payload1, rev 1, valid from 1,1 to 1,30
payload2, rev 2, valid from 0,1 to 1,20

Then running b2conditionsdb tag merge -o output A B, the output globaltag after the merge will contain:

payload1, rev 2, valid from 1,0 to 1,10
payload1, rev 1, valid from 1,11 to 1,19
payload1, rev 3, valid from 1,20 to 1,22
payload1, rev 1, valid from 1,23 to 1,30
payload2, rev 2, valid from 0,1 to 0,-1
payload2, rev 1, valid from 1,0 to 1,-1

When finished, this command will print a table of payloads and their validity and from which globaltag they were taken. If --dry-run is given it will only print the list of payloads.

Optionally one can specify --run-range to limit the run range for which the merging should take place. In the example above, running with --run-range 1 0 1 21 the result would be

payload1, rev 2, valid from 1,0 to 1,10
payload1, rev 1, valid from 1,11 to 1,19
payload1, rev 3, valid from 1,20 to 1,21
payload2, rev 1, valid from 1,0 to 1,21

New in version release-05-01-00.

b2conditionsdb tag merge [-h] [--debugging] [--help-full]
                         [--base-url BASE_URL] -o OUTPUT [--dry-run]
                         [--run-range FIRST_EXP FIRST_RUN FINAL_EXP FINAL_RUN]
                         [-j NPROCESS]
                         globaltag [globaltag ...]

Required Arguments

globaltag

name of the globaltag

Optional Arguments

--debugging

Enable debugging of http traffic

--base-url

URI for the base of the REST API, if not given a list of default locations is tried

--dry-run

Don’t do anything, just print a table with the results

--run-range

Can be for numbers to limit the run range to putin the output globaltag: All iovs will be limited to be in this range.

-j

Number of concurrent threads to use for creating payloads into the output globaltag.

required named arguments

-o, --output

Name of the output globaltag

Sub-command b2conditionsdb tag modify

This command allows to change the name or description of an existing globaltag. You can supply any combination of -n,-d,-t and only the given values will be changed

b2conditionsdb tag modify [-h] [--debugging] [--help-full]
                          [--base-url BASE_URL] [-n NAME] [-d DESCRIPTION]
                          [-t TYPE] [-u USER] [-s STATE]
                          TAGNAME

Required Arguments

TAGNAME

globaltag to modify

Optional Arguments

--debugging

Enable debugging of http traffic

--base-url

URI for the base of the REST API, if not given a list of default locations is tried

-n, --name

new name

-d, --description

new description

-t, --type

new type of the globaltag

-u, --user

username who created the tag. If not given we will try to supply a useful default

-s, --state

new globaltag state, see the command tag state for details

Sub-command b2conditionsdb tag publish

This command sets the state of a globaltag to PUBLISHED. This will make the tag immutable and no more modifications are possible. A confirmation dialog will be shown

Deprecated since version release-04-00-00: Use tag state $name PUBLISHED instead

b2conditionsdb tag publish [-h] [--debugging] [--help-full]
                           [--base-url BASE_URL]
                           TAGNAME

Required Arguments

TAGNAME

globaltag to be published

Optional Arguments

--debugging

Enable debugging of http traffic

--base-url

URI for the base of the REST API, if not given a list of default locations is tried

Sub-command b2conditionsdb tag runningupdate

This command will calculate and apply the necessary updates to a running globaltag with a given staging globaltag

Running tags are defined as “immutable for existing data but conditions for newer runs may be added” and the only modification allowed is to add new payloads for new runs or close existing payloads to no longer be valid for new runs.

This command takes previously prepared and validated payloads in a staging globaltag and will then calculate which payloads to close and what to add to the running globaltag.

For this to work we require

  1. A running globaltag in the state “RUNNING”

  2. A (experiment, run) number from which run on the update should be valid. This run number needs to be

    1. bigger than the start of validity for all iovs in the running tag

    2. bigger than the end of validity for all closed iovs (i.e. not valid to infinity) in the running tag

  3. A staging globaltag with the new payloads in state “VALIDATED”

    1. payloads in the staging tag starting at (0,0) will be interpreted as starting at the first valid run for the update

    2. all other payloads need to start at or after the first valid run for the update.

    3. The globaltag needs to be gap and overlap free

    4. All payloads in the staging tag should have as last iov an open iov (i.e. valid to infinity) but this can be disabled.

The script will check all the above requirements and will then calculate the necessary operations to

  1. Add all payloads from the staging tag where a start validity of (0, 0) is replaced by the starting run for which this update should be valid.

  2. close all iovs for payloads in the running tags just before the corresponding iov of the same payload in the staging tag, so either at the first run for the update to be valid or later

  3. Optionally, make sure all payloads in the staging tag end in an open iov.

Example:

running tag contains

payload1, rev 1, valid from 0,1 to 1,0
payload1, rev 2, valid from 1,1 to -1,-1
payload2, rev 1, valid from 0,1 to -1,-1
payload3, rev 1, valid from 0,1 to 1,0
payload4, rev 1, valid from 0,1 to -1,-1
payload5, rev 1, valid from 0,1 to -1,-1

staging tag contains

payload1, rev 3, valid from 0,0 to 1,8
payload1, rev 4, valid from 1,9 to 1,20
payload2, rev 2, valid from 1,5 to 1,20
payload3, rev 2, valid from 0,0 to -1,-1
payload4, rev 1, valid from 0,0 to 1,20

Then running b2conditionsdb tag runningupdate running staging --run 1 2 --allow-closed, the running globaltag after the update will contain

payload1, rev 1, valid from 0,1 to 1,0
payload1, rev 2, valid from 1,1 to 1,1
payload1, rev 3, valid from 1,2 to 1,8
payload1, rev 4, valid from 1,9 to 1,20
payload2, rev 1, valid from 0,1 to 1,4
payload2, rev 2, valid from 1,5 to 1,20
payload3, rev 1, valid from 0,1 to 1,0
payload3, rev 2, valid from 1,2 to -1,-1
payload4, rev 1, valid from 0,1 to 1,20
payload5, rev 1, valid from 0,1 to -1,-1

Note that

  • the start of payload1 and payload3 in staging has been adjusted

  • payload2 in the running tag as been closed at 1,4, just before the validity from the staging tag

  • payload3 was already closed in the running tag so no change is performed. This might result in gaps but is intentional

  • payload4 was not closed at rim 1,2 because the staging tag had the same revision of the payload so the these were merged to one long validity.

  • payload5 was not closed as there was no update to it in the staging tag. If we would have run with --full-replacement it would have been closed.

  • if we would have chosen --run 1 1 the update would have failed because payload1, rev2 in running starts at 1,1 so we would have a conflict

  • if we would have chosen --run 1 6 the update would have failed because payload2 in the staging tag starts before this run

  • if we would have chosen to open the final iovs in staging by using --fix-closed, payload1, rev 4; payload2, rev 2 and payload4 rev 1 would be valid until -1,-1 after the running tag. In fact, payload 4 would not be changed at all.

b2conditionsdb tag runningupdate [-h] [--debugging] [--help-full]
                                 [--base-url BASE_URL] -r EXP RUN
                                 [--allow-closed | --fix-closed | --simple-mode | --full-replacement]
                                 [--dry-run]
                                 running staging

Required Arguments

running

name of the running globaltag

staging

name of the staging globaltag

Optional Arguments

--debugging

Enable debugging of http traffic

--base-url

URI for the base of the REST API, if not given a list of default locations is tried

--allow-closed

if given allow payloads in the staging tag to not be open, i.e. they don’t have to be open ended in the update. Useful to retire a payload by adding one last update

--fix-closed

if given automatically open the last iov for each payload in staging if it is closed.

--simple-mode

if given require the staging tag to solely consist of fully infinite validities: Only one iov per payload with a validity of (0,0,-1,-1)

--full-replacement

if given perform a full replacement and close all open iovs in the running tag not present in the staging tag. After such an update exactly the payloads in the staging tag will be valid after the given run. This allows for closed iovs in the staging tag as with --allow-closed

--dry-run

Only show the changes, don’t try to apply them

required named arguments

-r, --run

First experiment + run number for which the update should be valid. Two numbers separated by space

Sub-command b2conditionsdb tag show

This command will show details for the given globaltags like name, description and number of payloads.

b2conditionsdb tag show [-h] [--debugging] [--help-full] [--base-url BASE_URL]
                        TAGNAME [TAGNAME ...]

Required Arguments

TAGNAME

globaltags to show

Optional Arguments

--debugging

Enable debugging of http traffic

--base-url

URI for the base of the REST API, if not given a list of default locations is tried

Sub-command b2conditionsdb tag state

This command changes the state of a globaltag to the given value.

Usually the valid states are

OPEN

Tag can be modified, payloads and iovs can be created and deleted. This is the default state for new or cloned globaltags and is not suitable for use in data analysis

Can be transitioned to TESTING, RUNNING

TESTING

Tag cannot be modified and is suitable for testing but can be reopened

Can be transitioned to VALIDATED, OPEN

VALIDATED

Tag cannot be modified and has been tested.

Can be transitioned to PUBLISHED, OPEN

PUBLISHED

Tag cannot be modified and is suitable for user analysis

Can only be transitioned to INVALID

RUNNING

Tag can only be modified by adding new runs, not modifying the payloads for existing runs.

INVALID:

Tag is invalid and should not be used for anything.

This state is end of life for a globaltag and cannot be transitioned to any other state.

New in version release-04-00-00.

b2conditionsdb tag state [-h] [--debugging] [--help-full]
                         [--base-url BASE_URL]
                         TAGNAME STATE

Required Arguments

TAGNAME

globaltag to be changed

STATE

new state for the globaltag

Optional Arguments

--debugging

Enable debugging of http traffic

--base-url

URI for the base of the REST API, if not given a list of default locations is tried

3.6.7. Sub-command b2conditionsdb upload

This command allows uploading a local database which was created by basf2 to the central database. It assumes that the globaltag already exists so please create it before if necessary using ‘tag create’.

The command requires the tagname to upload the payloads to and a database.txt containing the payloads and their iovs. One can supply a directory where to look for the payloads, by default they are assumed to be in the same directory as the database text file.

b2conditionsdb upload [-h] [--debugging] [--help-full] [--base-url BASE_URL]
                      [--normalize | --normalize-name NORMALIZE_NAME]
                      [-j NPROCESS] [--retries RETRIES] [--ignore-existing]
                      TAGNAME PAYLOADSFILE

Required Arguments

TAGNAME

globaltag to use for iov creation

PAYLOADSFILE

Testing payload storage file containing list of iovs

Optional Arguments

--debugging

Enable debugging of http traffic

--base-url

URI for the base of the REST API, if not given a list of default locations is tried

--normalize

Normalize the payload files to have reproducible checksums. This option should only be used if the payload files were created with an older software version (before release-04)

--normalize-name

Set the file name in the root file metadata to the given value. This implicitly enables --normalize and should only be used if the payload files were created with an older software version (before release-04)

-j

Number of concurrent connections to use for database connection (default: 1)

--retries

Number of retries on connection problems (default: 3)

--ignore-existing

Don’t check if payloads or iovs already exist in database. Speeds up initialization as the list of existing payloads doesn’t need to be downloaded. Can be used on first upload but the script cannot resume an upload if this option is given

3.6.8. b2conditionsdb-extract: Extract payload for a run range and save as TTree

New in version release-03-00-00.

This tool reads the given conditions objects from the database and writes them to a TTree. Intra run dependencies are not supported.

For example the command

b2conditionsdb-extract --exp 5 --runs 1-3,12 BeamParameters

will create a root file with a Tree containing the beam parameters of the runs 1, 2, 3, and 12 of experiment 5. The branch BeamParameters_valid contains 1 if the beam parameters are available for the given run and 0 if not. The following command plots the x position of the beam spot after opening the conditions.root file in root:

conditions->Draw("BeamParameters.m_vertex.x():run", "BeamParameters_valid", "*")
usage: b2conditionsdb-extract [-h] [--output OUTPUT] [--tag TAG] --exp EXP
                              --runs RUNS
                              condition [condition ...]

Required Arguments

condition

payload identifier, if the type is not equal to the name it has to be appended after a /

Optional Arguments

--output, -o

output file containing the TTree of conditions

Default: “conditions.root”

--tag, -t

global tag

--exp, -e

experiment number

--runs

run numbers, ranges are given as X-Y, multiple runs or ranges are separated by comma

3.6.9. b2conditionsdb-recommend: Recommend a global tag to analyse a given file

New in version release-03-00-00.

This tool determines the recommended set of global tags.

usage: b2conditionsdb-recommend [-h] [--oneline] [input_file]

Required Arguments

input_file

Input file that should be processed. No input file means MC generation.

Optional Arguments

--oneline

Prints the recommended global tags as a one-liner string.

3.6.10. b2conditionsdb-request: Request inclusion of payloads in official global tag

New in version release-03-00-00.

Tool to request an update of a global tag.

The tool will ask for the information required by the global tag manager for the update or take them from the command line options.

usage: b2conditionsdb-request [-h]
                              [--task {main,new,modify,validation,online,prompt,data,mc,analysis}]
                              [--normalize | --normalize-name NORMALIZE_NAME]
                              [--release RELEASE] [--reason REASON]
                              [--details DETAILS | --details-file DETAILS_FILE]
                              [--issue ISSUE] [--password PASSWORD | --oauth]
                              [--confirm]
                              payloads

Required Arguments

payloads

Name of the testing payload storage file

Optional Arguments

--task

Possible choices: main, new, modify, validation, online, prompt, data, mc, analysis

Type of global tag that should be updated.

Use new/modify if the request contains new/modified payload classes.

--normalize

Normalize the payload files to have reproducible checksums. This option should only be used if the payload files were created with an older software version (before release-04)

--normalize-name

Set the file name in the root file metadata to the given value. This implicitly enables --normalize and should only be used if the payload files were created with an older software version (before release-04)

--release

Required release version

--reason

Reason for the request

--details

Detailed instructions/information for the global tag manager

--details-file

File containing detailed instructions/information for the global tag manager

--issue

Identifier of an existing jira issue for the request

--password

Password to authenticate the request

--oauth

Authenticate via oauth. This is should only be used for automated updates running within the DAQ network.

--confirm

Confirm that the given information is correct and that the payloads should be uploaded