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

Refactoring coreas to include interpolation #688

Open
wants to merge 104 commits into
base: develop
Choose a base branch
from

Conversation

cg-laser
Copy link
Collaborator

@cg-laser cg-laser commented Jun 5, 2024

Major refactoring of the coreas interface to read the electric field from coreas hdf5 files.
A new class readCoREASDetector.py can be used to read an array and get the interpolated position.

This is largely a copy of #685 which is an undefined state because of an accidental force push. Please never force-push unless you know what you are doing.

@cg-laser
Copy link
Collaborator Author

cg-laser commented Jun 5, 2024

@MijnheerD @lpyras I'm getting these warning from the interpolator module all the time:

Trace arrival times were not set during init, only relative timings are returned!
warning: negative values in abs_spectrum found: 6 times. Setting to zero.

are we not using the interpolator correctly?

@cg-laser
Copy link
Collaborator Author

@MijnheerD @lpyras I added an example of a "LOFAR"-style Xmax reco. The example is using a vertical shower. It would probably be good to also test with an inclined shower as some potential bugs might only appear then.

Before merging this PR, it would be good if the module would be tested a bit more. Is my understanding correct, that this module has not been used by anyone and is essentially untested?

@cg-laser
Copy link
Collaborator Author

The output of the reconstruction looks like this.
A remaining ToDo is a correct uncertainty estimation of the energy fluence. This should be implemented into the efieldSignalReconstructor

Xmax_fit_0
footprint_0_core0 000000_0 000000

@lpyras
Copy link
Collaborator

lpyras commented Aug 5, 2024

@MijnheerD @lpyras I'm getting these warning from the interpolator module all the time:

Trace arrival times were not set during init, only relative timings are returned!
warning: negative values in abs_spectrum found: 6 times. Setting to zero.

are we not using the interpolator correctly?

@MijnheerD I dont really know what that means. I always thought we are anyway only interested in the relative timing. I implemented access now the timing information provided by the cr-pulse-interpolator. Is there something else to do?

@lpyras
Copy link
Collaborator

lpyras commented Aug 5, 2024

@MijnheerD @lpyras I added an example of a "LOFAR"-style Xmax reco. The example is using a vertical shower. It would probably be good to also test with an inclined shower as some potential bugs might only appear then.

Before merging this PR, it would be good if the module would be tested a bit more. Is my understanding correct, that this module has not been used by anyone and is essentially untested?

I tested it before the coreas refactoring for effective area calculation. That yielded reasonable results.

@lpyras
Copy link
Collaborator

lpyras commented Aug 6, 2024

I changed everything we discussed so far e.g. change the coreas readers in a way that they only rely on the readCorsika7() function. Unfortunately I didn't have time to test everything. Any volunteers? Otherwise I try to do it in the next weeks. :)

@MijnheerD
Copy link
Collaborator

Sorry for coming in late on this, I thought I already answered some the questions but apparently I didn't.

@MijnheerD @lpyras I'm getting these warning from the interpolator module all the time:

Trace arrival times were not set during init, only relative timings are returned!
warning: negative values in abs_spectrum found: 6 times. Setting to zero.

are we not using the interpolator correctly?

@MijnheerD I dont really know what that means. I always thought we are anyway only interested in the relative timing. I implemented access now the timing information provided by the cr-pulse-interpolator. Is there something else to do?

This is important, because usually the relative timing is not enough. The problem is that for larger starshapes, the CoREAS time traces start at different times. We added the option to pass the start times to the interpolator, which it can then interpolate for you as well. The warning tells you that the start times were not provided to the constructor. On the lofar/interpolator branch we added this on line 65 of "readCoREASInterpolator.py". Then on line 191 we retrieve the start times, which are used in the make_sim_station function give the traces the correct start time.

@MijnheerD @lpyras I added an example of a "LOFAR"-style Xmax reco. The example is using a vertical shower. It would probably be good to also test with an inclined shower as some potential bugs might only appear then.

Before merging this PR, it would be good if the module would be tested a bit more. Is my understanding correct, that this module has not been used by anyone and is essentially untested?

I agree we should test it more, and I think once the LOFAR pipeline is done we will have an excellent playground for that. Although we can also already start testing on simulations, like the Xmax example (thanks @cg-laser for the script!). I am not sure when we will be able to get to it, but in September we should have a master student who will need to work with the interpolator so he might be able to test it more thoroughly.

@anelles
Copy link
Collaborator

anelles commented Aug 7, 2024

I just tested the branch and it actually fails with a pip installed cr_interpolator on:
File "/usr/local/lib/python3.12/site-packages/cr_pulse_interpolator/signal_interpolation_fourier.py", line 9, in
import interpolation_fourier as interpF
ModuleNotFoundError: No module named 'interpolation_fourier
I feel like I have seen this error discussed. Do we need a new cr_interpolator release?

@fschlueter
Copy link
Collaborator

I am happy to approve this PR. I did not go line by line through this monolithic PR but I hope if people start using it, necessary fixes will be made. I have one question though. Besides adding the core functionality of the interpolator module this PR also removes examples. Why is that?

fschlueter
fschlueter previously approved these changes Jan 29, 2025
@MijnheerD
Copy link
Collaborator

The change I just made should hopefully fix the last unit test 🙏🏽

@MijnheerD
Copy link
Collaborator

MijnheerD commented Jan 29, 2025

With this PR we will get rid of the unit test "Tiny reconstrucution". Should we add a new test with the file? And should we do this in this PR?

Also, do we still need the example SimpleMCReconstruction.py and CostumHybridDetector.py? Both break with the current changes. I made new examples in cr_analysis. But maybe they are hard to find? Should I call them air_shower_scripts?

The SimpleMCReconstruction.py and CostumHybridDetector.py scripts should work with the newest changes, they broke because the interpolater package was not installing properly.

However, some new tests with the new scripts you added would indeed be good. Though I would say this goes in a new PR.

@lpyras
Copy link
Collaborator

lpyras commented Jan 30, 2025

I tried to clean up. I am happy to approve this PR now.

lpyras
lpyras previously approved these changes Jan 30, 2025
Copy link
Collaborator

@MijnheerD MijnheerD left a comment

Choose a reason for hiding this comment

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

Why is it necessary to check for the number of observers and block interpolation with less than 50 antennas? If someone wants to try interpolation with few observers (eg for testing), they should be able to. I don't think it is up to this module to perform these checks, I think we can leave this responsibility to the user.

@@ -303,6 +303,13 @@ def initialize_efield_interpolator(self, interp_lowfreq, interp_highfreq, **kwar

return None

if self.obs_positions_showerplane[:, 0].shape[0] < 50:
Copy link
Collaborator

Choose a reason for hiding this comment

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

Where does the number 50 come from?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I agree, that does not make much sense to me.

Copy link
Collaborator

Choose a reason for hiding this comment

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

It’s not a great solution. I did that because I tried the module with a non-star shape pattern coreas file. So ideally one would check if the observer positions are a star shape pattern.

from NuRadioReco.utilities import units
from NuRadioReco.detector.detector import Detector
import NuRadioReco.modules.io.coreas.readCoREASStation
import NuRadioReco.modules.efieldToVoltageConverter
import NuRadioReco.modules.RNO_G.hardwareResponseIncorporator
import NuRadioReco.modules.channelGenericNoiseAdder
import NuRadioReco.modules.channelGalacticNoiseAdder
#import NuRadioReco.modules.channelGalacticNoiseAdder
Copy link
Collaborator

Choose a reason for hiding this comment

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

If the import statement is not necessary, please remove it entirely. The module exists though, so why remove this? Was it causing problems for you?

Copy link
Collaborator

Choose a reason for hiding this comment

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

The galactic noise adder has a lot of dependencies. I thought for an example it is better if you don’t have to deal with them.

@@ -540,7 +540,7 @@ def add_electric_field_to_sim_station(

def calculate_simulation_weights(positions, zenith, azimuth, site='summit', debug=False):
"""
Calculate weights according to the area that one simulated position in readCoreasStation represents.
Calculate weights according to the area that one observer position in a start shape patter represents.
Copy link
Collaborator

Choose a reason for hiding this comment

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

Typos

if n_positions < 50:
logger.warning(
f"Only {n_positions} observer positions given to calculate weights. This is likely not a star shape pattern. Weights are set to 1.")
return np.ones(n_positions)
Copy link
Collaborator

Choose a reason for hiding this comment

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

Similar to a previous comment, why is this should a deal breaker? And where does the number 50 come from?

Copy link
Collaborator

Choose a reason for hiding this comment

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

The weight function is made for star shape pattern coreas files. It doesn’t really work for other observer positions. It’s not great solution I agree.

@@ -53,13 +54,14 @@ def run(self, detector):
corsika_evt = coreas.read_CORSIKA7(input_file)
coreas_sim_station = corsika_evt.get_station(0).get_sim_station()
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we still need the sim station if the zenith/azimuth come from the shower now?

@fschlueter
Copy link
Collaborator

One comment: For the future, it might be useful to add a module which can export the interpolated simulation to a CoREAS style hdf5 file?

@lpyras
Copy link
Collaborator

lpyras commented Jan 30, 2025

Why is it necessary to check for the number of observers and block interpolation with less than 50 antennas? If someone wants to try interpolation with few observers (eg for testing), they should be able to. I don't think it is up to this module to perform these checks, I think we can leave this responsibility to the user.

Okay, I get your point. I stumbled over this, because I tried the examples with the example data, that lead to a lot of not understandable errors. Should we make a check for star shape patterns? Otherwise we could use a different example shower?

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.

6 participants