adds Multipole class to atdisable_6d atenable_6d

[oscarxblanco]

This PR fixes the issus #873 where atdisable_6d fails to disable 6D when the ring has atmultipole elements.

I add the Multipole class to the list, and also an argument as it is the case for all other elements.

[oscarxblanco]

Dear @swhite2401, dear @lfarv ,
who should review this pull request ?

Best regards,
o

[lfarv]

missing argument in atenable_6d

[lfarv]

I had a look and it looks nice. However I found a strange thing: both atenable_6d and atdisable_6d mention an Octupole class. But as far as I could see, this class does not exist:

The Class field was not part of the initial definition of elements. As such, it is not mandatory. It is assigned by the element creation functions, but there is no atoctupole.m element creation function which would assign elem.Class='Octupole'. If the Class field is absent, the "class" is returned by atguessclass or guessclass_6d. None of these functions knows about an Octupole class: any magnet with order higher than 3 is considered as Multipole.

So the 'octupass' keyword in atenable_6d is accessed either if a user explicitly set the Class attribute to 'Octupole' (unlikely), or in a lattice read from a file created in PyAT, since the Octupole class exist in python and is saved in .mat files.

Creating an Octupole class in Matlab would require adding an atoctupole.m creation function, modifying atguessclass.m and guessclass_6d.m to identify octupoles, and modifying at2str.m and at2py.m to generate their proper representation. It could be a topic for another PR.

[lfarv]

OK

[oscarxblanco]

Dear @lfarv ,
my guess is that Octupoles were created in pyat to have some compatibility with the MAD-X element definition.