Allow scalar input for 't', 'E' and 'data' arguments of Container class

[Sheshuk]

Fixing problem if a user passes a scalar value to container.
Example:

import numpy as np
import astropy.units as u
from snewpy.flux import Flux
from snewpy.neutrino import Flavor

# this was the only valid way before this fix: wrap everything in []
Flux(data = [1] << u.Unit('1/(MeV s cm**2)'), 
     flavor=[Flavor.NU_E],
     time=[1]<<u.s,
     energy=[1]<<u.MeV)

#now it's possible to pass scalars if there is only a single value or point
Flux(data = 1 << u.Unit('1/(MeV s cm**2)'), 
     flavor=Flavor.NU_E, 
     time=1<<u.s,
     energy=1<<u.MeV)

#they're converted internally to arrays. This produces 
# d2FdEdT (1, 1, 1) [1 / (MeV s m2)]: <1 flavor(0;0) x 1 time(1.0 s;1.0 s) x 1 energy(1.0 MeV;1.0 MeV)>

[JostMigenda]

Even worse—before, you needed data = [[[1]]] << u.Unit('1/(MeV s cm**2)') (with triple brackets). I agree this is a nice improvement; thanks!

[JostMigenda]

Actually, on second thought, one thing gives me pause:

In addition to giving scalars for all arguments, this would also enable using a mix of scalars and vectors. E.g.

# pass array of energies, scalars for all quantities
Flux(data = [1, 1, 1] << u.Unit('1/(MeV s cm**2)'), 
     flavor=Flavor.NU_E, 
     time=1<<u.s,
     energy=[1, 2, 3]<<u.MeV)

# pass array of times, scalars for all other quantities
Flux(data = [1, 1, 1] << u.Unit('1/(MeV s cm**2)'), 
     flavor=Flavor.NU_E, 
     time=[1, 2, 3]<<u.s,
     energy=1<<u.MeV)

Both would produce the same 3D data array, but the intended physics meaning is different. I wonder if this makes it too easy to introduce mistakes?

[Sheshuk]

Thanks, you're right! I didn't think about that. That's definitely against what the user would expect.

[Sheshuk]

I added:

1. Reshaping data array if it's 1D to one of the expected shapes.
2. Array shape validation vs. expected shapes.

Maybe it still doesn't cover all the possible corner cases.
But in general this class is not supposed to be created by user, but rather produced in the SupernovaModel.get_flux etc...

But I need to think of more strict conditions, when to use this reshaping

[JostMigenda]

I’m not quite sure about corner cases either; but this certainly adds useful guard rails for the intuitive(-seeming) case. And for all other cases, one has to consciously think about the array shape anyway; so having no extra guard rails is probably fine.

Thanks!