Should we rename the very unhandy scan_config_override_per_scan to something like config_override, since it's not just scan_config but also chip parameters that can be overridden and also the _per_scan part is inherently clear since its a parameter of the scan?
Default config file
Format should be .cfg.h5, otherwise you break double click opening
maybe stick with yaml here? We don't have default masks and this might be nice to be able to quickly change?
scan.scan: If no parameters are explicitly specified, output config = input config?
So no white/blacklist feature? Makes things easier, but is every case handled?
I understand correctly, that every output file (both raw data and interpreted, unless scan fails somewhere) will have an input config node as well as an output config node, just that in some (most) cases those are identical?
Like I said before, scan_config_override_per_scan is only for chip-specific overrides (may call it scan_config_override_per_chip...). If you don't need crazy chip-specific settings, the general (for all chips) override (currently) happens directly via appending to scan_configuration.
Ok, but this should be implemented such that the changed settings don't have to be set for each chip individually (i.e. without requiring the module_0: {fe_0 {... structure), but also such that settings can be defined per chip (via module_0: {fe_0 {...) somewhere.
Should we rename the very unhandy scan_config_override_per_scan
Agree, is on the todo list.
Default config file...
Sure. Did not pay attention to that detail in the painting
scan.scan: If no parameters are explicitly specified, output config = input config?
Also, anlayze step could define something (e.g. disable mask). Otherwise yes, that would be the case.
So no white/blacklist feature? Makes things easier, but is every case handled?
Why not specify in scan? The scan should know what is important and we do not clutter API.
I understand correctly, that every output file (both raw data and interpreted, unless scan fails somewhere) will have an input config node as well as an output config node, just that in some (most) cases those are identical?
I would not store the output node if identical, but there might be reasons to do that?
This looks great,it would be cool, if a setting like 'default' would always load the default config and not the latest h5. :)
The name default could also imply default behavior = use latest config. Maybe just mentioning the file rd53a_default.cfg.yaml is sufficient? We can search the path, where it is, that one only has to give a file name. Or we name it std_config?
Maybe just mentioning the file rd53a_default.cfg.yaml is sufficient? We can search the path, where it is, that one only has to give a file name.
I think this is the best option, also with regard to the new chip. BTW, should we add a chip type flag to the configs to make sure we don't load an RD53A config for an RD53B chip?