-
Notifications
You must be signed in to change notification settings - Fork 31
Calculate Linear Transfer Map #1256
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Calculate Linear Transfer Map #1256
Conversation
Add a `transfer_map(ref, order="linear", fallback_identity_map=False)` method to the element list, supporting the calculation of a linear transfer map of all elements in the list.
| :return: True if at least one element of the specified kind exists | ||
| :rtype: bool | ||
|
|
||
| .. py::method:: transfer_map(ref, order="linear", fallback_identity_map=False) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For review: we could also make order a number, if that is more sensible (linear: 1, etc.).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is fine as-is for now. The best key word really depends on what options we would like to support in the future. For example, we could have multiple methods of computing the map (e.g., using Taylor maps or automatic differentiation or Lie maps), and "method" would be a good key word.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could also remove the order keyword at all for now, since we do not use it. We can always introduce more keywords when we need them.
| :param ref: A reference particle. | ||
| :param order: So far, only the calculation of linear transfer maps is supported. | ||
| :param fallback_identity_map: For elements with an undefined transfer map in the lattice, assume the identity matrix. | ||
| :return: The transfer map of all elements in the list. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For review: if we are later on calculating higher orders, should we return a list of transfer maps (one per order)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For higher orders, there are several ways to represent the map, which may be organized into one (or more) arrays. It's useful to organize these by order-by-order. However, regarding terminology all this information is usually referred to as one map (singular).
| .def( | ||
| "transfer_map", | ||
| []( | ||
| KnownElementsList &v, | ||
| RefPart ref, // note: intentional copy | ||
| std::string order, | ||
| bool fallback_identity_map | ||
| ) | ||
| { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we could also implement this part fully in Python and it would probably be cleaner.
Only the exception handling in the inner loop is likely (quite) slower.
Can also be done later, when we find that we like to implement higher order logic rather in Python than C++.
8730e11 to
d2185ef
Compare
| [9.98334297e-02, 4.99583537e-02, 0, 0, 1.00000000e00, -1.66466013e-03], | ||
| [0, 0, 0, 0, 0, 1.00000000e00], | ||
| ] | ||
| ) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these currently the true expected values or just dummy values?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I quickly put in the current computational result as expected. We should verify manually.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, def wrong values because of the multiplication order mix up :D
Co-authored-by: Chad Mitchell <[email protected]>
Co-authored-by: Chad Mitchell <[email protected]>
cemitch99
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fixed the existing test and ran some additional sanity checks, and everything looks good.
|
Thank you! :) |
| linear_transfer_map = linear_transfer_map * element_transport_map; | ||
| linear_transfer_map = element_transport_map * linear_transfer_map; | ||
| // TODO: shorthand needs https://github.com/AMReX-Codes/amrex/pull/4880 from AMReX 26.02+ | ||
| // result *= element_transport_map; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment cleanup needed: result *= element_transport_map; is not identical to the line above.
Add a
transfer_map(ref, order="linear", fallback_identity_map=False)method to the element list, supporting the calculation of a linear transfer map of all elements in the list.Close #1254
To Do / To Discuss
lattice...method or should we rather add an interface tosim. ...(assuming higher-order transfer maps require particle tracking) - discussed: the primary use cases are only on the reference particle trajectory (linear and higher order). We could add this to tracking for the few collective effects that change the reference particle, but this is uncommon.