Allocate big arrays with the minimum number of slot (particle, number of elements)

[kyrsjo]

Maybe make this part of the daten module?

[JamesMolson]

The fluka coupling needs nele increasing, so it would be good to attack this issue.

The alternative is extra layers of +if / +ei statements.

everything that touches

• nele
• nblo
• nblz
• nzfz
• npart

probably should be hit with the allocate hammer.

[amereghe]

for info: for the coupling, the standard settings are:

+if .not.bignblz
      parameter(nele=6000,nblo=2500,nper=2,nelb=140,nblz=50000,         &
     &nzfz = 500000,mmul = 20)
+ei

Moreover, the high value of nele is actually needed by the online aperture checking, not by the fluka coupling... the fluka coupling would need to double the markers of the collimators, whereas for the online aperture checking you pay a lot the region of the separation dipoles...

[rdemaria]

Is it technically possible to increase dynamically the array size?

On Wed, Nov 15, 2017 at 5:35 PM Alessio Mereghetti notifications@github.com wrote:

for info: for the coupling, the standard settings are:

+if .not.bignblz parameter(nele=6000,nblo=2500,nper=2,nelb=140,nblz=50000, & &nzfz = 500000,mmul = 20) +ei

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SixTrack/SixTrack/issues/250#issuecomment-344650300, or mute the thread https://github.com/notifications/unsubscribe-auth/AADUYZCqMy-GbdqR4suFYQz4r70pmRQXks5s2xLZgaJpZM4NAK1M .

[amereghe]

in the mod_fluka.f90 module we allocate some arrays based on parameters passed through the TCP/IP, so it is technically feasible

[kyrsjo]

We actually use several dynamic arrays in SixTrack - take for example DYNK, which is now completely dynamic, and parts of NAFF which also uses ALLOCATE. DATAMODS is basically just one big ALLOCATE.

In SixTrackV_dev I am slowly making some of the main +cd blocks into modules, which will make it possible to make the arrays allocatable. The question is rather when to allocate them, this will require some rethinking of DATEN, as the array sizes will depend on how much we read from there - however something similar to what @vkbo did in DYNK (basically implementing C++ vectors) may be one good option.

I'm getting there...

[rdemaria]

Did @vkbo https://github.com/vkbo use move_alloc or something different? Ideally a "c++ vector"-like is the correct data structure, I am wondering if fortran allows it without rewriting many things.

On Mon, Nov 20, 2017 at 10:56 PM Kyrre Ness Sjøbæk notifications@github.com wrote:

We actually use several dynamic arrays in SixTrack - take for example DYNK, which is now completely dynamic, and parts of NAFF which also uses ALLOCATE. DATAMODS is basically just one big ALLOCATE.

In SixTrackV_dev I am slowly making some of the main +cd blocks into modules, which will make it possible to make the arrays allocatable. The question is rather when to allocate them, this will require some rethinking of DATEN, as the array sizes will depend on how much we read from there - however something similar to what @vkbo https://github.com/vkbo did in DYNK (basically implementing C++ vectors) may be one good option.

I'm getting there...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SixTrack/SixTrack/issues/250#issuecomment-345844979, or mute the thread https://github.com/notifications/unsubscribe-auth/AADUYVwscRcgP2eDLeUZHh50h2rJrvZ3ks5s4fWLgaJpZM4NAK1M .

[kyrsjo]

Move_alloc would have been an improvement - the current implementation is just copying the data off into a temp array, deallocating and re-allocating the main array (with a bigger size), then copying the data back and dumping the temp array.

I'll use that for my developments! For DYNK it would be a good idea to look at too, however I doubt that it is a big problem for runtime.

Thanks for the tip!

[JamesMolson]

Pretty much done for nele now.

[vkbo]

Completed for nblo, nblz and nzfz in #516

[kyrsjo]

Done?

[kyrsjo]

Done!