Skip to content
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

First pass at composite transformations. #203

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

sybenzvi
Copy link
Contributor

@sybenzvi sybenzvi commented Aug 4, 2022

This PR is designed to address issue #183 by implementing a simple class to compose an arbitrary list of flavor transformations.

If instantiated as follows,
c = CompositeTransformation(U1, U2, ..., Un)
where U1, U2, etc. are different FlavorTransformation objects, the class will apply the transformations in the order supplied to the CompositeTransformation. I.e., U1 will be applied first, then U2, and so on to Un.

Unit tests need to be added to the branch before we proceed with the merger.

@github-actions
Copy link

github-actions bot commented Aug 4, 2022

Result of Benchmark Tests

Benchmark Min Max Mean
python/snewpy/test/test_snowglobes.py::test_simulation_chain_benchmark 4.18 4.29 4.24 +- 0.05

@sybenzvi
Copy link
Contributor Author

sybenzvi commented Aug 4, 2022

Comment about the guts of CompositeTransformation: internally it performs matrix multiplication of the composed unitary transformations. The composite matrix is not supposed to be accessed by users, who should use the survival and transition probability functions prob_ee(t, E) etc. provided by the base class. For efficiency, the calculation of the transformation matrix is memoized so that it is not recalculated for all transition probabilities unless the input time and energy arguments change.

On this topic, the following checks should be completed:

  • Unit test of the interface
  • Checks that memoization works as intended
  • Checks that ndarray arguments for input time and energy work

@JostMigenda
Copy link
Member

At first glance, this looks good to me; thanks! I would also suggest updating the FlavorTransformation.ipynb to add an example for this composite transformation.

@jpkneller
Copy link
Contributor

jpkneller commented Jun 1, 2023

The idea is a good one but the present implementation of the flavor transformations in SNEWPY means that there are only limited circumstances where you can string together flavor transformations. The neutrinos would have to decohere between the transformations being applied and the only flavor transformation we have in SNEWPY which occurs outside the supernova is neutrino decay.

@jpkneller
Copy link
Contributor

I checked the math and it turns out chaining together SNEWPY's flavor transformations cannot be done even if the previously mentioned restriction that the neutrinos decohere between transformations is valid. Attached is a proof.
proof.pdf

@JostMigenda
Copy link
Member

Thanks for checking this and writing it up! If I understand correctly, there’s two different ways we could fix this:

  1. If we switch to six-flavour oscillations (see Treat μ and τ flavours separately #99), we wouldn’t need the L and R matrices anymore
  2. If we stick with four-flavour oscillations, we could calculate the self.De1, self.De2 etc. in the __init__ function (as we already do for many of the existing transformations) and then use those in the calculation to compose flavour transformations.

@jpkneller
Copy link
Contributor

Either option should work. The second is the easiest and I know what to do. I haven't looked at how much of the code would have to change if we went to 6 flavors though it's something we said we'd do.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Create a method to compose flavor transformations
3 participants