Multi-Slit & PEPPERPOT

PEPPERPOT with rectangular slits instead of circles.

With instead I mean actually: in addition

added Feature request label

closed via commit 3ff473cc

@ext-rogers_c is this really fixed with commit 3ff473cc ?

@ext-rogers_c I guess you accidentally closed this issue. I couldn't find any reference to Peppertpots in the commit that closed it.

reopened

Interesting, I see the commit comments can close an issue... I meant to close #59 (closed)!

added ~47 ~48 labels

This is request from Argon that will referd to OPAL 1.9.x, because the actual implementation seams to be sufficient for the moment.

removed ~47 label

changed milestone to %OPAL 1.9.x

assigned to @kraus

On top of the Pepper-Pot we need a multi-slit in order to model an ongoing effort to understand FAST.

Edelen_FAST_slit.pdf

Benchmarking will be provided by Jonathan Edelen jonathan.edelen@gmail.com

assigned to @ext-edelen_a

changed title from PEPPERPOT to Multi-Slit & PEPPERPOT

Why not let the user load a vector graphics file with arbitrary shaped holes?

ok and such a drawing can be easy extracted from any CAD system, however I think a simple parametrisation seams easier to use and implement. One maybe want to play with parameters and does not have a vector graphics available. For optimisation generating these files on-line could be problematic.

I propose to first use a parametric form and in a second step read in graphics.

Then how about describing the pepper pot/multislit/whatever with a functional language like

ellipse(width, height)
rectangle(width, height)
repeat(Obj, Nr, xshift, yshift)
rotate(Obj, angle)
translate(Obj, xshift, yshift)
union(Obj1, Obj2)

A multislit device would then be

repeat(
       translate(
                 rectangle(
                            0.04, 
                            0.002
                 ),
                -0.02, 
                -0.02
       ),
       10, 
        0, 
        0.004
)

A pepperpot with round holes

repeat(
       repeat(
              translate(
                        ellipse(
                                0.002,
                                0.002
                        ),
                        -0.02,
                        -0.02
              ),
              8,
              0.05,
              0
       ),
       8, 
       0,
       0.05
)

This is an awesome idea.

How complicated to implement?

How do we connect this to the coordinate system?

This would be really great. At least for FAST, specifying in this way would be easier than uploading a CAD file

A first version of a standalone parser, which only works if format including whitespaces is followed strictly, is attached. It's currently implented using regex. It would be nice if it used boost spirit. But currently haven't time to (re-)read tutorials and documentation.test.cpp

Hey looks great. How do you indent to implement this? A slit/pepper pot etc. has such a string as an attribute? We then need also need a efficient function for masking out the particles.

My idea is to compute for every rectangle and ellipse the bounding box. If a particle is inside the bounding box then we have to apply a coordinate tansformation to see whether the particle is inside.

A pepperpot with round holes (diameter 0.1 mm, distance in both x and y 0.2 mm [sorry, have no idea whether these numbers are realistic]) will look like this

repeat( // duplicate row of ellipses 100 times and
        // distribute copies evenly in y-direction with distance = 0.2 mm
       repeat( // duplicate ellipse 100 times and 
               // distribute copies evenly in x-direction with distance = 0.2 mm
              translate( // shift ellipse to lower left corner
                        ellipse( // define ellipse with major = minor = 0.1 mm, center = (0, 0)
                                0.0001, 
                                0.0001
                                ), 
                        -0.01, 
                        -0.01
                        ), 
              100, 
              0.0002, 
              0.0
              ), 
       100,
       0.0,
       0.0002
      )

Currently I neglect the information of the periodicity that is introduced when using repeat(...), see in the method apply in the class Repeat. I think the query whether a particle is stopped could be optimized if we would store this information and use a modulo operation to map to one period length. For a single repeat this is easy to implement, but what about multiple nested repeats like in the example above? Does anyone have an information?

Maybe you need to explicitly say that the structure is periodic in a particular dimension.

repeat( // duplicate row of ellipses 100 times and
        // distribute copies evenly in y-direction with distance = 0.2 mm
       repeat( // duplicate ellipse 100 times and 
               // distribute copies evenly in x-direction with distance = 0.2 mm
              translate( // shift ellipse to lower left corner
                        ellipse( // define ellipse with major = minor = 0.1 mm, center = (0, 0)
                                0.0001, 
                                0.0001
                                ), 
                        -0.01, 
                        -0.01
                        ), 
              100, 
              0.0002, 
              0.0
              ), 
       100, is-periodic, 
       0.0,
       0.0002
      )

Just finished implementing the stand-alone parser with 27c49259. Next I'll implement it in the Pepperpot/Multi-slit element.

Wonderful, I would like to contact you with the AWA group @ext-neveu_n who have an experiment running/setup who need Multi-slit elements.

Just pushed a new branch ('flexiblecollimator') to the repository. Multi-slit / pepperpot is implemented but needs lot of work to improve performance. Currently we have to check for every hole and every time step whether a particle passes the hole. In the example above there are 10000 holes. This should be improved for cases where repeat is used

great shall I invoke the ANL folks (@ext-neveu_n and John Power) and @ext-edelen_a for testing on a real example?

with testing I mean: exercise a real example without looking at performance. after that look at the performance.

the push is on the master?

Thanks for all the work on this! I am looking forward to trying a slit example. John is also excited about the pepper pot.

Give me some more time. As written, I pushed into a new branch. I created a new element ('FLEXIBLECOLLIMATOR', suggestions for a better name are welcome), the description of the arrangement of holes can be provided in a file ('FNAME') and the following commands are supported

rectangle(width, height)
ellipse(width, height)
repeat(function_call, N, shiftx, shifty)
translate(function_call, shiftx, shifty)
rotate(function_call, angle)
shear(function_call, anglex, angley)
union(function_call, function_call [, function_call [,...]])

Here the output of a monitor directly after a flexible collimator.

And a detail

Suppe nice, how does the code for this look like?

My suggestion for the name is simply: COLLIMATOR and we then can get rid off all other collimators.

How would you define a slit?

As long as the performance of the code isn't as high as it should we shouldn't call it COLLIMATOR...

As slit?

rectangle(0.1, 0.005)

This slit is centered around y = 0 and has a height of 5 mm.

Well I see your pont, however but in your branch you do not care, or are you afraid that this implementation will never be performant?

Here's the input file and the description of the holes. For the pics above I've used 10 times as many particles.

Update: the input file contained a few errors. Here's the corrected one.

I didn't replace the collimator element but created a new element. I think when using many holes the code can only be fast if we can map the repated holes to the original one and check once whether a particle passes (or not) instead of e.g. 10000 times.

There are algorithms that use trees, i.e. octree (3D) or quadtree (2D), to check collisions. However, I'm not an expert on this. Here's also a discussion mentioning this

https://gamedevelopment.tutsplus.com/tutorials/quick-tip-use-quadtrees-to-detect-likely-collisions-in-2d-space--gamedev-374

Maybe such an algorithm can be applied here.

Here how this could go (maybe very naive):

i. in a domain [-1,1]^2 ([-1,1]^3)

ii. from the algorithmic geometry description create a 2D (3D) discretisation of the material (copper of pepper pot) with M elements (triangles for example).

iii. depending on the accuracy create a tree T of depth d, representing the geometry

iv. N = Ippl::getLocalNum() for i = 1 to N isDead = isInside(R(i),T)

Complexity O( N * log M)

Here some ideas from NVIDIA: https://devblogs.nvidia.com/thinking-parallel-part-i-collision-detection-gpu/

Here what Achim et all made: http://amas.web.psi.ch/people/aadelmann/ETH-Accel-Lecture-1/projectscompleted/semesterwork/herllmueller.pdf (@gsell the followup MSc is missing on our webpage)

Quadtree (or just a grid) came also to my mind but we have the explicit information that we repeat stuff and I'm sure that we can have even better performance if we use this information. I'll try this first and use quadtree as backup solution.

I see that for a regular object such as a pepper pot but what if someone adds changing hole radii or mixes ellipses with circles? I am sure users will do such things if they can.

They'll probably still use repeat to generate the holes.

Maybe we can make use of the information of repetitions and still using more advanced concepts.

Well maybe it's the better idea to follow your advice and implement a general solution. I'm working on it.

Just ran some tests with one million particles and varying number of equidistant holes (pepperpot) once using a naive approach and once with quadtrees.

And here with logarithmic scale

The performance is still not so impressive.

Well but the tree has a kind of nice performance. This is on one core?

Yes one core, one million particles.

For the generation of particles (using rng) and writing approximately half a million particles to disk 0.8 seconds are required. Thus instead of 2.974 seconds the quadtree alone requires approximately 2.2 seconds to sort out those particles that pass (for one million particles, 10201 holes, one core).

The code is now pushed to the repository (still separate branch). Feel free to try it out and post comments / suggestions for improvements.

can you provide an input file, I am compiling now

input file

description holes

It's advantageous to use an odd number of repetitions. A grid of 101 x 101 circles (100 x 100 repetitions), one million particles requires 3.1 seconds to test. A grid of 102 x 102 circles, one million particles only 1.8 seconds. The reason is that less circles are in the coarsest level of the quadtree if the number of circles in each direction is even.

Here a comparison between 20 x 20 repetitions and 21 x 21 repetitions. The first has 20 repetitions both in x- and y-direction. The 21 circles at x = -0.024 and the 21 circles at y = -0.024 (one is counted twice) are assigned to the coarsest level. In the case of 21 repetitions in each direction no circle is in the coarsest level.

Do you also get the same result (naive vs. quadtree)?

description of holes is not a valid link

@adelmann it's now corrected @frey_m is this a question for me or @adelmann?

@kraus My question was directed to your comparison (naive vs. quadtree).