Creating a Register from a specific layout

[HGSilveri]

For multiple reasons, it would be valuable to have register created from an underlying, predefined pattern layout, rather than with arbitrary coordinates.

There are a lot of different things to do here, but the first would be to create the foundational class that stores the layout. We could call it Layout or RegisterLayout and it would store all the coordinates of a layout.

Then, the layout class would enable the creation of a Register from it by specification of the trap indices with which to form the Register itself, with specific constraints like the limitation of <50% of the sites being chosen, so that rearrangement is still possible afterwards.

A method to check whether a layout is compatible with a device should be added too.

An open question is how we will differentiate layouts. We want to have layouts like square and triangular lattices, with different spacings between the atoms, but should these be instances of the same layout class, or child classes that specify the overall layout? To me, the child class approach seems cleaner and it would mimic what is done with the Waveforms.

[LaurentAjdnik]

For multiple reasons, it would be valuable to have register created from an underlying, predefined pattern, rather than with arbitrary classes.

This is gonna be fun 😄!

Would it always be the creation of a Register from scratch?

Or should we be able to add patterns to an existing prefilled register?

Especially if we want to add a first set of patterns then another set of patterns to the same Register.

In fact, more generally, should we have a simple option to merge registers?

[LaurentAjdnik]

the first would be to create the foundational class that stores the pattern. We could call it Pattern or RegisterPattern and it would store all the coordinates of a pattern.

Maybe also an attribute, or different classes inheriteance (Pattern2D, Pattern3D), if some patterns are considered only 2D/3D ?

How would the coordinates be considered ?

• "Bitmap approach" : Absolute values in micrometers, like when creating a register?
• "Vectorial approach" : Relative values (1.0 meaning standard spacing) to which you apply some scaling ratio when instanciating the pattern?

[LaurentAjdnik]

Then, the pattern class would enable the creation of a Register from it by specification of the trap indices with which to form the Register itself

I have the feeling this should be as generic as possible. Either as a method at the very top of the Pattern classes hierarchy, or even as a separate class.

So that Pattern classes remain as simple as possible and do not include any specific methods.

This Factory class should have a generic set of parameters, such as:

• Pattern to be used
• start coordinates (2D or 3D)
• number of pattern repetitions in all dimensions
• scaling ratio
• ...

[LaurentAjdnik]

with specific constraints like the limitation of <50% of the sites being chosen, so that rearrangement is still possible afterwards.

Would that always be necessary? Can't we achieve rearrangement with more sites occupied?

[LaurentAjdnik]

A method to check whether a pattern is compatible with a device should be added too.

What would/could be the set of criteria?

The only ones I can think of right now is:

• the distance between atoms (only if we have a "bitmap" approach)
• the 2D/3D nature

Anyhow, the resulting Register is currently always checked for compatibiliy with the Device, which is the best safeguard.

And this is probably when we will get the most errors (too many atoms, atoms too close or too far way...).

In fact, can't we just create a Register without a reference to a Device? In which case, there is not point in checking for compatibility when instanciating the pattern.

[LaurentAjdnik]

An open question is how we will differentiate patterns. We want to have patterns like square and triangular lattices, with different spacings between the atoms, but should these be instances of the same pattern class, or child classes that specify the overall pattern? To me, the child class approach seems cleaner and it would mimic what is done with the Waveforms.

I do not really see how we could use "instances of the same pattern class" so I would agree with you that "child classes" is the way to go.

Each pattern will be extremely specific. Maybe we'll end up needing an EiffelTowerPattern.

But that raises another question. Let's imagine a RectanglePattern class. If you specify a certain Width and Height, you can always partially adjust this by scaling. But you can not change the ratio between the Width and the Height, unless it becomes a paramater of the pattern. So, in the end, patterns might be more elaborate than just "storing all the coordinates".

[LaurentAjdnik]

One more thought: How exactly would be replicate a pattern?

Let's consider a super-simple SquarePattern that defines 4 atoms on a 2D plane, separated by 1 micrometer.

Let's include this pattern once. Now we have points at, let's say: (0,0) (0,1) (1,0) and (1,1). Thats is bottom-left corner on (0,0).

What if we were to repeat it twice along the x axis? Where would the "bottom-left" corner be for the second square? Said otherwise, how would we determine spacing between the two squares (easy for a human, needs to be clarified for an algorithm).

[LaurentAjdnik]

And finally, after spending the last 45 minutes on this, I realize you never openly mentioned "repeating the pattern" so I might have misunderstood what you meant, haha. But I hope some of the things I wrote still make sense. 😆

[HGSilveri]

Hey @LaurentAjdnik ! Indeed, there seems to be some misunderstanding regarding the concept of Pattern. The idea is that it encompasses all the positions in which you can place the atoms, and then the Register would just be the result of choosing a subset of such positions. So, you make a whole Register out of a single pattern, rather than from combining or repeating patterns

[HGSilveri]

Maybe also an attribute, or different classes inheriteance (Pattern2D, Pattern3D), if some patterns are considered only 2D/3D ?

Yes, I would go for a clear distinction. But perhaps we should stick to just 2D for now in any case, we'll see

How would the coordinates be considered ?

• "Bitmap approach" : Absolute values in micrometers, like when creating a register?
• "Vectorial approach" : Relative values (1.0 meaning standard spacing) to which you apply some scaling ratio when instanciating the pattern?

I would go for the vectorial approach, it's clearly more versatile.

[HGSilveri]

Would that always be necessary? Can't we achieve rearrangement with more sites occupied?

This is related to the need of having a pattern to start with, which I didn't get into here. The pattern is actually representing the positions in space where we are positioning all the optical traps. These traps are then loaded with atoms, and each has ~50% chance of being filled. We then take the atoms we got and move them around to the positions we want them in. So, if you want to prepare a register with N atoms, you need a pattern with at least 2N traps so that, on average, you get the N atoms you need

[HGSilveri]

Anyhow, the resulting Register is currently always checked for compatibiliy with the Device, which is the best safeguard.

And this is probably when we will get the most errors (too many atoms, atoms too close or too far way...).

In fact, can't we just create a Register without a reference to a Device? In which case, there is not point in checking for compatibility when instanciating the pattern.

I agree, the validation of a pattern is not really necessary

[HGSilveri]

I do not really see how we could use "instances of the same pattern class" so I would agree with you that "child classes" is the way to go.

Each pattern will be extremely specific. Maybe we'll end up needing an EiffelTowerPattern.

But that raises another question. Let's imagine a RectanglePattern class. If you specify a certain Width and Height, you can always partially adjust this by scaling. But you can not change the ratio between the Width and the Height, unless it becomes a paramater of the pattern. So, in the end, patterns might be more elaborate than just "storing all the coordinates".

Borrowing your RectanglePattern example, my idea would be to have it parametrized with as little parameters as possible, with a combination of parameters representing a specific set of coordinates. So, RectangularPattern would be the class of recatangular arrays, but what you would use to create a Register from would actually be an instance of RectangularPattern, which we could parametrize as RectangularPattern(width_in_atoms, length_in_atoms, x_spacing, y_spacing). So, RectangularPattern(10, 3, 5., 2.5) would be a specific pattern from which you could pick atoms the atoms to make your Register

[HGSilveri]

And finally, after spending the last 45 minutes on this, I realize you never openly mentioned "repeating the pattern" so I might have misunderstood what you meant, haha. But I hope some of the things I wrote still make sense. 😆

Hahaha yes, there seemed to be some misunderstanding. I replied to the points that I feel still make sense