ENH: recording temperature controller readback in each xrun

[chiahaoliu]

It would be great to always have temperature controller readback as part of metadata, could be in the filename or other formats.

Expected Behavior

record temperature controller readback values for all xrun

Current Behavior

Temperature controller are recorded only if Tramp or Tlist is run.

Possible Solution

In general, we want to record as much auxiliary metadata as possible, which is exact the usecase of SupplementalData.

Context

In some experiments, user might ramp the temperature controller and collect data while ramping, instead of running Tramp or Tlist where collect data at deterministic points.

Under current setup of xpdAcq, user can only have the temperature information written down by hand.

Attn: @sbanerjee23 @eaculb

[CJ-Wright]

How will we know what the sample temperature is?

[chiahaoliu]

That's a good point. I think currently user assumes the temperature readback from the temperature controller is closer to the sample temperature.

[sbanerjee23]

This is cryostream temperature not sample temperature. Users' responsibility to understand whether controller readback value applies for their sample or not. Could be another boolean in sample sheet where sample slated for temperature dependent measurements, single shot or ramp, gets flagged as such in metadata (in addition to temperature being recorded).

[sbillinge]

So set a variable cryostream_temperature which is always recorded but only used when needed? On Wed, Oct 4, 2017 at 3:52 PM Soham Banerjee notifications@github.com wrote:

This is cryostream temperature not sample temperature. Users' responsibility to understand whether controller readback value applies for their sample or not. Could be another boolean in sample sheet where sample slated for temperature dependent measurements, single shot or ramp, gets flagged as such in metadata (in addition to temperature being recorded).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/xpdAcq/mission-control/issues/45#issuecomment-334270216, or mute the thread https://github.com/notifications/unsubscribe-auth/AEDrUb7PvxxmAxuRmaZ1HSCLqVBhCuIYks5so-IVgaJpZM4Pt536 .

[CJ-Wright]

I'm confused by the difference between recorded and used.

[sbillinge]

We Record the temperature, the user doesn't use it.

On Sat, Oct 7, 2017 at 1:00 PM Christopher J. Wright < notifications@github.com> wrote:

I'm confused by the difference between recorded and used.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/xpdAcq/mission-control/issues/45#issuecomment-334950131, or mute the thread https://github.com/notifications/unsubscribe-auth/AEDrUeXZp0QAgxqlY97uTtLokvQsUvReks5sp64igaJpZM4Pt536 .

[CJ-Wright]

I think so. I guess I'm a bit fuzzy on how the user will interact with this info (not that they won't, but what are the use cases). Do we write this temperature into the sample name? The temperatures will be their own stream (if we use the supplemental data framework) so that may be a bit tricky. The users could look at this using the databroker without any problems.

[chiahaoliu]

Naively speaking, would saving the event metadata, whether it's auxiliary or not, for each xrun cover this UC?

For file-based workflow, if a scan is explicitly executed with Tramp or Tlist, temperature information will appear in file name as well as in the even metadata file. If a scan is executed by ct or some other kinds of scan plan, the temperature information will only appear in the event metadata file and user can utilize the readback values with his judgments.

Of course user can have all the data above, if he is in non-file-based workflow and interacts with data broker. And above workflow could be extended to all motors.

[sbillinge]

Soham should answer this question since he requested it On Sat, Oct 7, 2017 at 3:49 PM Timothy Liu notifications@github.com wrote:

Naively speaking, would saving the event metadata, whether it's auxiliary or not, for each xrun cover this UC?

For file-based workflow, if a scan is explicitly executed with Tramp or Tlist, temperature information will appear in file name as well as in the even metadata file. If a scan is executed by ct or some other kinds of scan plan, the temperature information will only appear in the event metadata file and user can utilize the readback values with his judgments.

Of course user can have all the data above, if he is in non-file-based workflow and interacts with data broker. And above workflow could be extended to all motors.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/xpdAcq/mission-control/issues/45#issuecomment-334961472, or mute the thread https://github.com/notifications/unsubscribe-auth/AEDrUVU_9c7Z8GGcwtZ3aMUFTxBqnh8kks5sp9XcgaJpZM4Pt536 .

[sbanerjee23]

For me, if cryostream_temperature was just recorded in the .yml file that would be great for now. And like Tim said, if it's possible to record even more motor values, that would be useful for us. For example, every time we start a beamtime we always write down the goniometer and PE1 positions, and the filters being used.

[sbillinge]

I think we can automatically record pretty much anything we have PV's for without too much difficulty (though it would probably have to be hard-coded so when new things become available they would have to be added.

Another thought. We could request some kind of wide-angle web-cam thing in the hutch that captures an image that can be recorded somehow. This will show the hutch setup at the time of the measurement?

S

On Sun, Oct 8, 2017 at 10:12 AM Soham Banerjee notifications@github.com wrote:

For me, if cryostream_temperature was just recorded in the .yml file that would be great for now. And like Tim said, if it's possible to record even more motor values, that would be useful for us. For example, every time we start a beamtime we always write down the goniometer and PE1 positions, and the filters being used.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/xpdAcq/mission-control/issues/45#issuecomment-335009319, or mute the thread https://github.com/notifications/unsubscribe-auth/AEDrUe4BzbAkW7PNzk63nhLVEGrh3YAbks5sqNg3gaJpZM4Pt536 .

[CJ-Wright]

Formally we can access anything that has an ophyd object. Yes we will have to code into the supplemental data which objects to listen to.

I don't know what the camera setup is in the hutch maybe someone from the @xpdAcq/bls can comment?

[chiahaoliu]

24

Link another discussion on which devices to record by default

[sbillinge]

per conversation with @CJ-Wright solution looks like this:

1. run an asynchronous baseline event stream that listens to various things, including any temperature controllers
2. this gets saved to a uuid_baselineStream.yaml metadata file that gets saved with the uuid.yaml metadata file that saves the start header metadata

[sbillinge]

fairly major upgrade so punting to 2018-2 release

[chiahaoliu]

Per discussion with @CJ-Wright and @sbillinge, we can start implementing this UC by stuffing an extra list of "monitoring" detectors (such as temperature controller, sample stages...etc.) when xrun is triggered and if user encounters delays, we can start implementing acquisition in a separate stream.

[sbillinge]

I think we need more time to think about this, and how to implement it correctly, also discuss with the users whether they actually really want it. I'm going to bump it off the milestone @chiahaoliu

[sbillinge]

We should probably rediscuss this. We can't implement a solution until we know what we want to do exactly. @eaculb please could you put this onto a group meeting agenda for discussion.