Skip to content

Bumps design #33

Description

@RossBoylan

Several things seem odd about the current bumps design. This ticket is to see if there is a good reason for any of them.

  1. Maximum 10 bumps per type. Seems completely arbitrary. See
    raise RuntimeError("No more than 10 bump filters of a type allowed. Exceeded for type "+key_orig)
    for the error message; the code above it hardcodes looking for 10.
  2. Why are keys being created with the original key, a dot, and a counter?
    new_key = key_orig+"."+str(i)
  3. It is not entirely clear to me if the order in which one applies the bumps matters. If each transforms the k-space representation then they would be order dependent. I think that is not the case because the code applies each bump to the original data, x, and adds up the results. Can anyone confirm?

It seems to me a more natural data structure would be to make the bumps a list of Bump objects, with each object having all relevant info including the signal key.

Metadata

Metadata

Labels

designconcerning the intended behavior of the applicationquestionFurther information is requested

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions