dissociate bt from xrun after _end_beamtime

[chiahaoliu]

xrun remebers bt even after _end_beamtime

Expected Behavior

bt is dissociated after _end_beamtime

Current Behavior

xrun remebers bt even after _end_beamtime

Possible Solution

1. poke around current namespace and modify xrun
2. gently remind the user to exit out current ipython session

[chiahaoliu]

Both solution 1 and 2 are feasible, I would like to vote for 2 since it is safer for the software point of view...(at the cost of restarting bsui)

Any ideas?

@DanOlds @CJ-Wright @sbillinge

[DanOlds]

I'm worried that if we don't either a.) fix this in the namespace or b.) force a quit of the current ipython session, this issue will inevitably pop up again, and a future user will end up with incorrectly-labeled data.

[DrMorpheus]

Just to chime in, as Hui mentioned, it happened to us before, and was not a simple fix to recover from. If Hui hadn't been there to help us through it, I think our next step was flipping tables.

[chiahaoliu]

Just a friendly reminder, there is a built-in print statement in _start_beamtime explicitly saying:

"INFO: to link newly created beamtime object to xrun, "
            "please do\n"
            ">>> xrun.beamtime = bt

ref: https://github.com/xpdAcq/xpdAcq/blob/master/xpdacq/beamtimeSetup.py#L62-L66

If the instruction is followed as prompted, we could've avoided the problem :) It is understandable that sometimes this information is overlooked so we have a PR to mitigate the possibility of this event in the future.

[CJ-Wright]

I think a good way forward would be: when _end_beamtime is run it injects a poison pill into the global configuration. This poison pill will cause any subsequent _start_beamtime functions in that terminal to give a descriptive error explaining that the users need to open a new terminal and run bsui to start a new beamtime. This will prevent new users from inheriting any of the previous beamtime's state (eg changes made to xrun or ipython in addition to their beamtime) which were not written into the ipython profiles. Simultaneously it will allow anyone to interact with the existing terminal from the previous beamtime. This would be useful in case users wanted to access the databroker, get all their ipython history, or anything else they wanted to do with their accumulated state.

[sbillinge]

:+1: This is not a time to be polite to the users and gently ask them to do things....our philosophy was always to give users a fresh session for their beamtime in a standard state.

This will become worse in time as people increasingly start getting their data from databroker rather than saving files during the run.

S On Thu, Mar 21, 2019 at 12:35 AM Christopher J. Wright < notifications@github.com> wrote:

I think a good way forward would be: when _end_beamtime is run it injects a poison pill into the global configuration. This poison pill will cause any subsequent _start_beamtime functions in that terminal to give a descriptive error explaining that the users need to open a new terminal and run bsui to start a new beamtime. This will prevent new users from inheriting any of the previous beamtime's state (eg changes made to xrun or ipython in addition to their beamtime) which were not written into the ipython profiles. Simultaneously it will allow anyone to interact with the existing terminal from the previous beamtime. This would be useful in case users wanted to access the databroker, get all their ipython history, or anything else they wanted to do with their accumulated state.

— You are receiving this because you were mentioned.

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

[CJ-Wright]

I think this has been fixed by the poison pill.