Refactoring coreas to include interpolation #688
Conversation
…ing readCoREAS.py which reads a random position and readCoREASStationGrid.py which takes the closest observer in an array. Now readCoREASDetector.py can be used to read an array and get the interpolated position.
…na position) code seems to give expected results now.
… improve docstring
|
@MijnheerD @lpyras I'm getting these warning from the interpolator module all the time: are we not using the interpolator correctly? |
…test will be part of PR #689
|
@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? |
|
The output of the reconstruction looks like this.
|
@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? |
I tested it before the coreas refactoring for effective area calculation. That yielded reasonable results. |
|
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. :) |
|
Sorry for coming in late on this, I thought I already answered some the questions but apparently I didn't.
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
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. |
|
I just tested the branch and it actually fails with a pip installed cr_interpolator on: |
|
So the automatic build fails on the cr_interpolator not being installed, but even if you pip install it, it doesn't work. |
|
Ah, @lpyras just reminded me that this is known and a new release is being worked on. Then I can do the homework as assigned by @MijnheerD to me check whether the reconstruction is indeed what we have done for LOFAR. |
There was a problem hiding this comment.
The readCoREASDetector module looks good, but there is still some more cleanup to do in the coreas.py file. Specifically there are several points where explicit units are used, instead of the internal unit system. On some occasions the z-coordinates are fixed to some value, which I also think is very dangerous because the user does not see this and it might lead to unintended bugs. Lastly I don't see the purpose of the several getter-function that are there. If we think these attributes should be hidden from the user in such a way that they cannot alter them, then we should make proper properties of them. But right now they serve little purpose.
| Parameters | ||
| ---------- | ||
| zenith : float | ||
| zenith angle in radians |
There was a problem hiding this comment.
I think it is better to make use of the internal units here and everywhere else in the file
There was a problem hiding this comment.
radiants is the default units. You mean I should add a /units.rad?
There was a problem hiding this comment.
Yes, in case the internal system would change at some point :)
There was a problem hiding this comment.
I realised that I am not being very clear here, sorry. What I was specifically pointing to is that fact that you assume the zenith angle is given in radians (according to the docstring). But I would not do that/write it like that, ie what we really expect is the angle given in internal units. And then later, when calling the radiotools functions, we should indeed add / units.rad to explicitly convert to radians (in case the internal units would ever change)
| efield_on_sky = cs.transform_from_ground_to_onsky(efield_geo) | ||
|
|
||
| if prepend_zeros: | ||
| # prepend trace with zeros to not have the pulse directly at the start |
There was a problem hiding this comment.
I don't know if this is the best way of achieving this goal. Adding more timesamples will alter the frequency spectra. Why not just roll the pulse to the center?
There was a problem hiding this comment.
Actually, is this really necessary? At least for the interpolator I think we solved the issue with pulses not being centered.
There was a problem hiding this comment.
This is old heritage... @cg-laser what should we do here?
There was a problem hiding this comment.
Just my two cents: What we have found in Auger is that the trace length by CoREAS can be to small resulting in a to large frequency resolution. However, what we would do is padding in the frequency domain.
There was a problem hiding this comment.
somebody wants to implement that?
| observer_position = np.zeros(3) | ||
| observer_position[0], observer_position[1], observer_position[2] = -position[1] * units.cm, position[0] * units.cm, position[2] * units.cm | ||
| observer_position = cs.transform_from_magnetic_to_geographic(observer_position) | ||
| observer_position = convert_obs_positions_to_nuradio_on_ground(position, zenith, azimuth, magnetic_field_vector) | ||
| core_position = (-observer_position + station_position) | ||
| core_position[2] = 0 |
There was a problem hiding this comment.
shower core is fixed to z=0, is that desired?
|
I try to address @MijnheerD suggestions. One question still open is the z coordinate of the shower. What should we do in sim_station? The height of the coreas shower? Where do we want the core position? In the same plane as the antenna? Should we remove make_sim_station() and make_sim_shower() as Mitja suggested? Any opinions? @cg-laser @fschlueter |
| def set_position_onsky(self, position): | ||
| """ | ||
| set position of the electric field in the on sky (vxB, vxvxB) coordinate system | ||
| """ | ||
| self._position_onsky = position | ||
|
|
||
| def get_position_onsky(self): | ||
| """ | ||
| get position of the electric field in the on sky (vxB, vxvxB) coordinate system | ||
| """ | ||
| return self._position_onsky | ||
|
|
There was a problem hiding this comment.
Why do we need to store these coordinates? Aren't they just a transformation of position?
| @@ -105,6 +105,8 @@ class showerParameters(Enum): | |||
| distance_shower_maximum_geometric = 10 #: distance to xmax in meter | |||
| distance_shower_maximum_grammage = 11 #: distance to xmax in g / cm^2 | |||
| parent_id = 12 #: id of parent in sim particles | |||
| core_coordinate_vertical = 13 #: vertical coordinate of the shower core used in corsika | |||
| coreas_GPSSecs = 14 #: Event time in GPS time of the shower in coreas | |||
There was a problem hiding this comment.
I dont think so, but it was stored in the previous implementation, that's why I added it.
|
|
||
| def read_CORSIKA7(input_file, declination=None): | ||
| """ | ||
| this function reads the corsika hdf5 file and returns a sim_station with all relevent information from the file |
There was a problem hiding this comment.
doc-string could be improved
| warning_printed_coreas_py = True | ||
| sim_station.set_is_cosmic_ray() | ||
| sim_station.set_simulation_weight(weight) | ||
| return sim_station | ||
|
|
||
|
|
||
| def create_sim_station(station_id, evt, weight=None): |
There was a problem hiding this comment.
Should this function also copy over traces?
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.