Closed coldfix closed 10 years ago
I am heavily reworking the cern.cpymad.madx
API as well to return Table
proxy objects, that can then be used to retrieve columns/summary if desired, but won't allocate any unnecessary numpy arrays if the columns are not used. It is no problem for the returned value to retain backward compatibility. This may sound complex, but the code is actually quite simple and short.
[will be handled in a separate PR]: I want to remove the retdict
parameters from most of the function signatures, as it just creates additional complexity. Do you think this is an acceptible back-ward incompatible change?
[will be handled in separate PR]: Furthermore, I'm not sure whether the columns
parameter becomes unnecessary. Apart from determining which columns to retrieve, it was also used in a SELECT call. Does the SELECT call have any influence, apart from setting which variables to output if a file was specified? What is the meaning of the pattern parameter?
Best regards,
Thomas
Added element inspection to this branch as well, This will close #38. Since I used quite a lot of steps, I recommend not to look at the individual changes, but rather at the overall diff.
If you want to check it out, you could use a test.madx
like so:
qp: quadrupole, k1=2, l=1;
sb: sbend, l=2, angle=10;
tt: sequence, l=4, refer=center;
qp, at=0.5;
qp, at=1.5, l=2;
sb, at=3;
endsequence;
and the following python code:
from cern.cpymad.madx import Madx
m = Madx()
m.call('test.madx')
el = m.get_sequence('tt').get_elements()
from cern.cpymad.types import Expression
import yaml
def element_dump(data, stream=None, Dumper=yaml.Dumper, **kwds):
class OrderedDumper(Dumper):
pass
def _expr_representer(dumper, data):
return dumper.represent_mapping(
yaml.resolver.BaseResolver.DEFAULT_MAPPING_TAG,
{'expr': data.expr, 'value': data.value})
def unicode_representer(dumper, uni):
node = yaml.ScalarNode(tag=u'tag:yaml.org,2002:str', value=uni)
return node
OrderedDumper.add_representer(unicode, unicode_representer)
OrderedDumper.add_representer(Expression, _expr_representer)
return yaml.dump(data, stream, OrderedDumper, **kwds)
element_dump(el, open("data.yml", 'w'))
This might already be ready for merging, but I will take a few days to see if I need any more features, that should be directly integrated into this PR. And I should really also add some tests.
Note, that most of this is still downward compatible and shouldn't make it necessary to change using code (except when that relies on the exact return type of .twiss()
).
EDIT: added the little example above as test.
This is a big change, will take me some time to look through it all. In principle I have no objections, thanks once again for all your work!
Oh, it looks like some commits were missed in the merge to master. We should merge these as well. We can put these in testing tomorrow. I recommend merging with the "Merge pull request" button, to be sure to merge the most up-to-date version.
I am planning to add and alter some functionality in libmadx to make the madx module more useful on its own. My idea is the following:
Create a class
Sequence
that internally just stores the name of the sequence. It has@property
s to lazily obtain more information when/if desired:there will be a classmethodscrub that, it can't be a classmethod, since:get_sequences
returning a list of instances.Sequence
objects are instanciated viaMadx.get_sequence(name)
,Madx.get_sequences()
or similar (they need to be specific to aMadx
instance)Most of this should be possible to add without touching any backward compatibility issues. Changes to the current
libmadx.py
:get_twiss(sequence) -> numpy.array
get_beam(sequence) -> dict
get_elements(sequence) -> list(Element)
(saving this for #38, though)get_expanded_elements(sequence) -> list(Element)
get_active_sequence() -> name
making it possible to useMadx.*
methods without specifying the sequence nameget_sequences() -> list(names)
(incompatible, but much nicer!)I am not fully decided whether to store a pointer to the C-struct or the name of the sequence within
class Sequence
. I tend towards storing the name, becausecdef class
, instances must be created from libmadx. This in turn creates additional complexity when marshaling the instances between processes.Furthermore, I'd like to remove the print statements from _libmadx.gettable and replace them with
raise RuntimeError
or similar. The print statements in _libmadx.getsequences will be obsolete anyway, the properties can then be examined via the class.By the way, with this and #38, my GUI application will probably become useful for plain MADX files, very soon.
Any thoughts?