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

Dveyrat/extended cooling tail model #312

Merged
merged 18 commits into from
Nov 20, 2024

Conversation

dveyrat
Copy link
Contributor

@dveyrat dveyrat commented Apr 15, 2024

Adds extended supernova model class which models neutrino luminosity during the cooling tail.

@dveyrat dveyrat marked this pull request as ready for review May 30, 2024 18:14
@sybenzvi
Copy link
Contributor

sybenzvi commented Jun 20, 2024

Before completing the review, let's close the loop with collaborators from Hyper-K on this feature (email forwarded by @JostMigenda on 5 Jun 2024).

* remove unused imports
* give __init__ argument a cleaner name
* move type check to top of __init__
@JostMigenda
Copy link
Member

Had a first look while waiting for my transfer in ORD. Boarding begins now, so just a few notes for next week:

  • I’ll suggest a few more minor code changes later.
  • Some usage examples would be good. I think we already have one in the v2.0 paper draft; but it would be good to have that available in the repo (e.g. as an example notebook or in the docstring)
  • Are there any useful tests we could add?

Copy link
Member

@JostMigenda JostMigenda left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of comments and fixes. They’re mostly minor, but some may require discussion.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like this is just an unintended metadata change; I could try to rebase the branch and make this change disappear, to clean up the PR a little bit.

python/snewpy/models/extended.py Outdated Show resolved Hide resolved
python/snewpy/models/extended.py Outdated Show resolved Hide resolved
python/snewpy/models/extended.py Outdated Show resolved Hide resolved
python/snewpy/models/extended.py Outdated Show resolved Hide resolved
python/snewpy/models/extended.py Outdated Show resolved Hide resolved
python/snewpy/models/extended.py Outdated Show resolved Hide resolved
Comment on lines +88 to +110
def get_integrated_luminosity(self, m_PNS, SRT, alpha, beta, gamma):
"""Get integrated neutrino luminosity from shock revival time to 20 s.

Parameters
----------
m_PNS : astropy.Quantity
Mass of the proto-neutron star.
SRT : astropy.Quantity
Shock revival time.
alpha : float
First cooling tail model parameter.
beta : float
Second cooling tail model parameter.
gamma : float
Third cooling tail model parameter.

Returns
-------
astropy.Quantity
Integrated luminosity calculated from Ekanger et al. (2023) model.
"""
logE = (m_PNS.value * alpha) + (SRT.value * beta) + gamma
return (10**logE) * u.erg
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I understand correctly, this fit is specific to the Nakazato_2013 models (e.g. due to the 20s time range and the shock revival time) and does not make sense for other models? The function also does not appear to be used anywhere, so would it be better to delete it?

Comment on lines 64 to 81
def extend(self, ts, k = -1., A = None, tau_c = 36. * u.s, alpha = 2.66):
"""Extend supernova model to specific times.

Parameters
----------
ts : astropy.Quantity
Times to add to supernova model.
k : float
Power law factor (default: -1)
A : astropy.Quantity
Normalization factor (default: None)
tau_c : astropy.Quantity
Exponential decay characteristic timescale (default: 36 s)
alpha : float
Exponential decay factor (default: 2.66)
"""
for t in ts:
self.time = np.append(self.time, t)
Copy link
Member

@JostMigenda JostMigenda Sep 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we enforce here that the times in ts are larger than base_model.time[-1]?

Or alternatively, if we’d like to include a larger time range in ts (e.g. to compare the “true” luminosity with the “extended” luminosity at early times), I wonder whether it might be preferable to keep the “true” and “extended” data points separate. If we just append the extended points to self.time (here) and self.luminosity (below), it’s more difficult to plot the true/extended luminosity separately and it’s easy to end up with plotting artifacts, like in this example from the demo notebook:

image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think @dveyrat's idea was that the ts argument would be a superset of the internal model times, but we can internally force it to drop any times that already exist in the model rather than make the user track which times are present in the model and which are not.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’d … probably err on the side of not making the user keep track of such things; but I can also see how it might be lead to confusion if we try to be “too smart” and drop entries when the user might not expect that. 🤔

Maybe we should keep it as is for now, merge, and ask people to test a beta release? And then we can still change it based on feedback.

Copy link
Member

@JostMigenda JostMigenda left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for resolving these @sybenzvi! I’m pretty happy with this now; there’s still an open UX question, but I think we can go ahead, merge this as is (once the tests have succeeded) and ask people for feedback on that during beta testing.

@JostMigenda JostMigenda merged commit 564f2b5 into main Nov 20, 2024
14 checks passed
@sybenzvi
Copy link
Contributor

Thanks @JostMigenda , we can figure out the interface later. After your merger I did update the extend function to only add times after the end of the model time, but I didn't test this yet. If you're satisfied we can punt on that until after the release.

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.

3 participants