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.

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

Refactor for next Sciline (Optional, param tables, and more) #135

Merged
merged 22 commits into from
Jun 17, 2024

Conversation

SimonHeybrock
Copy link
Member

@SimonHeybrock SimonHeybrock commented Apr 30, 2024

Changes:

  • Add helpers such as set_banks, replacing Pipeline.set_param_table.
  • Remove complicated multi-step helpers for run and bank merges.
  • Small changes to work with new way of Optional handling by Sciline.
  • Change masking.py to work more cleanly without param table with a small local workflow structure change.

Notes:

  • Depends on Sciline@main, need to update deps once released.
  • Depends on fixes in Cyclebane which are not even in it's main yet.

Fixes #97.
Fixes #142.

@SimonHeybrock SimonHeybrock requested a review from nvaytet April 30, 2024 12:31
nvaytet
nvaytet previously approved these changes May 2, 2024
docs/user-guide/common/beam-center-finder.ipynb Outdated Show resolved Hide resolved
@SimonHeybrock SimonHeybrock changed the title Refactor for Sciline's future handling of Optional Refactor for next Sciline (Optional, param tables, and more) Jun 6, 2024
@@ -32,10 +32,10 @@ def __getattr__(self, name: str) -> NoReturn:
# Needed for type annotations
MatrixWorkspace = object

Period = NewType('Period', int)
Period = NewType('Period', int | None)
Copy link
Member Author

Choose a reason for hiding this comment

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

I was not sure if the Optional should be absorbed into the aliases like this. As it is now it is less explicit on the user side, but requires less changes. If we don't like it we can change later on?

Copy link
Member

Choose a reason for hiding this comment

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

I prefer it like this, never really liked the Optional thing anyway

@SimonHeybrock SimonHeybrock marked this pull request as ready for review June 6, 2024 06:57
@SimonHeybrock SimonHeybrock requested a review from nvaytet June 6, 2024 06:58
Copy link
Member

@nvaytet nvaytet left a comment

Choose a reason for hiding this comment

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

DId you verify that the results are identical to what you get from main?

"workflow[DirectBeamFilename] = isis.data.zoom_tutorial_direct_beam()\n",
"workflow[isis.CalibrationFilename] = isis.data.zoom_tutorial_calibration()\n",
"workflow[Filename[SampleRun]] = isis.data.zoom_tutorial_sample_run()\n",
"workflow[Filename[EmptyBeamRun]] = isis.data.zoom_tutorial_empty_beam_run()\n",
"workflow[isis.SampleOffset] = sc.vector([0.0, 0.0, 0.11], unit='m')\n",
"workflow[isis.DetectorBankOffset] = sc.vector([0.0, 0.0, 0.5], unit='m')\n",
"masks = isis.data.zoom_tutorial_mask_filenames()\n",
"workflow.set_param_series(PixelMaskFilename, masks)"
"workflow = set_pixel_mask_filenames(workflow, masks)"
Copy link
Member

Choose a reason for hiding this comment

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

I wonder if users would find this syntax confusing/unusual.
Everything above seems to be operating in-place on the workflow (using setitem), but this one takes in the workflow as an argument, and returns an updated workflow.

I know we want to try and hide map and reduce from users, so they don't have to do it themselves, but I'm predicting that some will be confused by this.

That said, I'm not sure how to fix it, because you can't set a method on the workflow like workflow.set_pixel_masks_filenames(masks) as it's specific to this workflow...

Maybe it's again a case of leaving it for now and finder a better solution later when we've had more experience using it?

Copy link
Member

Choose a reason for hiding this comment

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

I guess when all this will be hidden inside small widgets, it won't be very important anymore...

Copy link
Member Author

Choose a reason for hiding this comment

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

Alternatives are:

  • Make this arguments of the workflow creation, LokiWorkflow(sample_runs=..., ...).
  • Turn LokiWorkflow into a builder (using builder pattern):
    workflow = LokiWorkflow()
    workflow.set_sample_runs([...])
    workflow.build()  # or build automatically in `workflow.compute()`, by making this a wrapper.
  • Turn LokiWorkflow into a wrapper, with internal reference to the pipeline. Dedicated methods can set and update the internal workflow.

I think neither of those options is too crazy, but we should probably give it more thought, and gain some more experience using this.

I opened scipp/essreduce#35 for tracking this.

@@ -308,6 +305,7 @@
"metadata": {},
"outputs": [],
"source": [
"workflow = sans.set_banks(workflow, banks=['larmor_detector'])\n",
Copy link
Member

Choose a reason for hiding this comment

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

So do we still have to do a mapping when we only have a single bank?

Copy link
Member Author

Choose a reason for hiding this comment

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

No, I think I put it there having the full Loki in mind, to make it easier to modify in the future. Should I remove it?

Copy link
Member

Choose a reason for hiding this comment

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

I would say yes

@@ -558,11 +556,8 @@
"workflow[DimsToKeep] = []\n",
"\n",
"# Set parameter series for file names\n",
Copy link
Member

Choose a reason for hiding this comment

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

Outdated comment?

@@ -32,10 +32,10 @@ def __getattr__(self, name: str) -> NoReturn:
# Needed for type annotations
MatrixWorkspace = object

Period = NewType('Period', int)
Period = NewType('Period', int | None)
Copy link
Member

Choose a reason for hiding this comment

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

I prefer it like this, never really liked the Optional thing anyway

)


def to_detector_mask(
Copy link
Member

Choose a reason for hiding this comment

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

This makes more sense 👍

@SimonHeybrock
Copy link
Member Author

DId you verify that the results are identical to what you get from main?

Only by eye, looking at the figures in the notebooks.

@nvaytet
Copy link
Member

nvaytet commented Jun 11, 2024

Only by eye, looking at the figures in the notebooks.

I think it would be good to check the values.

@SimonHeybrock
Copy link
Member Author

Only by eye, looking at the figures in the notebooks.

I think it would be good to check the values.

I updated the Loki I(Q) test to verify against reference files. I created those by running the same test on main. The files have been added to this repo in this branch. I excluded the "upper-bound" mode for now, since we expect changes there soon (masking?), which would break the test. Since this PR is unrelated to the uncertainty broadcast mode I think we can just add those reference files later, if desired.

@@ -19,6 +19,10 @@
:recursive:

providers
set_background_runs
Copy link
Member

Choose a reason for hiding this comment

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

As was suggested in scipp/essdiffraction#63, should we rename to with_*?

Otherwise, everything looks good 👍

Copy link
Member Author

Choose a reason for hiding this comment

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

Done

@SimonHeybrock
Copy link
Member Author

I updated to the released Sciline. I believe all comments have been addressed so I will merge and release once the builds pass.

@SimonHeybrock SimonHeybrock merged commit 7d6a037 into main Jun 17, 2024
3 checks passed
@SimonHeybrock SimonHeybrock deleted the sciline-next2 branch June 17, 2024 05:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Refactor for next Sciline release Explicit merge / accumulation strategies and customization points
2 participants