Skip to content

MAPED data merging with Torch#204

Open
henrygbell wants to merge 157 commits into
electronmicroscopy:nanobeamfrom
henrygbell:nanobeam
Open

MAPED data merging with Torch#204
henrygbell wants to merge 157 commits into
electronmicroscopy:nanobeamfrom
henrygbell:nanobeam

Conversation

@henrygbell
Copy link
Copy Markdown
Collaborator

What does this PR do?

This PR is the torchified version of PR-169. For my data it speeds the merge_datasets method up by ~10x or more and adds batching.

Example notebook

maped_test_nb_torch.ipynb

Data for that notebook

Download here

For reviewers:

Please test the code on your own datasets! Check the code for accuracy. Let me know if you have any suggestions

TODO next:

  • Can we optimize this torch version?
  • dscan alignment

henrygbell and others added 19 commits April 2, 2026 15:06
…eeds to be overloaded is set_optimizer for PPLR cases
…to do the matching in set_optimizer instead of parsing in optimizer_params maybe?
… to check: Look at object_models.py and see how the optimizer matching should be handled. It seems like set_optimizers doesn't really do what it's supposed to do.
… probably have to do TV loss computation within the model?
…well. Only things to ask Corneel about is multiscale res since this adds a significant amount of compute. Should I be doing variable num_samples_per_ray?
…t DDP, clean-up KPlanes, fix up object_models.py since it's insanely cluttered now
@bobleesj
Copy link
Copy Markdown
Collaborator

Happy to review and also address the remaining bottleneck. @henrygbell

@bobleesj
Copy link
Copy Markdown
Collaborator

@gvarnavi seems like CI tests aren't running on branch PRs, could we also add automated workflows? I want to ensure that this torch refactoring doesn't break the existing maped pytest.

Copy link
Copy Markdown
Collaborator

@bobleesj bobleesj left a comment

Choose a reason for hiding this comment

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

@henrygbell I spent 15-20 mins reviewing. Before I run with real data, I noticed that new utility torch functions were added. It is not required to write unit tests for each (if you want, better if you compare against scipy/numpy) but at least we need to know that we maintain parity after refactoring. Please see the drift PR below where torching was done but no API/accuracy was changed

Ref: https://github.com/electronmicroscopy/quantem/pull/206/changes#r3040892988.

After your feedback, I will test with the data we collected at snsf.

pad_val: str | float = 0.0,
shift_method: str = "bilinear",
):
class MAPEDTorch(AutoSerialize):
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

general comment - we need an end-to-end test either with synthetic data or data that used before refactoring w/ torch to ensure nothing broke in this PR. Then I would be more comfortable reviewing this.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

second comment is that did the API or is it just torching without any user behavior modified? Please indicate that so that we don't need to worry about backward compatability in your PR comment

Comment thread src/quantem/diffraction/maped.py Outdated

Parameters
----------
edge_blend
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

pls follow numpy docstring - parameter type missing.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

important for doc api doc rendering automated

Comment thread src/quantem/diffraction/maped.py Outdated

Stores
------
self.scales : torch.tensor
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

yeah here i see paramters

- compute mean BF and mean DP summaries,
- choose/find diffraction origins,
- align diffraction space and real space,
- merge datasets into a single composite Dataset4dstem.
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

good

Comment thread src/quantem/diffraction/maped.py Outdated
stack[ind] = np.fft.ifft2(F * ramp).real
Parameters
----------
origins
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

numpy doc, same comment

Comment thread src/quantem/diffraction/maped.py Outdated
mode="constant",
cval=0.0,
prefilter=False,
Stores
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

stores or returns?

return w
if alpha >= 1:
return torch.hann_window(N, device=device, dtype=dtype)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

just code comment - no extra whitespace needed, fewer lines better in general so that we don't have to scroll too much. I

…ositionModel ABC, make sure to have a property for which kind of tensor decomposition method is being used. SO3Params are moved to a different file, thinking of making a kplanes_utils.py. Starting reorganization of object_models.py to have ObjectINR and ObjectTensorDecomp
… of parameters now that helps with type-setting. The main reason for having model_base.py as is it is right now is if we ever wanted to go do TensoRF or something just to validate
cophus and others added 29 commits June 2, 2026 10:57
@bobleesj
Copy link
Copy Markdown
Collaborator

bobleesj commented Jun 3, 2026

@henrygbell seems like we are having some PR synching issues here as well.

A few things to check

  1. upstream/namoeam is getting old, it is diverging from upstream/dev. Why don't you just make MAPED code merged to upstream/dev after making upstream/nanobeam merged to upstream/dev`? Please chat with @cophus

This `upstream/nanobeam' is getting a bit too old where problems are starting to occur

#235 (comment)

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.

9 participants