pyat: atpass error about at HOT 23 CLOSED

Hi,

Thanks for trying pyat, I'd be keen to help you. You could try renaming the file to .txt and see if it lets you attach the file by dragging it into this editor.

Cheers,
Will

from at.

Here's the example dba.mat renamed.

dba.txt

from at.

Ok, thanks @willrogers ...
a25.txt

from at.

I cannot reproduce the bug, but the dab.txt lattice you sent is 145 elements long, and not 1469 as your 1st message says. Is it the right lattice ?

from at.

I added the dba.txt as an example. Zeus then added a25.txtand that's the one with the bug.

We've got a fix for this, should get a pull request in today.

from at.

The pull request #71 should fix the segfault. However, there is still difficulty loading the .mat file. That is because pyat requires the 'Class' field to be set on every element in the lattice. The Matlab version does some guessing to try to figure out the correct type.

@lfarv @carmignani what do you think is the correct behaviour? Do you think we should require the 'Class' field on every element?

from at.

Hi @ZeusMarti,

The changes from #71 should resolve your original problem. However, as Will mentioned, your a25.mat file still will not load a valid ring, as some of your elements that do not have classes set have pass methods other than 'DriftPass' or 'IdentityPass'. To fix this set the 'Class' field to 'Corrector' on your correctors and to 'Quadrupole'* on your element with FamName of 'QS'.

*I have assumed that 'Quadrupole' is the correct class for your 'QS' elements, however with the attributes they have once loaded in pyat they could equally be Sextupoles.

I hope this helps,
Toby

from at.

The 'Class' field has been introduced recently and is not required to give a valid AT structure, it has been set as a help for selecting elements. It would be a constraint for a lot of existing lattices to impose it. A better way (but more work) would be to reproduce the function atguessclass in Python.

Otherwise I noticed that the a25 lattice also crashes the atwritem Matlab function. I have a fix for that to be submitted soon.

from at.

Thanks everyone. 'QS' stands for skew quadrupole, I guess, in this case it should be a Multipole, right?

from at.

Yes, Multipole is fine.
I am currently working on a class guessing function, an improved Python implementation of atguessclass.m, and so looked at your lattice, a25.mat, for reference. I noticed a few elements that are not Quadrupoles but have 'K' as an attribute, this currently confuses my class guesser. Could you please explain what these elements are/should be, elements 16 and 19 (indexing from 1) are examples of this case. As they have so few other attributes my assumption would be 'Drift', but they appear to be related with the Quadrupoles that preceded them in the lattice.

from at.

@T-Nicholls, I should better remove those elements, they are just markers of each quadrupole family. I don't even remember when we introduced them or why... Actually I thought about removing them in the past, but up to now, they where not generating any problem. In case of many turns tracking I generally remove those kind elements.

For the python scrip, elements with IdentityPass not being Monitor should be guessed to be Marker, what dou you think?

from at.

@ZeusMarti thanks for clarifying.
My current class guessing function only guesses based off of what attributes/fields the element has. I will take that into consideration though, as I am looking at writing separate functions to guess based on PassMethod or FamName of the element. That said, whilst in most cases non-Monitor elements with IdentityPass will be Marker, RingParam elements also have IdentityPass as their default PassMethod. In addition, hopefully, PassMethod based guessing will rarely be used as attribute and FamName guessing methods will be used first as they are more likely to be accurate.

from at.

@ZeusMarti
I have now completed my class guessing function and it is near perfect on every lattice that I checked. To test it I removed any existing classes and then checked the output against the known correct classes for each element.
I also tried it on your lattice, it found a class for every element and the output lattice successfully generated twiss data. However, since I am not familiar with your lattice and not all of the original elements have a class, I am unable to verify that the output lattice is correct. I have manually verified the first 50 elements and I believe them to be correct, but I would be most grateful if you could do some checking for me.
If you do not have a list of classes that you can directly compare it against then I would suggest: checking that at least one element in each family now has the correct class, setting some of the elements (e.g. Quadrupoles) and checking that the twiss data is what you would expect, also just checking a small number of elements randomly chosen from the lattice.
I have attached an ordered list of the element's classes(a25_classes.xlsx) and the .mat file for the full lattice, renamed to .txt, (a25_fixed.txt).
I look forward to hearing what you find, thanks.

from at.

@T-Nicholls
The twiss data agrees only roughly (10%) at the first element. Elements (16, 19, 26, 46,...), even if they have a K field should be Monitor not Quadrupole. Maybe those two problems are related? Apart from that, all the other elements look ok to me!

from at.

@ZeusMarti
Thank you very much, that is good news. I hope that is the reason the twiss data is off, which fields of the twiss data differ? I'm not sure as even though they are Quadrupoles they use IdentityPass and have length 0, so I don't think they should have an effect.
Unfortunately, there is no way to correctly identify these elements because changing the PassMethod to IdentityPass is sometimes used as a way to keep the element in the lattice but remove it from the calculations. We also cannot distinguish by length, as it is possible (at least as far as the AT integrators are concerned) for a Quadrupole to have Length 0. I am not sure if that would be an intended use though, if not I could use a length check.
My understanding of accelerator physics is not the best so I will check this with Will.

from at.

After further investigation and discussion with Will, there is no way to correctly identify your Monitor elements that have a K field; this is a guessing function after all and will not ever be perfect. On the note of the twiss data in Python, I have found all fields of the twiss data from your original file (after QS and Corrector changes) to be identical to the twiss data from my file with the classes guessed. However, they differ from the MML twiss data values from the same files; I am unsure why this is the case as they are identical for our ring at Diamond, but I am looking into it.

from at.

@T-Nicholls
Can you make your guessing function available ? Thanks

from at.

I was waiting on full feedback from Will before I made a pull request, and he is away this week, but I will make a change that he suggested on Friday and create the pull request today.

from at.

@lfarv, my changes are now on pull request #74.

from at.

@ZeusMarti I finally got to the bottom of the difference in the twiss data for your lattice. The length of all Corrector elements was accidentally being set to 0, this only caused a discrepancy if the element should have had a non-zero length. Thus the divergence in your twiss data only occurring from element 1460 onwards. It is worth noting that this bug caused a difference regardless of whether the Corrector was set or not. The fix for this is on pull request #78. I believe that all the problems you have raised on this issue should now have been addressed.

from at.

Thanks!!
I'll take a look at it as soon as possible!

from at.

@ZeusMarti have you looked at this?

from at.

Sorry I just forgot about this issue. Indeed, it works pretty well now! Thanks guys.

from at.