Arctos: positions

Created on 17 Oct 2018  ·  45Comments  ·  Source: ArctosDB/arctos

We're doing two things with container type "position" - they're grid-mapped containers which never have barcodes (freezer box wells), and they're whatever someone felt like calling a position for some reason. The latter may or may not have barcodes. That's confusing; I suggest we split this up somehow.

Here are container types that hold positions.


select 
  c.container_type,
  decode(p.barcode,NULL,'no','yes') posnhasbarcode,
  count(*) c
from
  container c,
  container p
where
  p.parent_container_id=c.container_id and
  p.container_type='position'
group by
   c.container_type,
  decode(p.barcode,NULL,'no','yes')
order by
  c.container_type
 15   16  ;

CONTAINER_TYPE                           POSNHASBA      C
------------------------------------------------------------ --------- ----------
bag                              no           500
cabinet                              yes           26
freezer                              no           114
freezer                              yes          854
freezer box                          no        901371
freezer box                          yes           93
freezer rack                             no            81
freezer rack                             yes        10188
microplate                           yes           96
range case                           yes         1744
shelf                                yes           64
slide box                            no         44599

12 rows selected.

Most-obvious funky data below.

There's some code around container type "position" so I have a slight preference for keeping that. Can we identify and rename the positions in the above data which are NOT managed by the "positions" app? I don't see any particular benefit to renaming everything one thing ('non-mapped position'??) versus introducing lots of container type ('bag position','freezer position', etc. - although that vocabulary seems confusing).

I think that would let us get rid of the "locked_position" flag, which is intended to allow moving movable positions (I have no idea what that is...) and disallow moving things which cannot be moved (wells in a freezer box). That is, all "position" container types would be created and managed entirely by the "position" app.

Someone mentioned a need for flexibility in mapped positions. We could accomplish that by removing number_positions from table container, and replacing it with three new fields:

  • number_rows (NUMBER)
  • number_columns (NUMBER)
  • orientation (horizontal, vertical)

so a number_rows=2,number_columns=3,orientation=horizontal container would map

1--2--3
4--5--6

and a number_rows=2,number_columns=3,orientation=vertical container would hold map

1--3--5
2--4--6

I could then rebuild the position form to be entirely dynamic, built from data in the parent container (eg, freezer box), rather than the current few preconfigured options.

Thoughts?

Freezer boxes with barcodes positions:

select 
  distinct c.barcode box_barcode
from
  container c,
  container p
where
  p.parent_container_id=c.container_id and
  p.container_type='position' and
  c.container_type='freezer box' and
  c.barcode is not null and
  p.barcode is not null
 12  ;

BOX_BARCODE
------------------------------------------------------------------------------------------------------------------------
C56455
C56452
C56454
C56456
C56457
C56458
C56451

7 rows selected.

Bags with positions

select 
  distinct c.barcode box_barcode
from
  container c,
  container p
where
  p.parent_container_id=c.container_id and
  p.container_type='position' and
  c.container_type='bag' 
 10  ;

BOX_BARCODE
------------------------------------------------------------------------------------------------------------------------
C57219
C56056
C56926
C56860
C57355
Function-ContainerOrBarcode Help wanted
Source
picture dustymc
👍1

Most helpful comment

positions form we could use for non-cryovials,

Let's fix that too. Right now that's hard-coded in to the form - positions in freezer boxes hold cryovials, positions in slide boxes hold slides, etc. Unless someone stops me, I'll add another new field:

  • positions_hold_container_type-->FKEY ctcontainer_type

Which will allow..

  • parent_container (where everything else about the positions is set)

    • position



      • whatever you entered in positions_hold_container_type



That'll still prevent the kiddos from scanning a room into a freezer, but it'll let you determine the purpose of a box. If you want to dedicate a random freezer box to vials (or whatever), you can. It'll also make the code a little more robust.

picture dustymc on 7 Nov 2018
👍2

All 45 comments

So those freezer boxes with barcodes are racks and the bags with positions are boxes. I'm going to go clean them up right now.

I like the flexibility option!

Not sure I understand all of: "There's some code around container type "position" so I have a slight preference for keeping that. Can we identify and rename the positions in the above data which are NOT managed by the "positions" app? I don't see any particular benefit to renaming everything one thing ('non-mapped position'??) versus introducing lots of container type ('bag position','freezer position', etc. - although that vocabulary seems confusing).

I think that would let us get rid of the "locked_position" flag, which is intended to allow moving movable positions (I have no idea what that is...) and disallow moving things which cannot be moved (wells in a freezer box). That is, all "position" container types would be created and managed entirely by the "position" app."

But sure!

KyndallH picture KyndallH on 18 Oct 2018

I like the flexibility option!

I do too, but it would be some more work when creating containers. I could probably deal with much of that with some sort of canned option, but you'd need to fill in three fields instead of 1 when you're making some new funky-shaped freezer. The tradeoff is that your new funky-shaped freezer would immediately work in the "positions" form.

The rest of it is mostly me struggling with vocabulary - ^^ is the important thing, we can come back here when it's resolved.

dustymc picture dustymc on 18 Oct 2018
👍1

Speaking of positions and flexibility: can I get barcodes 396828 - 396841 switched from cryovial to position? Due to all the position rules, I cannot change them. They are slots/positions in my freezer rack.

A smidge more work when creating containers would be fine with me. We can work on vocab - that is a minor problem.

Thanks!

KyndallH picture KyndallH on 18 Oct 2018

I very much like the flexibility option also.
Dusty, can you clarify what you need regarding the other positions? We can
eventually get rid of the physically barcoded freezer rack and box
positions once we have the new form. Ditto for shelf and range case, maybe

  • although I may need to keep some of those (in mammal and parasite wet
    collections, which I have less control over.) What do you mean by the
    positions app?
    I'm wondering whether we need to have such stringent restrictions on
    editing positions such as Kyndall describes?

On Thu, Oct 18, 2018 at 1:18 PM Kyndall Hildebrandt <
[email protected]> wrote:

Speaking of positions and flexibility: can I get barcodes 396828 - 396841
switched from cryovial to position? Due to all the position rules, I cannot
change them. They are slots/positions in my freezer rack.

A smidge more work when creating containers would be fine with me. We can
work on vocab - that is a minor problem.

Thanks!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/1743#issuecomment-431128401,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOH0hG9oeK6TtZNA8gTgRSYicelWY0s1ks5umNQfgaJpZM4XieXH
.

campmlc picture campmlc on 18 Oct 2018

First thing I need is some direction - is this enough of a consensus to proceed with...

three new fields:

number_rows (NUMBER)
number_columns (NUMBER)
orientation (horizontal, vertical)

?

Second thing I'll need is terminology. Can I have "position" for "grid-map thing", and if so what do we do with the "positions" that have barcodes? Or I could use a new term for grid-mapped things and ya'll can keep "position" for stuff that doesn't use the position form - that option is a bit more work, but might be worth it.

"The position form" is accessed by...

screen shot 2018-10-18 at 1 59 04 pm

and (for 10x10 horizontal freezer boxes) looks like this...

screen shot 2018-10-18 at 1 59 26 pm

Those holes with cryovial-barcodes in them are what I've been calling "grid-mapped positions" for lack of better vocabulary.

I think that scanning paired barcodes (eg, barcode on a freezer box into the barcode on a rack-slot) most always results in better data, and I will not remove that option. (But we might have to call those something other than "positions.") This will just make treating racks like freezer boxes possible; it won't require that. There's no reason to run out and peel off any barcodes! (Well, there might be - you're probably going to end up needing two procedures and two forms to put boxes in racks.)

The grid-map forms absolutely rely on predictable data, and we absolutely have to have stringent restrictions on doing stuff with the containers that are managed through those forms. That's much of the reason we need to separate "positions" which are managed through the grid-form and "positions" which are just random things that someone's called "position" for some reason.

dustymc picture dustymc on 18 Oct 2018

Kyndall and I and probably Teresa support

three new fields:

number_rows (NUMBER)
number_columns (NUMBER)
orientation (horizontal, vertical)

If I understand correctly, this tool is NOT going to create a grid map
thing? Or is it? I'm confused.

Terminology

Can the grid map things be just "position" and anything anyone creates
outside of an auto grid would be "freezer box position" or "freezer
rack" position, or "shelf position" etc ?

I want to minimize the part path language for 1 million some odd
cryovial positions in the grid. I assume other positions will be less
ubiquitous.

Also, if we have a grid thing to create box and rack positions as well
as cryovial positions, can we make sure that we can use "move all
children of this container to barcode _______" and have that work?

On Thu, Oct 18, 2018 at 3:14 PM dustymc notifications@github.com wrote:

First thing I need is some direction - is this enough of a consensus to
proceed with...

three new fields:

number_rows (NUMBER)
number_columns (NUMBER)
orientation (horizontal, vertical)

?

Second thing I'll need is terminology. Can I have "position" for "grid-map
thing", and if so what do we do with the "positions" that have barcodes? Or
I could use a new term for grid-mapped things and ya'll can keep "position"
for stuff that doesn't use the position form - that option is a bit more
work, but might be worth it.

"The position form" is accessed by...

[image: screen shot 2018-10-18 at 1 59 04 pm]
https://user-images.githubusercontent.com/5720791/47183884-01d35580-d2de-11e8-8a05-54a063643b6e.png

and (for 10x10 horizontal freezer boxes) looks like this...

[image: screen shot 2018-10-18 at 1 59 26 pm]
https://user-images.githubusercontent.com/5720791/47183907-11529e80-d2de-11e8-957a-0f592f4a3942.png

Those holes with cryovial-barcodes in them are what I've been calling
"grid-mapped positions" for lack of better vocabulary.

I think that scanning paired barcodes (eg, barcode on a freezer box into
the barcode on a rack-slot) most always results in better data, and I will
not remove that option. (But we might have to call those something other
than "positions.") This will just make treating racks like freezer boxes
possible; it won't require that. There's no reason to run out and peel off
any barcodes! (Well, there might be - you're probably going to end up
needing two procedures and two forms to put boxes in racks.)

The grid-map forms absolutely rely on predictable data, and we absolutely
have to have stringent restrictions on doing stuff with the containers that
are managed through those forms. That's much of the reason we need to
separate "positions" which are managed through the grid-form and
"positions" which are just random things that someone's called "position"
for some reason.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/1743#issuecomment-431164297,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOH0hOxZ18UHYeV3n4ulKDEYUswb_G35ks5umO8hgaJpZM4XieXH
.

campmlc picture campmlc on 18 Oct 2018

this tool is NOT going to create a grid map

That's exactly what it's for. Get a new giant (whatever) tomorrow, edit container, rows=317 columns=847, orientation=vertical and the grid-map thing will auto-create 268499 positions and display them as 268499 boxes with "1" in the top-left corner and "2" right underneath. (The alternative is writing code for every type of container that contains grid-mapped positions - where we are now.)

grid map things be just "position" and anything anyone creates outside of an auto grid would be ... etc ?

That makes it easy for me, if it works for ya'll.

"move all children of this container to barcode _______" and have that work?

That should work now, and nothing about this will change it. Give me an example of something that doesn't work and maybe I can make better errors or something.

dustymc picture dustymc on 18 Oct 2018

Works for me.

I also like the terminology "grid-mapped positions" and we can use "barcoded positions" for the other. Or simply positions.

KyndallH picture KyndallH on 19 Oct 2018

Given the following, I prefer "position" as shorter and clearer
(freezer box)←[ ] 2 (position)←[ A76LM ] NK 26914 L (cryovial)

On Thu, Oct 18, 2018 at 4:57 PM Kyndall Hildebrandt <
[email protected]> wrote:

Works for me.

I also like the terminology "grid-mapped positions" and we can use
"barcoded positions" for the other. Or simply positions.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/1743#issuecomment-431191163,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOH0hJ_L42FUt8RwsxjIsIxGTQSU80FRks5umQdGgaJpZM4XieXH
.

campmlc picture campmlc on 19 Oct 2018

I think Dusty needs two terms: one to describe positions without barcodes as in your grid system and one with positions that have a barcode as in my system.

KyndallH picture KyndallH on 19 Oct 2018

But you and I both have "positions" in the cryovial form. That's the one
I'd like to just keep as "positions" because there are so many of them,
plus anything else we create using the grid system/without barcode system.
We could be more explicit for everything else.

On Thu, Oct 18, 2018 at 5:25 PM Kyndall Hildebrandt <
[email protected]> wrote:

I think Dusty needs two terms: one to describe positions without barcodes
as in your grid system and one with positions that have a barcode as in my
system.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/1743#issuecomment-431196578,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOH0hCfs7S0sQC1XYTbDrXXv0Pv2XWbpks5umQ3xgaJpZM4XieXH
.

campmlc picture campmlc on 19 Oct 2018

two terms:

yup

1) a container type that can only be created by the positions form, can't have barcodes, can't be moved, etc.
2) something to do with the other stuff we currently call "position"

If it's more or less arbitrary I'll use "position" for the things without barcodes - that'll let me reuse a bit more code, and I think we're more used to thinking of them as the weird thing.

@KyndallH barcodes 396828 - 396841 are now positions.

dustymc picture dustymc on 19 Oct 2018
👍1

Ok

On Thu, Oct 18, 2018, 6:12 PM dustymc notifications@github.com wrote:

two terms:

yup

  1. a container type that can only be created by the positions form,
    can't have barcodes, can't be moved, etc.
  2. something to do with the other stuff we currently call "position"

If it's more or less arbitrary I'll use "position" for the things without
barcodes - that'll let me reuse a bit more code, and I think we're more
used to thinking of them as the weird thing.

@KyndallH https://github.com/KyndallH barcodes 396828 - 396841 are now
positions.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/1743#issuecomment-431204334,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOH0hFjKB86wiUxSqOl41qRXYRxCtORoks5umRjngaJpZM4XieXH
.

campmlc picture campmlc on 19 Oct 2018

This sounds awesome and I am ready to start using it yesterday!

Jegelewicz picture Jegelewicz on 19 Oct 2018

OK, let's do this. Lacking immediate feedback, I'll keep "position" for the special container type.

Positions will:

  • be created only by the position app (from data in the parent container)
  • not be movable
  • not be editable
  • not be permitted barcodes

Anything with a barcode cannot be a position in that model. I'm going to start with the assumption that any position which does not have a barcode should remain a position. Here's the current summary:

CONTAINER_TYPE                           POSNHASBA      C
------------------------------------------------------------ --------- ----------
cabinet                              yes           26
freezer                              no           114
freezer                              yes          854
freezer box                          no        904360
freezer box                          yes           14
freezer rack                             no            81
freezer rack                             yes        10280
microplate                           yes           96
range case                           yes         1744
shelf                                yes           64
slide box                            no         44999

Barcoded positions will be changed into new container types of "{parent container type} position" - so "cabinet position" for the cabinets etc.

I don't believe the barcoded "freezer box" positions - I'll change them to legacy (which will LOCK them) unless I hear something else.

dustymc picture dustymc on 6 Nov 2018

We do have barcoded freezer box positions that we created by actually
barcoding slots in a rack - not an easy thing to do- because we had no
alternative. These could be changed to "rack positions" as for the other
"parent container type" positions, and I will gradually phase them out.

On Tue, Nov 6, 2018 at 9:25 AM dustymc notifications@github.com wrote:

OK, let's do this. Lacking immediate feedback, I'll keep "position" for
the special container type.

Positions will:

  • be created only by the position app (from data in the parent
    container)
  • not be movable
  • not be editable
  • not be permitted barcodes

Anything with a barcode cannot be a position in that model. I'm going to
start with the assumption that any position which does not have a barcode
should remain a position. Here's the current summary:

CONTAINER_TYPE POSNHASBA C

cabinet yes 26
freezer no 114
freezer yes 854
freezer box no 904360
freezer box yes 14
freezer rack no 81
freezer rack yes 10280
microplate yes 96
range case yes 1744
shelf yes 64
slide box no 44999

Barcoded positions will be changed into new container types of "{parent
container type} position" - so "cabinet position" for the cabinets etc.

I don't believe the barcoded "freezer box" positions - I'll change them to
legacy (which will LOCK them) unless I hear something else.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/1743#issuecomment-436315060,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOH0hNBeJRqzWz_LZffk_Lpa1-RRo2bwks5usbfmgaJpZM4XieXH
.

campmlc picture campmlc on 6 Nov 2018

OK, let's do this.

Jegelewicz picture Jegelewicz on 6 Nov 2018
👍1

The parent container type is "freezer box" - these data say you have barcodes inside of freezer boxes.

Barcoded positions in a freezer rack will (unless someone tells me something else in the very near future) become "freezer rack position." We have lots of those, they're fine. 


select 
  c.container_type,
  c.barcode parent_barcode,
  p.barcode position_barcode
from
  container c,
  container p
where
  p.parent_container_id=c.container_id and
  p.container_type='position' and
  p.barcode is not null and
  c.container_type='freezer box'
 13   ;

CONTAINER_TYPE
------------------------------------------------------------
PARENT_BARCODE
------------------------------------------------------------------------------------------------------------------------
POSITION_BARCODE
------------------------------------------------------------------------------------------------------------------------
freezer box
C56458
C57027

freezer box
C56458
C57023

freezer box
C56458
C57024

freezer box
C56458
C57025

freezer box
C56458
C57026

freezer box
C56458
C57028

freezer box
C56458
C57029

freezer box
C56458
C57030

freezer box
C56458
C57031

freezer box
C56458
C57032

freezer box
C56458
C57033

freezer box
C56458
C57034

freezer box
C56458
C57035

freezer box

A6XD1
dustymc picture dustymc on 6 Nov 2018

Ah yes, these are actually glass vials of parasites that are stored in
freezer boxes. Most are scanned directly into the box, because we had no
positions form we could use for non-cryovials, until recently. Then
Adrienne managed to find a way to scan those vials into position using the
form, something we've needed for a long time. I figured it would break
something, but it worked. The only difference between them and cryovials is
that they are glass and slightly larger, and they are called "vials"
instead of "cryovials".

On Tue, Nov 6, 2018 at 9:44 AM dustymc notifications@github.com wrote:

The parent container type is "freezer box" - these data say you have
barcodes inside of freezer boxes.

Barcoded positions in a freezer rack will (unless someone tells me
something else in the very near future) become "freezer rack position." We
have lots of those, they're fine.

select
c.container_type,
c.barcode parent_barcode,
p.barcode position_barcode
from
container c,
container p
where
p.parent_container_id=c.container_id and
p.container_type='position' and
p.barcode is not null and
c.container_type='freezer box'
13 ;

CONTAINER_TYPE

PARENT_BARCODE

POSITION_BARCODE

freezer box
C56458
C57027

freezer box
C56458
C57023

freezer box
C56458
C57024

freezer box
C56458
C57025

freezer box
C56458
C57026

freezer box
C56458
C57028

freezer box
C56458
C57029

freezer box
C56458
C57030

freezer box
C56458
C57031

freezer box
C56458
C57032

freezer box
C56458
C57033

freezer box
C56458
C57034

freezer box
C56458
C57035

freezer box

A6XD1

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/1743#issuecomment-436322218,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOH0hPWd9TAJM_trQ5YHv_XWPsJaMAFmks5usbxVgaJpZM4XieXH
.

campmlc picture campmlc on 6 Nov 2018

Those are not what I'm looking at. There are positions inside of freezer boxes which claim to have barcodes. Things scanned directly into a box will not involve positions. The contents of the positions doesn't matter. I'm __only__ looking at positions.

dustymc picture dustymc on 6 Nov 2018

Can you send an example? Which collection?

On Tue, Nov 6, 2018 at 10:08 AM dustymc notifications@github.com wrote:

Those are not what I'm looking at. There are positions inside of freezer
boxes which claim to have barcodes. Things scanned directly into a box will
not involve positions. The contents of the positions doesn't matter. I'm
only looking at positions.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/1743#issuecomment-436330988,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOH0hG5EFCuQ-YSv8-VWjZi8_mcHlMh4ks5uscH5gaJpZM4XieXH
.

campmlc picture campmlc on 6 Nov 2018

https://github.com/ArctosDB/arctos/issues/1743#issuecomment-436322218

dustymc picture dustymc on 6 Nov 2018

I fixed A6XD1. Someone managed to add a barcode to a position instead of to
a cryovial.

Looks like Alaska has the C57035 series barcodes. Something recent, as they
are still in the universe.

On Tue, Nov 6, 2018 at 10:11 AM dustymc notifications@github.com wrote:

1743 (comment)

https://github.com/ArctosDB/arctos/issues/1743#issuecomment-436322218

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/1743#issuecomment-436332022,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOH0hM0qBkPUqe_AQynyCV1uMKovEGZwks5uscKxgaJpZM4XieXH
.

campmlc picture campmlc on 6 Nov 2018

@KyndallH

campmlc picture campmlc on 6 Nov 2018

That is correct BUT it isn't in a freezer box. It is in a rack. I'll go ahead and fix those.

KyndallH picture KyndallH on 7 Nov 2018

I can't deal with disagreement between number_positions and actual positions. Here are mismatched freezers.

Per https://github.com/ArctosDB/arctos/issues/1729 I will change 33-position freezers to

  • number_rows=11

    • number_columns=3

    • orientation=vertical

and 48 to

  • number_rows=12

    • number_columns=4

    • orientation=vertical

I'll need instructions for handling anything else. If I don't get this soonish I'll just NULL the mapping and convert the existing positions to "freezer positions" and we can deal with it later.

select * from (
select distinct 
p.barcode,
p.NUMBER_POSITIONS,
count(c.container_id) numberActualPositions
from
container p, 
container c 
where 
p.container_id=c.parent_container_id and
c.container_type='position' and
p.container_type='freezer'
group by
p.NUMBER_POSITIONS,
p.barcode
)
where NUMBER_POSITIONS != numberActualPositions
;

BARCODE
------------------------------------------------------------------------------------------------------------------------
NUMBER_POSITIONS NUMBERACTUALPOSITIONS
---------------- ---------------------
LN2FRZR7
          38            37

LN2FRZR3
          26            38

FRZR5
          48            95

LN2FRZR2
          26            38

LN2FRZR1
          26            38
dustymc picture dustymc on 7 Nov 2018

positions form we could use for non-cryovials,

Let's fix that too. Right now that's hard-coded in to the form - positions in freezer boxes hold cryovials, positions in slide boxes hold slides, etc. Unless someone stops me, I'll add another new field:

  • positions_hold_container_type-->FKEY ctcontainer_type

Which will allow..

  • parent_container (where everything else about the positions is set)

    • position



      • whatever you entered in positions_hold_container_type



That'll still prevent the kiddos from scanning a room into a freezer, but it'll let you determine the purpose of a box. If you want to dedicate a random freezer box to vials (or whatever), you can. It'll also make the code a little more robust.

dustymc picture dustymc on 7 Nov 2018
👍2

These are freezer racks with a mismatch of unbarcoded positions. As with freezers, I'll convert them to "freezer rack position" if they're not cleaned up by the time I get to production.

```select * from (
select distinct
p.container_id,
p.barcode,
p.institution_acronym,
p.NUMBER_POSITIONS,
count(c.container_id) numberActualPositions
from
container p,
container c
where
p.container_id=c.parent_container_id and
c.container_type='position' and
p.container_type='freezer rack'
group by
p.container_id,
p.NUMBER_POSITIONS,
p.barcode,
p.institution_acronym
)
where NUMBER_POSITIONS != numberActualPositions
22 ;

CONTAINER_ID

BARCODE

INSTITUTION_ACRONYM NUMBER_POSITIONS NUMBERACTUALPOSITIONS

11766658

C55853
UAM 100 13

17206634

C57996
UAM 14 15

 2264445

C05226
UAM 13 12

15863744

C57311
UAM 100 14

15863745

C57312
UAM 100 14

17206635

C57997
UAM 14 13

  766362

C04014
UAM 11 10

 2264444

C05183
UAM 13 15

11767095

C56290
UAM 13 9

15863743

C57310
UAM 100 14

 2264452

C05268
UAM 13 12

11767214

C56409
UAM 9 13

12029911

MVZ4000
MVZ 15 81

17725834

DGR17882
MSB 12 11

11766564

C55759
UAM 100 13

14847229

DGR15780
MSB 12 11

16 rows selected.
```

dustymc picture dustymc on 7 Nov 2018

and freezer box position count mismatch

CONTAINER_ID
------------
BARCODE
------------------------------------------------------------------------------------------------------------------------
INSTITUTION_ACRONYM                      NUMBER_POSITIONS NUMBERACTUALPOSITIONS
------------------------------------------------------------ ---------------- ---------------------
    14848602
DGR17153
MSB                                   100            99

      753024
C44007
UAM                                    81           100

    14243919
BIRD 116
MVZ                                    81           162

    14845739
DGR14243
MSB                                   100           200

    14845821
DGR14325
MSB                                   100           200

    14850461
DGR19012
MSB                                   100           200

    16349747
DGR15751
MSB                                   100           300

    14238210
BIRD 115
MVZ                                    81           162

    14850493
DGR19044
MSB                                   100           200

    14850528
DGR19079
MSB                                   100           200

    14850556

MSB                                   100           200

    14849697

MSB                                   100           200

    14849707

MSB                                   100           200


13 rows selected.
dustymc picture dustymc on 7 Nov 2018

How come LN2FRZR4-LN2FRZR6 didn't show up?

As for LN2 cryovats, the layout may be difficult.

img_8363

KyndallH picture KyndallH on 7 Nov 2018

If they have barcodes, they can't be positions in the model we're aiming for - they'll be "freezer position"s (or similar) and I won't do anything except change the container type.

dustymc picture dustymc on 7 Nov 2018

Got it. Okay, I'll work on cleaning up those with mismatch # positions.

KyndallH picture KyndallH on 7 Nov 2018

Thanks for this! I'll work on the DGR issues.

On Wed, Nov 7, 2018 at 8:47 AM dustymc notifications@github.com wrote:

positions form we could use for non-cryovials,

Let's fix that too. Right now that's hard-coded in to the form - positions
in freezer boxes hold cryovials, positions in slide boxes hold slides, etc.
Unless someone stops me, I'll add another new field:

  • positions_hold_container_type-->FKEY ctcontainer_type

Which will allow..

  • parent_container (where everything else about the positions is set)

    • position



      • whatever you entered in positions_hold_container_type



That'll still prevent the kiddos from scanning a room into a freezer, but
it'll let you determine the purpose of a box. If you want to dedicate a
random freezer box to vials (or whatever), you can. It'll also make the
code a little more robust.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/1743#issuecomment-436669421,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOH0hCgUnyOVvQ83vF3C0KNZpogIlFPPks5uswCIgaJpZM4XieXH
.

campmlc picture campmlc on 7 Nov 2018

I need one of the positions moved to a different freezer rack. It won't let me move it so I'll need you to do it. Thanks!

Parent --> Child
C57997 --> 396730

KyndallH picture KyndallH on 7 Nov 2018

UAM@ARCTOS> update container set parent_container_id=(select container_id from container where barcode='C57997') where barcode='396730';

1 row updated.

dustymc picture dustymc on 7 Nov 2018

In the case of DGR17882, this rack has barcoded positions, but the boxes
were scanned in directly to the rack alongside the positions, not in them.
I can take the time right now to scan them all into the existing positions
but there are probably many more of these and I'd rather do it all at once
via a csv load. Will it break anything if I leave them and let them get
autoconverted to "freezer box positions" within the rack?
What about situations like rack position DGR12988 containing both freezer
rack DGR16575 with boxes scanned into barcoded positions and freezer
box DGR13404
(not scanned into position). This freezer is a big mess from the NEON
accession, worked on by many different students, and needs to be rescanned.
Again, can I leave as is and redo once we have the positions form, or does
it need to be resolved now?

On Wed, Nov 7, 2018 at 1:23 PM Kyndall Hildebrandt notifications@github.com
wrote:

I need one of the positions moved to a different freezer rack. It won't
let me move it so I'll need you to do it. Thanks!

Parent --> Child
C57997 --> 396730

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/1743#issuecomment-436764518,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOH0hP-JiwWthencMhLW33L-B6ZFYiHdks5us0E5gaJpZM4XieXH
.

campmlc picture campmlc on 7 Nov 2018

I don't need anything now, except to isolate the 'true positions' which I can do by renaming stuff that's somehow funky. I think worst-case would involve deleting the rack and starting over, which should just be a ~dozen scans, and that shouldn't really be necessary. There will be no possibility of data being lost in this - whatever you're doing now will work at least as well as now when I'm done. I'll be relaxing the constraints on moving "% positions" (eg, not-positions that just happen to have the word 'position' in the container type) and hardening the constraints on moving "position" container types so that might even be easier to clean up after this is done.

dustymc picture dustymc on 7 Nov 2018

Fixed all of UAMs except a few I need you to fix.

Move Parent --> Child
C05226 --> C05234
C05268 --> c05281

For FRZR5, I need you to delete the positions that are numerical (1, 2, 3, etc.) and keep the FRZR5-1D, etc. barcodes/positions.

Thanks!

KyndallH picture KyndallH on 7 Nov 2018

I uppercased your c and

update container set parent_container_id=(select container_id from container where barcode='C05226') where barcode='C05234';
update container set parent_container_id=(select container_id from container where barcode='C05268') where barcode='C05281';
delete from container where parent_container_id=(select container_id from container where barcode='FRZR5') and is_number(label)=1 ;

dustymc picture dustymc on 7 Nov 2018

This is more or less functional - small components may be down for (hopefully!) short periods of time, but the big picture should now be in place. Please test and report anything you manage to break.

Edit container (and bulkloaders and etc.) have a new position layout - number_positions and locked_position have been replaced by


 NUMBER_ROWS                                    NUMBER
 NUMBER_COLUMNS                                 NUMBER
 ORIENTATION                                    VARCHAR2(25)
 POSITIONS_HOLD_CONTAINER_TYPE                          VARCHAR2(25)

All positions are now locked - it should not be possible to create them except by using the positions form, nor to alter them except by moving them to an empty parent with an identical layout.

All non-positions (including eg, "freezer position") act like any other container type. Former "position" container types have been migrated to new "[parent container type] position" containers.

There are now no assumptions regarding what types of containers may hold positions nor what those positions may hold - that's all pulled from data in the parent.

screen shot 2018-11-14 at 10 03 27 am

Some of my test subjects:

http://arctos-test.tacc.utexas.edu/findContainer.cfm?container_id=129036
http://arctos-test.tacc.utexas.edu/findContainer.cfm?barcode=103165
http://arctos-test.tacc.utexas.edu/findContainer.cfm?container_id=17206034
http://arctos-test.tacc.utexas.edu/findContainer.cfm?barcode=C57397

dustymc picture dustymc on 14 Nov 2018

Test looks good to me! I think the best thing is the table font size! Granted, you can also just zoom in on your computer screen but I love it because I so need it!

KyndallH picture KyndallH on 14 Nov 2018

table font size

I tried; http://arctos-test.tacc.utexas.edu/containerPositions.cfm?container_id=17206037 still doesn't fit...

dustymc picture dustymc on 14 Nov 2018

I'm having difficulty breaking things now, which often just means I'm pushing the wrong buttons. This should go to production early next week; PLEASE test ASAP if at all possible.

dustymc picture dustymc on 16 Nov 2018

I will try to test on Sunday when I am home.

Jegelewicz picture Jegelewicz on 16 Nov 2018

done

dustymc picture dustymc on 28 Nov 2018
Was this page helpful?
0 / 5 - 0 ratings

Related issues

acdoll picture acdoll  ·  8Comments
AJLinn picture AJLinn  ·  3Comments
dustymc picture dustymc  ·  6Comments
DerekSikes picture DerekSikes  ·  3Comments
mkoo picture mkoo  ·  3Comments