-
Notifications
You must be signed in to change notification settings - Fork 18
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
New implementation of the nectarchain module #82
New implementation of the nectarchain module #82
Conversation
-update SPE fit parameters initialization following updates of the ctapipe extractors -improve the limits of generated charge histogram plots
and ChargesContainer following events_id
-container module for the data structure (to be extend) -makers module to make the computation of calibration quantities on the data structure
with n and p' fixed
at nominal voltage + update of user script
pre-computed one
the fitting process continues although the initial parameters computation failed
+ data management with max_events parameter
will return a generator to only load the slices one by one during execution -> reduce the RAM needed
at nominal voltage (config files) -change SPE fit plotting matplotlib -> pyqtgraph to speed up the plots generation
Hi @guillaumegrolleron , Thank you so much for that! I am currently testing Otherwise, the tools to extract waveforms and charges work like a charm ! |
When testing the new implementation, we (@guillaumegrolleron and I) came across one issue: when pre-extracting waveforms and charges from *.fits.fz files and outputting them as HDF5 files using the script For instance:
returns:
|
-bugfix : check valididty of container before to write when finishing component
-creation of your own component and tool -SPE tools use -exctraction of waveforms and chgares with tools and components.
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
of the nectarchain module -typo fix -overwrite argument of tool better defined
Now the read of a container will always return a generator, which can be ciomposed by only one item.
Hi all, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you so much, @guillaumegrolleron , this is a huge piece of work!
I just have a small request concerning ignoring Jupyter notebooks and enabling pre-commit
hooks, in order to automaically convert them as python scripts before pushing them to the repo.
Thanks!
Thanks a lot for the hard work ! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot, @guillaumegrolleron !
I made a last check re-running the SPE fit first extracting the waveforms from a fits.gz file, and running the SPE fits on the intermediate HDF5 file, all fine !
I am merging this PR now.
In this PR, I finished to re-implement the
nectarchain
module following thectapipe
framework.We are no longer using format defined in
nectarchain
to save waveforms, charges or calibrations coefficients. Now all the data are based on the 'ctapipe.containers' classes. Everything is stored in hdf5 format.Moreover, a general skeleton has been developed ('EventsLoopNectarCAMCalibrationTool'), based on the
ctapipe.tool
feature. Basically this top class has a Component member that can be overload, which contains the names of thectapipe
component
that will be apply on each events. The goal is to make future development easier, we only need to write newcomponent
which will perform the work. The whole management of the loop over events as well as the writing to output file is managed by thenectarchain
module. A Tutorial notebook to explain how to develop new features through theComponent
workflow will come in upcoming commits.I have yet completely rewrite the waveforms, charges extraction, and the gain computation (with both SPE fit and photo-statistic method) following this new implementation.
I also wrote a lighter
EventSource
than the one that we were using fromctapipe_io_nectarcam
to speed up the loop over events.There are some technical points for which I would like to have the point of view of
ctapipe
experts, such as the transmission of the configurabletraits
defined incomponent
to thetool
containing thatcomponent
, to make them visible at thetool
creation level.Some points are still missing as will come in an upcoming PR :
-Unit test rewriting
-Documentation
-cleaning + change module names following PEP recommendations
-WT SPE reimplementation