search

bluesky / ophyd

hardware abstraction in Python with an emphasis on EPICS
https://blueskyproject.io/ophyd
BSD 3-Clause "New" or "Revised" License
51 stars 79 forks source link

Scalar data has wrong shape #58

Closed danielballan closed 9 years ago

danielballan commented 9 years ago

Reminder that scalar data from SRX was coming in with the shape [2] where it should be None. I have not looked into why that is happening yet.

tacaswell commented 9 years ago

should be [] due to the way that ListFields seem to work.

ghost commented 9 years ago

We could default it to None.

tacaswell commented 9 years ago

I think [] makes more sense as it matches the return scheme from numpy.

ghost commented 9 years ago

I agree! None is just a possibility, that's all... :hammer:

dchabot commented 9 years ago

I'm going to leave this open, as we'll have to revisit this properly in the near future. For now, this fix must be disseminated to all field deployments.

tacaswell commented 9 years ago

How do we want to deal with disseminating this?

XPD and SRX can can probably just be drop-in replaced, but SRX will require either a full upgrade (maybe including data migration) or we back port this to what ever version they are running.

I am not a fan of push upgrades, the beamline scientists need to be in the loop on these.

dchabot commented 9 years ago

On Fri Feb 20 2015 at 7:33:16 PM Thomas A Caswell notifications@github.com wrote:

How do we want to deal with disseminating this?

XPD and SRX can can probably just be drop-in replaced, but SRX will require either a full upgrade (maybe including data migration) or we back port this to what ever version they are running.

I am not a fan of push upgrades, the beamline scientists need to be in the loop on these.

I think we (me?) let those beamlines know what the score is, and discuss what the options are for their upgrade.

I will be at the lab tomorrow, so I can make some rounds...

-- dc

— Reply to this email directly or view it on GitHub https://github.com/NSLS-II/ophyd/issues/58#issuecomment-75344639.

tacaswell commented 9 years ago

I should be at my compter in the afternoon to do any packaging/support you may need.

dchabot commented 9 years ago

Thanks, Tom.

On Fri, Feb 20, 2015, 9:51 PM Thomas A Caswell notifications@github.com wrote:

I should be at my compter in the afternoon to do any packaging/support you may need.

— Reply to this email directly or view it on GitHub https://github.com/NSLS-II/ophyd/issues/58#issuecomment-75352300.

dchabot commented 9 years ago

Poking around the mongo command line on 05id and 28id, I don’t see any entries beyond the 13th and 18th of Feb, respectively.

i.e. they’re not using the software. Yet… So, we have a window of opportunity here.

Once the beamline staff is made aware that changes need to be made and OK the operation, we could just nuke their existing mongo store and start fresh. BTW — 05id still shows an outdated “metadataStore” db name in their installation.

Not sure what to do at 23id - they’re quite active... @stuwilkins?

— dc

On Feb 20, 2015, at 7:33 PM, Thomas A Caswell notifications@github.com wrote:

How do we want to deal with disseminating this?

XPD and SRX can can probably just be drop-in replaced, but SRX will require either a full upgrade (maybe including data migration) or we back port this to what ever version they are running.

I am not a fan of push upgrades, the beamline scientists need to be in the loop on these.

— Reply to this email directly or view it on GitHub.

stuwilkins commented 9 years ago

That is certainly a window of opportunity! I will be in tomorrow hopefully working on getting detectors etc. working. We could do it then, but I would need help via gchat or something. DO we have a migration script?

S

On Feb 21, 2015, at 9:16 AM, dchabot notifications@github.com<mailto:notifications@github.com> wrote:

Poking around the mongo command line on 05id and 28id, I don’t see any entries beyond the 13th and 18th of Feb, respectively.

i.e. they’re not using the software. Yet… So, we have a window of opportunity here.

Once the beamline staff is made aware that changes need to be made and OK the operation, we could just nuke their existing mongo store and start fresh. BTW — 05id still shows an outdated “metadataStore” db name in their installation.

Not sure what to do at 23id - they’re quite active... @stuwilkins?

— dc

On Feb 20, 2015, at 7:33 PM, Thomas A Caswell notifications@github.com<mailto:notifications@github.com> wrote:

How do we want to deal with disseminating this?

XPD and SRX can can probably just be drop-in replaced, but SRX will require either a full upgrade (maybe including data migration) or we back port this to what ever version they are running.

I am not a fan of push upgrades, the beamline scientists need to be in the loop on these.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHubhttps://github.com/NSLS-II/ophyd/issues/58#issuecomment-75373405.

dchabot commented 9 years ago

After speaking with Eric and Karen today, they’re both OK with nuking the existing (unused) mongodb collections. As neither 05id or 28id have been exercising the software stack, this is a fairly harmless operation. @Garth: any thoughts on this?

If there are no objections or roadblocks, we should aim to do this either Monday (if not interfering) or Tuesday (maintenance day).

— dc

dchabot commented 9 years ago

I will discuss with the team tomorrow (Monday) then Tuesday before NOON would be good to try.

Thanks, Sanjit

On 2/21/15, 5:26 PM, "Daron Chabot" daronchabot@gmail.com wrote:

After speaking with Eric and Karen today, they�re both OK with nuking the existing (unused) mongodb collections. As neither 05id or 28id have been exercising the software stack, this is a fairly harmless operation. @Garth: any thoughts on this?

If there are no objections or roadblocks, we should aim to do this either Monday (if not interfering) or Tuesday (maintenance day).

� dc

ghost commented 9 years ago

If you make a copy of the data directory of his beam line before you drop metadataStore, we can retrieve his data on any machine in the future. It'll probably make him a little more comfortable.

dchabot commented 9 years ago

This is fine. Please give me a heads up when you actually do the work.

Cheers,

garth

On Feb 21, 2015, at 5:26 PM, Daron Chabot daronchabot@gmail.com wrote:

After speaking with Eric and Karen today, they�re both OK with nuking the existing (unused) mongodb collections. As neither 05id or 28id have been exercising the software stack, this is a fairly harmless operation. @Garth: any thoughts on this?

If there are no objections or roadblocks, we should aim to do this either Monday (if not interfering) or Tuesday (maintenance day).

� dc

dchabot commented 9 years ago

Garth, I will talk to you today and let you al know a good time tomorrow. S

-----Original Message----- From: Williams, Garth Sent: Monday, February 23, 2015 8:13 AM To: Daron Chabot Cc: NSLS-II/ophyd; Eric Dooryhee; Ghose, Sanjit; Chen-Wiegart, Yu-chen Karen Subject: Re: [ophyd] Scalar data has wrong shape (#58)

This is fine. Please give me a heads up when you actually do the work.

Cheers,

garth

On Feb 21, 2015, at 5:26 PM, Daron Chabot daronchabot@gmail.com wrote:

After speaking with Eric and Karen today, they're both OK with nuking the existing (unused) mongodb collections. As neither 05id or 28id have been exercising the software stack, this is a fairly harmless operation. @Garth: any thoughts on this?

If there are no objections or roadblocks, we should aim to do this either Monday (if not interfering) or Tuesday (maintenance day).

  • dc
tacaswell commented 9 years ago

@dchabot Did this get fixed?

dchabot commented 9 years ago

On Apr 9, 2015, at 3:17 PM, Thomas A Caswell notifications@github.com wrote:

@dchabot Did this get fixed?

I believe so - see commit ee2ba492b

tacaswell commented 9 years ago

closed by ee2ba49