AutoGrid features

[constantinpape]

I have been thinking a bit more about HCS plates and the autoGrid and I think this doesn't quite fit yet. Take a 4x4 plate: A1, A2, A3, A4, B1, ..., D4 Right now we would specify the grid view like this:

{
autoGrid: {"sources": ["A1", ..., "D4"]}
}

and this would result in the following layout:

A1 A2 A3 A4
B1 B2 B3 B4
C1 C2 C3 C4
D1 D2 D3 D4

but instead we want

A1 A2 B1 B2
A3 A4 B3 B4
C1 C2 D1 D2
C3 C4 D3 D4

[tischi]

I have an idea, omitting " for lazyness:

{
  autoGrid: { sources: [ [A1], [A2], [A3], [A4] ], name: wellA },
  autoGrid: { sources: [ [B1], [B2], [B3], [B4] ], name: wellB },
  autoGrid: { sources: [ [A1,A2,A3,A4], [B1,B2,B3,B4] ], name: coolPlate }
}

For this to work we would need to add some things to the spec, which anyway could make sense:

1. sourceTransformations: are applied in the order given in the JSON
2. autoGrid: grid spacing is the spatial extend of the largest field
3. autoGrid: a field is one item in the sources list
4. autoGrid: the spatial extend of a field is the extend of the union of the sources in the field

I think this would have a bunch of advantages, such as requiring essentially no additional concept, solving the well name issue on the fly, and providing quite some flexibility to design all kind of fancy grid layouts.

cc @martinschorb and @K-Meech who may have more autoGrid use cases in mind.

Regarding the concrete use-case of a multi-well plate a plain autoGrid would not work, because we need to specify the number of rows and columns, e.g. 8 x 12 for a 96 well plate; maybe we could add optional fields to autoGrid: numRows, numColumns (maybe we have them already)?

[constantinpape]

{ autoGrid: { sources: [ [A1], [A2], [A3], [A4] ], name: wellA }, autoGrid: { sources: [ [B1], [B2], [B3], [B4] ], name: wellB }, autoGrid: { sources: [ [A1,A2,A3,A4], [B1,B2,B3,B4] ], name: coolPlate } }

I think this is a bit confusing, because in our current spec this would mean that A1, A2, A3 and A4 are at the same grid position in the "coolPlate" grid. How about allowing nesting the grids like this:

{
   autoGrid: { sources: [ [A1], [A2], [A3], [A4] ], name: wellA },
   autoGrid: { sources: [ [B1], [B2], [B3], [B4] ], name: wellB },
   autoGrid: { sources: [ wellA], [wellB] ], name: coolPlate }
}

• sourceTransformations: are applied in the order given in the JSON

Yes, this should def. be part of the spec.

• autoGrid: grid spacing is the spatial extend of the largest field

• autoGrid: a field is one item in the sources list

• autoGrid: the spatial extend of a field is the extend of the union of the sources in the field

If I understand your suggestion here correctly this again clashes with having multiple sources at the same grid position (which we need to support).

Regarding the concrete use-case of a multi-well plate a plain autoGrid would not work, because we need to specify the number of rows and columns, e.g. 8 x 12 for a 96 well plate; maybe we could add optional fields to autoGrid: numRows, numColumns (maybe we have them already)?

Not part of the spec yet, but we should def. add it. Note that both numRows and numColumns is redundant though, because given the number of grid positions one determines the other, so I would suggest that we only include one in the spec.

[tischi]

I think this is a bit confusing, because in our current spec this would mean that A1, A2, A3 and A4 are at the same grid position in the "coolPlate" grid.

Maybe we have to zoom to discuss in more detail, but I will try ;-)

The way I am thinking about what autoGrid could be doing is the following:

1. It leaves all the sources in the first field where they are.
2. It shifts all the sources in the second field to the right, by the grid spacing.
3. a.s.o

That means if the sources that are part of the second field are already arranged somehow (e.g. by some preceding transformations), their relative position would not be changed, because they are all translated by the same amount. So it would behave like what you propose in your suggestion with referring to the wellA.

Your proposal is easier to read, but it requires more internal logic, because I have to keep track which sources have been modified together in proceeding transformations and the names of the sourceTransformations become a requirement, which would no be the case for my proposal where the names would be optional. Also if feel with my proposal one would be more flexible, but maybe also more confusing and no use cases for this.

I am not sure, I think both versions have their merit (currently I am in fact leaning a bit towards your solution). Maybe let's wait what @martinschorb and @K-Meech think.

If I understand your suggestion here correctly this again clashes with having multiple sources at the same grid position (which we need to support).

I don't think so, e.g.

{
  autoGrid: { sources: [ [A1,X1], [A2], [A3], [A4] ], name: wellA },
  autoGrid: { sources: [ [B1], [B2], [B3], [B4] ], name: wellB },
  autoGrid: { sources: [ [X1,A1,A2,A3,A4], [B1,B2,B3,B4] ], name: coolPlate }
}

Here A1 and X1 will be at the same position in space.

[tischi]

One thing with your current proposal would be that we would need to require that sourceTransform names MUST NOT be identical to source names ;-)

Or there could be a logic that the code always first tries to see whether the specified name corresponds to the name of a preceding sourceTransform; if yes, it will transform all the sources specified there; if no, in a second attempt sees whether this is the name of a source and then transform only that single source.

[constantinpape]

Maybe we have to zoom to discuss in more detail, but I will try ;-)

I see, I think I understand your proposal now. Indeed, I think what I proposed is more readable, but it needs additional logic, because gridTransforms can now also be passed names of other grid transforms, whereas your proposal makes due with only passing source names.

Let's discuss details on zoom, maybe we have some time for this in or after the meeting tomorrow.

[tischi]

I actually feel that maybe we have to support my "proposal" (or something similar) in a sense that it is not really a new proposal but just a needed detailed specification of autoGrid. Because if we have such cases...

autoGrid: { sources: [ [A1,A2], [B1] ], name: coolPlate }

...where, e.g., the sources A1 and A2 happen to not be at the same physical location before the autoGrid. Then what should we do? We could move them to the same location during the autoGrid, but which location would that be? We would need to specify.

Thus, I currently think, maybe we could support "my proposal" anyway and possibly also support your proposal as a sort of convenience that allows to specify groups of sources by the name of a sourceTransformation.

[constantinpape]

From discussion with @tischi: we will implement this proposal https://github.com/mobie/mobie.github.io/issues/24#issuecomment-808729572, i.e. grid will "just" apply offsets to the sources according to the grid spacing (which is determined from the largest source at any grid position).