Closed strempfer closed 3 years ago
This pull request introduces 1 alert when merging f9d860c19e3255ba82bde898a8003b1da0a6320c into 1732b2e91d7b6324a4dd95a6d14999c99ca6b7ca - view on LGTM.com
new alerts:
This pull request introduces 1 alert when merging e1bd5392595e8c067e8c85a7b91a23db56352896 into 1732b2e91d7b6324a4dd95a6d14999c99ca6b7ca - view on LGTM.com
new alerts:
This pull request introduces 1 alert when merging e44b8447dc7d7aa9f17a9b2b47185ec90ad0027c into 1732b2e91d7b6324a4dd95a6d14999c99ca6b7ca - view on LGTM.com
new alerts:
This pull request introduces 1 alert when merging f77d0dc8be03d62c08eefa65bc409271e91c7599 into 1732b2e91d7b6324a4dd95a6d14999c99ca6b7ca - view on LGTM.com
new alerts:
In diffraction.fit_series()
, this code (flagged by LGTM) will catch every exception, whether due to mathematics or some other python problem: https://github.com/APS-4ID-POLAR/polartools/blob/f77d0dc8be03d62c08eefa65bc409271e91c7599/polartools/diffraction.py#L161-L166
Q: Why is this a problem to be fixed?
A: Catching the BaseException
(as this code does now) makes debugging very hard by ignoring the very existence of any problems within this try..except
block.
What exception(s) is/are expected? Re-write as except ValueError:
(for one exception possibility or except (KeyError, AttributeError):
for multiple possibilities. Replace the examples with the expected exception(s). And if you want to inform what exception was received, add as exc
to get access to the details. This example prints a short summary:
except NoneError as exc:
print(f"Yikes!!! Got an exception: ''{exc}")
You can also handle exceptions individually if that is worthwhile:
except NoneError:
print("a NoneErrorhappened")
except ValueError:
print("a ValueError happened")
except AttributeError:
print("an AttributeError happened")
I wonder how it is possible in BlueSky to have any variable be used as the varying variable for the scan series, if this is not scanned but in the header, like in #P or #U for the Spec file. I got something for Spec, which I will implement, but it would be great if this could be generalized also for the BlueSky database.
I'm not entirely sure I understand what you mean, but in Bluesky it's rather easy to add stuff to the metadata, which is added to every scan. There is a few ways to do it (note that the metadata is a python dictionary):
extra_metadata = {'my variable': 1}
RE(lup(motor, start, end, points, md=extra_metadata))
def myscan(..., md = None):
_md = {'extra_metadata': 1}
_md.update(md)
yield from scan(..., md=_md)
RE.md['extra_metadata'] = 1
# Then if you want to change this metadata
RE.md['extra_metadata'] = 2
Our current load functions in polartools.load_data
ignore the metadata, this is because it is rather straightforward to get it in bluesky. To access it from the beamline would look something like (our database is loaded into the db
variable):
extra_metadata = db[scan_number].metadata['start']['extra_metadata']
There is a few ways to do it ...
And if that were not enough, there is an additional type of metadata called baseline that records Devices at the start and end of every run. For reference, the baseline data stream is the closest Bluesky counterpart to SPEC's recording of all the positioners in a scan's header (the #P
& #O
control lines in a SPEC data file). The items included in the baseline can be controlled for every run or for specific plans.
There's a whole documentation page about Bluesky metadata: https://blueskyproject.io/bluesky/metadata.html?highlight=baseline#recording-metadata
And then there are monitors, to record every change of a Signal as a separate stream in a run ... (This is how the APS storage ring current is logged during a run.)
In diffraction.py, function 'fit_series' added and slightly different fit function 'fit_peak' added.