Inspect sequence from memory

[coldfix]

I'd really like a way to inspect sequence definitions programmatically.

There is already a [discussion in the egroup](https://groups.cern.ch/group/pymad-users/Lists/Archive/Flat.aspx?RootFolder=/group/pymad-users/Lists/Archive/Accessing beam line via pymad&FolderCTID=0x01200200ECFAA498D6B48B4D914FD896657099D1) about this but I think here is a better place.

In short: there is currently no built-in way in pymad to inspect the beam line. Something similar can be done by iterating over all elements in the output of .twiss. However, this way one cannot obtain any symbolic names., e.g. quadrupole coefficients needed for matching.

I suspect that the API exposed in the MAD-X headers could be used to implement this, but I am not fully sure since I have little knowledge about the MAD-X source. If this is possible and you can hint me towards the required functions I'd be glad to implement this.

Best regards,

Thomas

[Eothred]

I will have a look if I can find it in the headers as soon as I have time. I can also check with Laurent if we have some kind of API defined (doubt so for the moment).

[Eothred]

OK, I had a look at this now, and discussed with Laurent. Essentially, the answer is that the structure is a bit messy. The sequence has pointers to nodes which knows previous/next nodes, which then may or may not point to an element, which ... That's how far I got before I gave in.

You may have a look in mad_seq.h, mad_node.h and mad_elem.h to get an idea.. I also pushed my current work (which I will probably not follow up on) to the branch memaccess_elements

[coldfix]

Great, I will have a look soon.

[coldfix]

I recently had a look at your development branch. What I don't quite understand is the distinction between 'real' (which is currently only RCOLLIMATOR) and other elements. Is there something special about some elements that creates the need for them to be handled differently? Or was this just for testing purposes?

In madX/mad_node.h:30 what is the difference between position and at_value? Is one of these relative to refer=center/...?

In my PR for #49 I have added a function _parse_command(command* cmd) which will come in quite convenient to get all the properties of each element into a dictionary. I hope, it is okay, if I rebase development onto that branch?

[Eothred]

The trouble is that the object 'element' is used for other things which are not actual elements (in which case a lot of the data we try to pull are null pointers). So my thought was that you would have a list of the types you actually are interested in. For testing I only added rcollimator, but you would also need to add all magnet types etc in that list... Or find a better solution.

[coldfix]

For what else is it used? In the sequences I looked at, there was nothing but the elements, that I defined in the input file (which is nice!). Which pointers exactly may be NULL? In that case, it would be easier just to check if the pointer is NULL, rather than lookup the element type name in a list, I think.

Maybe that is what the distinction original sequence (there is a member node_list* nodes) versus expanded sequence (node** all_nodes) is for? First, I thought, original sequence can be used to see what the sequence looked like before a MAKETHIN - but seemingly that's not the case. Do you know whether there is any way to access the original sequence, before MAKETHIN?

By any chance, is it possible to install a newer Cython version on the target systems? In the past, I noticed, that some convenient syntax is not usable on the test servers.

Thanks for the hints so far, I think I can get it working (although I'd like to hear some more about the "virtual" elements).

One more question: in MAD-X, is it somehow possible to match a coefficient using the name of an element, that was later sliced in many pieces by MAKETHIN? e.g.:

foo, sequence;
qp: quadrupole, k1=2;
endsequence;
makethin, sequence=foo;

match, sequence=foo;
vary, name=qp->k1;
endmatch;

Or do I always need to do this like

qp: quadrupole, k1 := QP_K1;
vary, name=QP_K1;

Sorry, for all the trouble, recently. I hope, things get a little more quiet soon.

Best regards, Thomas

[Eothred]

I don't remember precisely to be honest. You could simply try to remove it and see if anything fails (try on a larger sequence like LHC or similar).

[Eothred]

For makethin, don't think so (unsure). makethin does not simply split in slices, it also rematches (changes strengths). Generally, I find the Mad-X objects to be confusing and cluttered, so I would take everything I say with a grain of salt since I might simply misunderstand.

[coldfix]

Haven't had any problems with the LHC sequence so far.

[coldfix]

Implemented in #49.