-
Notifications
You must be signed in to change notification settings - Fork 19
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
Create a NeutrinoFlux
class as a container for neutrino signal, produced by a supernova model
#214
Comments
Initial thoughts: I’m sceptical about the Regarding Benefit 2: That sounds like you’re trying to build your own implementation of (parts of) |
Yes. IMO the current
But I'm not proposing to change this interface here. I propose to keep the interface for the compatibility, alright, but I propose to move the existing functionality into the objects, and make the inner implementation of these |
Wouldn't that change the interface (currently
By implementing manually you mean in my user script / jupyter notebook, and don't touch the snewpy code? |
@JostMigenda, it seems to me that you consider my use cases as something exotic, and my suggestions somehow disruptive for the "normal" usage of snewpy. 1. Using new detector configuration
(similar to the icecube, but with different mass).
Possible workarounds
2. Using presupernova models
Possible workarounds
What I suggestis to make classes that allows an easy way of tweaking the usual processing chain. So that users can decide on the energy/time binning, and work with that values the way they want - integrate, slice, scale the flux, and compute the event rates flexibly. Currently snewpy is not capable of this. |
Thanks for describing these high-level use cases you’re interested in; this helps make the problem much clearer! Regarding 1. (new detector configuration): If the new detector is at an early stage, where it can be described by “similar to [existing configuration], but with different mass”, the workaround I would recommend is to use that existing configuration and just multiply the resulting event rates with a scale factor. (That’s e.g. how we got Hyper-K numbers for the SNEWS 2.0 white paper; or what I’m currently using to write a SN section for another detector white paper.) If those workarounds aren’t enough, we could try to extend Regarding 2. (preSN models): I think ideally, the difference between preSN and ccSN models should be almost transparent to users of snewpy. As far as reasonably possible, they should be able to use the same code to plot (or calculate event rates for or do any other analysis with) any model. Right now, I agree that the existing Under the hood, a I see a couple of possible options now:
None of these options feels right; I’m torn. Let me think about this some more … |
Thank you for your answer.
That looks the most natural solution to me, but it might happen only in the distant future. Other options look quite bad for the user experience and.
While I totally agree on your points (a) and (b) , the link in (c) says I mean that v2.0 is not a New Year, and when it comes should be defined only by the changes we put to snewpy - not vice versa. Please don't use this as an argument about what changes should or should not be made. And finally I want to stress again, I didn't propose any changes for the public interface at all. Let's agree on this point: our public interface doesn't work for those use cases, and we are not ready to change it (yet?). The solution I propose to this is:
|
Sorry for the late response! I’ll just repeat one point regarding the implementation, so it doesn’t get lost:
|
We discussed with @JostMigenda the implementation and agreed to the following points: 1. Make
|
This is a discussion for a feature if we agree on #213.
What I want
A
NeutrinoFlux
class, returned bySupernovaModel.get_initial_flux
method.An object which contains all the information about the neutrino signal from supernova model.
This information should be sufficient to
T
andE
points where it was calculatedWhat I suggest
astropy.Quantity
classes to keep track of all the dimensions.(N_flavors,N_times,N_energies)
- this will make it easy to apply any transformation matrix, by just using matrix multiplicationSo, something like this (pseudocode):
Benefits
FlavorTransformation
andNeutrinoFlux
classes (not coupled toSupernovaModel
) - which is logical, because mixing acts on the neutrino signal rather than the supernova itself.NeutrinoFlux
to the SNOwGLoBES/SimpleRate calculation directly.So instead of (or as alternative to) calling (pseudocode)
one could do
and have access to all the intermediate results IN MEMORY without reading additional files
The text was updated successfully, but these errors were encountered: