disable opacity from inverse emission

[srichers]

prevent pair emission processes from contributing to the opacity through Kirchoffs law. This lets the emission processes be turned on without screwing up the opacities. The README is updated to say that turning on the emission processes means the corresponding opacities must be explicitly programmed in whatever simulation

[evanoconnor]

I know this is the wrong way to handle thermal emission opacities. However, it is very attractive and accurate in some cases (In equilibrium for nux neutrinos is it exact). I agree something better should be done than what is done now. Ideally, NuLib will have the routines that calculate the opacities given the appropriate distributions.

Can we add in an option to include this way of computing opacities instead of removing it completely? I would prefer having people have to turn it off by default so that they know must determine it on their own. I think having no opacities is worse than having wrong but approximate opacities, especially if the problem is one where opacites are needed.

I think turning these processes off by default for nue/nuebar in requested interactions is a good idea as there this assumption can really mess things up, especially at low temperatures and they don't really do anything since the charged current rates are so high.

Thoughts?

[srichers]

Hi Evan,

I'll add a flag to in/exclude the rates. I think I don't understand. I'll try to clarify why I'm confused below.

The rates should be correct for any species when both the neutrino and antineutrino species are isotropic, at the same temperature as the fluid, and zero chemical potential, right? Equilibrium means the forward rates are just as fast as the reverse rates, so including the processes has the same effect as not including them at all. Would this not be equivalent to saying "The rates are accurate when the system is in equilibrium, defined as when the forward and backward rates are the same" (i.e. circular logic)?

Thanks for helping me understand what is going on!

Sherwood Richers

On Sat, Mar 1, 2014 at 2:35 PM, evanoconnor notifications@github.comwrote:

I know this is the wrong way to handle thermal emission opacities. However, it is very attractive and accurate in some cases (In equilibrium for nux neutrinos is it exact). I agree something better should be done than what is done now. Ideally, NuLib will have the routines that calculate the opacities given the appropriate distributions.

Can we add in an option to include this way of computing opacities instead of removing it completely? I would prefer having people have to turn it off by default so that they know must determine it on their own. I think having no opacities is worse than having wrong but approximate opacities, especially if the problem is one where opacites are needed.

I think turning these processes off by default for nue/nuebar in requested interactions is a good idea as there this assumption can really mess things up, especially at low temperatures and they don't really do anything since the charged current rates are so high.

Thoughts?

Reply to this email directly or view it on GitHubhttps://github.com/evanoconnor/NuLib/pull/4#issuecomment-36439090 .

[evanoconnor]

Hi Sherwood,

Sorry this took a while,

The rates should be correct for any species when both the neutrino and antineutrino species are isotropic, at the same temperature as the fluid, and zero chemical potential, right?

Yes, correct.

Equilibrium means the forward rates are just as fast as the reverse rates, so including the processes has the same effect as not including them at all.

Not exactly. Since these are the only ways to produce mu and tau, without them there would be no emission, therefore you couldn't build up to an equilibrium field in the first place. What NuLib is doing only makes sense in the limits, i.e. either in equilibrium or in the free streaming limit. However, it also provides a means for the neutrino to diffuse out of equilibrium.

I'm coding the kernels for e+e- annihilation to nu/nubar pairs now. It will be easy to incorporate into GR1D as it is essentially the same process as inelastic electron scattering. It will be particularly easy for nux since I will not have to couple species.

Evan

On 2014-03-02, at 9:26 PM, srichers notifications@github.com wrote:

Hi Evan,

I'll add a flag to in/exclude the rates. I think I don't understand. I'll try to clarify why I'm confused below.

The rates should be correct for any species when both the neutrino and antineutrino species are isotropic, at the same temperature as the fluid, and zero chemical potential, right? Equilibrium means the forward rates are just as fast as the reverse rates, so including the processes has the same effect as not including them at all. Would this not be equivalent to saying "The rates are accurate when the system is in equilibrium, defined as when the forward and backward rates are the same" (i.e. circular logic)?

Thanks for helping me understand what is going on!

Sherwood Richers

On Sat, Mar 1, 2014 at 2:35 PM, evanoconnor notifications@github.comwrote:

I know this is the wrong way to handle thermal emission opacities. However, it is very attractive and accurate in some cases (In equilibrium for nux neutrinos is it exact). I agree something better should be done than what is done now. Ideally, NuLib will have the routines that calculate the opacities given the appropriate distributions.

Can we add in an option to include this way of computing opacities instead of removing it completely? I would prefer having people have to turn it off by default so that they know must determine it on their own. I think having no opacities is worse than having wrong but approximate opacities, especially if the problem is one where opacites are needed.

I think turning these processes off by default for nue/nuebar in requested interactions is a good idea as there this assumption can really mess things up, especially at low temperatures and they don't really do anything since the charged current rates are so high.

Thoughts?

Reply to this email directly or view it on GitHubhttps://github.com/evanoconnor/NuLib/pull/4#issuecomment-36439090 .

— Reply to this email directly or view it on GitHub.