voltage2efield not working without particle type

[boboeyen]

After running a simulation with the emitter I wanted to use the voltageToEfieldConverter but it didn't properly work because no particle type was given to the event in the station. The particle type was set in the sim_station, but since a reconstruction model does not look for this (as data does not have this structure) the module was not aware of it and not working for me. Also I was wondering if some more differentiation is then needed to some how extract whether it is a neutrino, CR or pulser event?

[ikrav]

I may be missing something, but why would voltageToEfieldConverter care about what is the cause of the electric field? Naively, it seems that only what the antenna characteristics are should be relevant.

Does this mean that something needs to be changed in the example for the emitter use that Pawan has configured in NuRadioMC?

Ilya

On Apr 25, 2022, at 10:06 AM, Bob Oeyen @.**@.>> wrote:

Non-NU Email

---

After running a simulation with the emitter I wanted to use the voltageToEfieldConverter but it didn't work because no particle type was given to the event in the station. The particle type was set in the sim_station, but since a reconstruction model does not look for this (as data does not have this structure) the module was not aware of it and not working for me. Also I was wondering if some more differentiation is then needed to some how extract whether it is a neutrino, CR or pulser event?

— Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https://github.com/nu-radio/NuRadioMC/issues/400__;!!PvXuogZ4sRB2p-tU!Xr2gw7qlHNpHxTWZARQqRvDzX5ZnlZZwY4_8N8kkTZtaiXiGmj3Z0CQBQOWi$, or unsubscribehttps://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/ABHCCYGIMST3P77TSMEBKGDVG2YFTANCNFSM5UI4EOOQ__;!!PvXuogZ4sRB2p-tU!Xr2gw7qlHNpHxTWZARQqRvDzX5ZnlZZwY4_8N8kkTZtaiXiGmj3Z0LrZ0Q97$. You are receiving this because you are subscribed to this thread.Message ID: @.***>

[shallmann]

@boboeyen I suspect that the error was thrown elsewhere, since the voltageToEfieldConverter does not (and should not, as Ilya already pointed out) use MC info like particle type... can you attach a minimum not-working example, or the full error message?

[boboeyen]

Well the code simply does check whether it is a neutrino or cosmic ray to do other calculations for the refractive index. It apparently also uses a ice import from NuRadioReco.utilities to get the refractive index but this file has nothing sensible in it, just a few lines. It is really strange. Is this maybe an old module that was replaced by voltageToEfieldConverterPerChannel but was not removed?

https://github.com/nu-radio/NuRadioMC/blob/develop/NuRadioReco/modules/voltageToEfieldConverter.py#L32 https://github.com/nu-radio/NuRadioMC/blob/develop/NuRadioReco/utilities/ice.py

[christophwelling]

This check for the particle type is in there because cosmic ray and neutrino signals have to be treated slightly differently. If you reconstruct the signal direction for a cosmic ray from the time delay, you get the direction the signal had in the air, which is different from the one it has in the ice because of refraction at the air-ice surface. This does not happen for signals from neutrinos.

That said, this module was really only developed for cosmic ray events, because we did not really know how to reconstruct the E-field for neutrino events, but were pretty sure that just unfolding the antenna response like this module does would not really work. So nobody really has put any work into figuring out how this module would work for a signal coming from below.

[shallmann]

I see, the only quick hacky solution without modifying voltageToEfield converter would probably be to use station.set_is_neutrino() or run the eventTypeIdentifier.run(event, station, mode='forced', forced_event_type='neutrino') before calling the converter.

But this is not beautiful... @cg-laser other suggestions? do we want to address the possibility of having additional / more general event types in the sim station? Should we catch (or can we even get rid of?) the sim_station properties in the voltageToEfieldConverter?

[anelles]

I think we should make clear that this module is only intended for using the surface antennas (where one can assume that the same ray path reached all of them) and it has only been tested for cosmic rays.

It shouldn't be used for neutrinos in general, maybe for surface only events, once could pull it off, but we would have to test. For neutrinos in the deep antennas, Christoph's IFT module and Ilse's forward folding are better options, but their logic of course may be different.

I think this falls in the workpackage of providing a couple of 'standard' reconstruction sequences that are well documented and up to date. Probably some code clean-up would be useful ...

[cg-laser]

@boboeyen thanks for starting this discussion. I slightly disagree with the above: The voltageToEfieldConverter is a general-purpose module that works as long as the efield can be assumed to be identical in the antennas that are used for reconstruction. E.g. an hpol/vpol pair deep in the ice should just work fine.

Setting the particle_type manually as Steffen proposed is a good solution to solve it for now. The user needs to somehow specify if the signal originates from air or from ice. I think it will be error-prone to define either case as the default because many people also do cosmic ray analyses with NuRadioReco. However, we might want to adapt the naming scheme from particle_type to from_air/from_ice or similar.

For now I would suggest to print a more meaningful error when the particle type is not set.

[cg-laser]

I just made a PR to add more documentation

[boboeyen]

For my simulation I am now using the voltageToEfieldConverterPerChannel since that one seems to work and just unfolds the antenna. I was not aware of the difference between these two modules so some more documentation about the modules and when to use them (in general) I think would be great :)

[boboeyen]

@cg-laser I would really support the change in naming scheme since the new scheme says what it is actually about and the old doesn't. That being said I would understand that it breaks backwards compatibility. Maybe it can be introduced as an additional naming scheme that is then used in the relevant modules?

[cg-laser]

@boboeyen be careful with the voltageToEfieldConverterPerChannel. It does not reconstruct the full efield. You as the user need to specify the final polarization. Only then the 2D efield can be determined from a 1D single antenna measurement.

[boboeyen]

Okay, thanks for reminding me. And what about the ice in the module? This seems also very weird to me.

[cg-laser]

it is needed to get the index of refraction which is needed to calculate the propagation times. And for the "from air" case to calculate how the signal arrival direction changes when the signal refracts into the ice.

[sjoerd-bouma]

I hope that with #401 this is now sufficiently clear? If not, feel free to request additional changes and reopen this issue.