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

Creation of hidden photon flux code #72

Merged
merged 31 commits into from
Sep 11, 2023

Conversation

tomasoshea
Copy link
Contributor

@tomasoshea tomasoshea commented Jun 22, 2023

tomasoshea Large: 907 Powered by Pull Request Badge

Created 2 new files TRestAxionSolarHiddenPhotonFlux.h and TRestAxionSolarHiddenPhotonFlux.cxx to go with the TRestAxionSolarFlux code.

@tomasoshea tomasoshea requested a review from jgalan June 22, 2023 08:15
class TRestAxionSolarHiddenPhotonFlux : public TRestAxionSolarFlux {
private:
/// The hidden photon mass used for calculation
double HiddenPhotonMass;
Copy link
Member

@jgalan jgalan Jun 22, 2023

Choose a reason for hiding this comment

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

I think we do not need the mass here? It is the method GetRandomEnergyAndRadius where we define the mass. There should be something inside that method that gets the probability depending on the mass.

Then, inside the processing chain, TRestAxionGeneratorProcess will chose a given mass, and it will use that method to get a random particle from the sun, with given energy and position in the sun (for a given mass).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've been looking at it and instead of having the mass as an argument to all the functions that need it, could we not have it as a member of the class? So for example when GetRandomEnergyAndRadius is called with double_t mass as an argument we can then set HiddenPhotonMass = mass? So that since the flux depends on the mass we wouldn't have to supply mass as an argument to every function that deals with the flux.

Copy link
Member

Choose a reason for hiding this comment

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

Yes, this is possible.

We just need to make sure then that we have this mass inside TRestAxionSolarFlux and not within TRestAxionQCDSolarFlux or TRestAxionHiddenPhotonFlux.

So, we define a TRestAxionSolarFlux::fMass.

Then, inside the TRestAxionGeneratorProcess we can call TRestAxionSolarFlux::SetMass(m) before calling GetRandomEnergyAndRadius.

TRestAxionGeneratorProcess will only have access to those methods available to TRestAxionSolarFlux.

Copy link
Member

@jgalan jgalan Jun 22, 2023

Choose a reason for hiding this comment

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

Then, inside TRestAxionSolarFlux we should add:

Double_t fMass = 0; //!

Double_t GetMass() { return fMass; }
void SetMass(const Double_t &m ){ fMass = m; }

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, then would we remove the double_t mass from the other functions and just have them use fMass? For example in GetTotalFlux(Double_t mass = 0)

@jgalan jgalan merged commit 55492be into rest-for-physics:master Sep 11, 2023
59 of 64 checks passed
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.

2 participants