Skip to content

More ImPACT code cleanup#2705

Open
gschwefer wants to merge 10 commits into
cta-observatory:mainfrom
gschwefer:impact_code_cleanup_and_fixes
Open

More ImPACT code cleanup#2705
gschwefer wants to merge 10 commits into
cta-observatory:mainfrom
gschwefer:impact_code_cleanup_and_fixes

Conversation

@gschwefer

Copy link
Copy Markdown
Contributor

Hi everyone,

I finally got around to clean up the ImPACT code a bit more.

This PR has 3 major changes:

  • The paths to the input templates are now TelescopeParameters. I also changed the required structure of the templates, they now need to contain a new key tel_type which contains the telescope description as a string to check if they are valid for the telescope they are being used for. This will require a little fix to all currently existing templates, but it is an easy and quick one.
  • The pedestal and spe width parameters are now also TelescopeParameters. For the pedestal_width, I also included the option to read them from the monitoring. In case no values are specified, they fall back to a hardcoded value in a global dict.
  • Finally, for the tests, I removed the need for the dummy_reconstructor option/variable

I look forward to your comments and to discussion on the implementation of these things.

Comment thread src/ctapipe/reco/impact.py Outdated
filename, role="ImPACT Time Template file for " + tel_type[t]
for template_path, tel_ids in template_sort_dict.items():
net_interpolator = TemplateNetworkInterpolator(
template_path, bounds=((-5, 1), (-1.5, 1.5))

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Is it really wise to hardcode the bounds of the templates this deep into a function? I think you should at least extract these definitions to some global constants at the top of the file.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Yes putting them as a global constant is better than this

Comment thread src/ctapipe/reco/impact.py
@ctao-dpps-sonarqube

Copy link
Copy Markdown

Failed

  • 30.32% Duplicated Lines (%) on New Code (is greater than 3.00%)
  • 76.20% Coverage on New Code (is less than 80.00%)

Analysis Details

7 Issues

  • Bug 0 Bugs
  • Vulnerability 0 Vulnerabilities
  • Code Smell 7 Code Smells

Coverage and Duplications

  • Coverage 76.20% Coverage (94.10% Estimated after merge)
  • Duplications 30.32% Duplicated Code (0.90% Estimated after merge)

Project ID: cta-observatory_ctapipe_AY52EYhuvuGcMFidNyUs

View in SonarQube

@ParsonsRD

Copy link
Copy Markdown
Member

Hi all, are there any actions that are needed to merge this PR? I think these commits are an important step to prepare for a FreePACT PR.

@kosack kosack assigned kosack and maxnoe and unassigned maxnoe and kosack Dec 2, 2025
@kosack kosack requested review from kosack and maxnoe December 2, 2025 09:23
@maxnoe

maxnoe commented Dec 2, 2025

Copy link
Copy Markdown
Member

@kosack @ParsonsRD the static analysis was failing with lots of duplicated code and too little coverage, so I didn't yet have a deeper look.

30 % duplications is quite a lot...

The branch needs an update with main also.

impact_reco = ImPACTReconstructor(example_subarray, table_profile)
for tel_type in example_subarray.telescope_types:
create_dummy_templates(
str(tmp_path) + "/{}.template.gz".format(str(tel_type)),

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Suggested change
str(tmp_path) + "/{}.template.gz".format(str(tel_type)),
tmp_path / f"{tel_type}.template.gz",

[
"type",
"MST_MST_FlashCam",
str(tmp_path) + "/MST_MST_FlashCam.template.gz",

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Suggested change
str(tmp_path) + "/MST_MST_FlashCam.template.gz",
tmp_path / "MST_MST_FlashCam.template.gz",

spe = 0.6 # Also hard code single p.e. distribution width
# The SPE and pedestal width parameters are also configurable as TelescopeParameters.
# None is allowed and the default value. In that case, either values from the event monitoring data are used
# or if that is also not available, a value from a hardcoded backup dict is used.

@kosack kosack Dec 2, 2025

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I think that is a bad idea, since it means if somebody forgets to set a correct value, the backup value is silently used, and it is not clear to the user that that happened. It would be better to have it fail if a telescope type is not specified, especially since the backup values are wrong for Prod6. The backup values don't even end up in the provenance log, since they are set outside the configuration system.

I would just remove BACKUP_PED_TABLE and BACKUP_SPE_TABLE, and instead add a sample configuration file to the resources directory and update ctapipe-quickstart to export it (or modify the existing example file) if you really want to have some defaults. However, even there it's not such a good idea since they are really only correct for one PROD.

Eventually (but perhaps in a future PR if it's too complex), these should just be read from the interpolated monitoring data produced by the MonitoringSource, which you can access via the event itself: that's possible already for the pedestal width (after ctapipe-v0.27, see changelog), but I think not yet for the PE/DC ratio. With that, you don't even have to specify a fixed pedestal variance or PE/DC ratio, since that allows it to vary during an observation. That's much safer, since the user doesn't have to copy this information into the config file.

mask = event.dl1.tel[tel_id].image_mask
if self.pedestal_width.tel[tel_id] is None:
if event.mon.tel[tel_id].pedestal.charge_std is None:
ped_dict[tel_id] = BACKUP_PED_TABLE[

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I would just remove this fallback (see prev comment), and just require that the user use a proper configuration file.

@kosack

kosack commented Dec 2, 2025

Copy link
Copy Markdown
Member

Also, please rebase this on the main branch, since the reason the tests are not all passing is just that some things were changed in the test configuration (like the SonarQube server) since this MR was opened.

@gschwefer

Copy link
Copy Markdown
Contributor Author

Thanks for the review @maxnoe @kosack, I'll have another look

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.

5 participants