Remove the nosfts output from lalpulsar_MakeSFTs and allow channel skipping in Fscan programs

Description

This MR removes the nosfts file output from lalpulsar_MakeSFTs if that program was given the --allow_skipping=TRUE option. Instead we spread to the other Fscan programs the --allow_skipping option so that the program is more robust to no SFT files potentially being present and we will instead rely on the parent-child relationship of the Fscan DAG workflow.

API Changes and Justification

Backwards Compatible Changes

• This change does not modify any class/function/struct/type definitions in a public C header file or any Python class/function definitions
• This change adds new classes/functions/structs/types to a public C header file or Python module

Backwards Incompatible Changes

• This change modifies an existing class/function/struct/type definition in a public C header file or Python module
• This change removes an existing class/function/struct/type from a public C header file or Python module

In the rare case (Fscans only) where --allow_skipping=TRUE was provided, then the function to make the nosfts file was called. I have removed this function because I don't want to worry about using the HTCondor file transfer system to transfer this file back to the home filesystem

Review Status

No review started yet. I need to discuss this MR further with @karl-wette @ansel-neunzert

assigned to @evan-goetz

added apimajor lalpulsar labels

added 1 commit

• 7604bee9 - Remove the nosfts output from lalpulsar_MakeSFTs and allow channel skipping in...

Compare with previous version

added 1 commit

• 0c062dc5 - Remove the nosfts output from lalpulsar_MakeSFTs and allow channel skipping in...

Compare with previous version

added 1 commit

• 1ae0777b - Remove the nosfts output from lalpulsar_MakeSFTs and allow channel skipping in...

Compare with previous version

@evan-goetz I had interpreted the original implementation as drawing a distinction beween the two cases

1. no SFTs available due to missing channels
2. no SFTs available due to random other MakeSFTs errors

where 1 seemed to be an "expected" error mode, hence a "carry on" for the rest of the pipeline seeming sensible, while 2 could indicate deeper issues and should result in a failure.

If that wasn't the intention, your solution seems fine. But if having that distinction is worthwhile, maybe one of the other options from #770 (closed) are needed?

marked this merge request as ready

requested review from @karl-wette and @david-keitel

@ansel-neunzert do you have any feedback on this MR to remove the nosfts file output in case of missing channels or too low data rate channels in the list of channels? This presence of this file is impossible to predict in advance of opening frame files, so it cannot be passed back the HTCondor file transfer and listed as a file in the submit file.

Fscan will need to adapt to not having this nosfts file, which I am working on a separate update for that project.

Let me know if you have questions.

resolved all threads

approved this merge request

@evan-goetz I've approved this, but will leave for you to merge when you're ready, e.g. after you've heard back from @ansel-neunzert

marked the checklist item This change removes an existing class/function/struct/type as incomplete

marked the checklist item This change does not modify any class/function/struct/type definitions as completed

@evan-goetz There is a new LALSuite release off master being planned, and I assume we'd want to include this? If this is ready to merge, please go ahead.

(Also: this doesn't actually include any API changes, so I've changed the description to "Backwards Compatible Changes".)

added apinone label and removed apimajor label

resolved all threads

merged

mentioned in commit 63bb7a8b

mentioned in issue #770 (closed)

mentioned in merge request !2428 (merged)