Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • bliss bliss
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 605
    • Issues 605
    • List
    • Boards
    • Service Desk
    • Milestones
  • Jira
    • Jira
  • Merge requests 165
    • Merge requests 165
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • BlissBliss
  • blissbliss
  • Issues
  • #2687

Rework scan_info acquisition_chain

This is proposal to discuss about reworking the acquisition_chain field from the scan_info.

State

Now the acquisition_chain looks like that:

    "acquisition_chain": {
        "timer": {
            "master": {
                "images": [],
                "scalars": ["timer:elapsed_time", "timer:epoch"],
                "spectra": [],
            },
            "scalars": ["diode1"],
            "images": ["lima1:image"]
        },
        "axis":
            "master": {
                "images": [],
                "scalars": ["sx"],
                "spectra": [],
            },
            "scalars": ["diode2"],
        "img": {
            "master": {
                "images": ["lima2:image"],
            },
            "spectra": ["opium:mca1"],
            "scalars": ["timer:elapsed_time", "timer:epoch"]
        },
    },

It contains:

  • Relationship between top master and channels
  • Channel generated by device used as master
  • Kind of channel data
  • Ordered top masters
  • Ordered channels

What i don't like

    1. structurally is_master and data kind are orthogonal information
    • but here is handled by combination (6*2 = 6 lists, for now)
    1. data kind have nothing to do with the acquisition_chain
    • This information is probably not at the proper place
    1. spectra is not a proper name for any kind of list of values (in fact it's the same for image)
    • It feels like an accurate kind, but it's just about data dimension
    1. A channel is never a master -> a device is the master and this device produce a channel
    • What does lima:image as master means?
      • That's in fact just a counter
    • Maybe there is a better way to handle that
    1. We have to expose metadata per devices (right now we have to cheat using channels)

Proposal 1

  • This address 1) 2) 3)
  • Now we have a scan_info/channels fields which can be used for data kind
  • We can use data dim instead of data kind
scan_info = {
    'acquisition_chain': {
        'timer': {
            # WAS ADDED
            'devices': ['timer', 'simulation_diode_sampling_controller'],

            # STILL THERE FOR COMPATIBILITY
            'images': [],                                                                                                                                                      
            'master': {'images': [], 'scalars': ['timer:elapsed_time', 'timer:epoch'], 'spectra': []},
            'scalars': ['simulation_diode_sampling_controller:diode1'],
            'spectra': []}
    },

    # WAS ADDED
    'devices': {
        'simulation_diode_sampling_controller': {
            'channels': ['simulation_diode_sampling_controller:diode1']},
        'timer': {
            'channels': ['timer:elapsed_time', 'timer:epoch'],                                                                                                                           
            'triggers': ['simulation_diode_sampling_controller']}
    },

    'channels': {
        'simulation_diode_sampling_controller:diode1': {
            'dim': 0,  # <-- DIM WAS ADDED
            'display_name': 'diode1'},
        'timer:elapsed_time': {
            'dim': 0,
            'display_name': 'elapsed_time',
            'unit': 's'},                                                                                                                                                  
        'timer:epoch': {
            'dim': 0,
            'display_name': 'epoch',
            'unit': 's'}
    },
}

It contains the same information as before then I think there is no problem to implement this change.

Proposal 1+1

  • This address 4) 5)
  • We can expose the devices and the relationshit between devices and channels
  • A device can be a master if it triggers other devices (no magic, exact same model as bliss)
    'acquisition_chain': {
        'timer': {
            # WAS ADDED
            'devices': ['timer', 'simulation_diode_sampling_controller'],

            # STILL THERE FOR COMPATIBILITY
            'images': [],                                                                                                                                                      
            'master': {'images': [], 'scalars': ['timer:elapsed_time', 'timer:epoch'], 'spectra': []},
            'scalars': ['simulation_diode_sampling_controller:diode1'],
            'spectra': []}
    },

    # WAS ADDED
    'devices': {
        'simulation_diode_sampling_controller': {
            'channels': ['simulation_diode_sampling_controller:diode1']},
        'timer': {
            'channels': ['timer:elapsed_time', 'timer:epoch'],                                                                                                                           
            'triggers': ['simulation_diode_sampling_controller']}
    },
Edited Apr 14, 2021 by Valentin Valls
Assignee
Assign to
Time tracking