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.

Sign up for GitHub

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

Jump to bottom

Mention the ability to disable output connections #433

Merged
merged 1 commit into from
Aug 2, 2024
Merged

Mention the ability to disable output connections #433

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 24 additions & 2 deletions doc/lsst.pipe.base/creating-a-pipelinetask.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -415,7 +415,8 @@ The dimensions of the task itself can also be modified in ``__init__``, where ``
self.inputs.remove("background")

This still works, but it is more verbose and less intuitive than the now-recommended attribute-manipulation approach.
It is now no longer to delegate to `super` in either case, since the base class `super` does nothing (the first steps of initialization are instead handled by a metaclass).
It is now no longer recommended to delegate to `super` in either case,
since the base class `super` does nothing (the first steps of initialization are instead handled by a metaclass).


The last step in modifying this task will be to update the ``run`` method to
Expand Down Expand Up @@ -472,8 +473,29 @@ passed on to the run method. The body of the run method checks if the background
has been passed, and if so adds it back in and does a local background
subtraction.

To bring this all together, see :ref:`pipeline-appendix-c`
To bring this all together, see :ref:`pipeline-appendix-c`.

The same mechanism works for output connections:
an output from a `PipelineTask` can be made optional (under config control)
or a config switch can even be used to choose between different ways of
providing output.
Copy link
Member

Choose a reason for hiding this comment

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

Might be worth clarifying that this is different from making an input optional at runtime by setting minimum=0 in the Input connection declaration. In the configuration case, the connection is treated as if it never existed by QG generation and execution code, while minimum=0 allows a quantum to be generated and run even no dataset for that input are found. (There is no minimum for Output connections because they are always considered runtime-optional.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Let me know if you think I've captured it now.


Note that disabling a connection via this mechanism, during initialization,
has the same effect on quantum graph generation and execution as if the
connection had never existed.

Run-time optional inputs
------------------------

A separate mechanism exists that allows an `Input` connection to be made
run-time optional.
If the `Input.minimum` attribute is initialized to zero for a connection,
graph-building will still generate a quantum, and the `PipelineTask` will
be run, even if no dataset for that input can be found.

Output connections are run-time optional by definition; it is always possible
for a `PipelineTask` to produce no output; that by itself is not treated as
an error condition.

----------------------------------------
Dataset name configuration and templates
Expand Down
Loading