P/transducerdef update

[peterhollender]

This makes some substantial changes to the way we store transducer definitions on disk, and carries these changes throughout the codebase. Major updates include:

1. A new TransducerArray class that explicitly holds multiple TransformedTransducers (also a new class - a thin wrapper for Transducers). This allows for per-module modification of module positioning and properties, with a simple to_transducer method that bakes array together into a single conventional Transducer.
2. The addition of sensitivity and impulse_response attributes to Transducer, which propagate down to elements. The split of sensitivity means that impulse responses are no longer length-1 arrays when they mean to encode simple scaling, In both cases, these attributes also exist for Element, and are elegantly ignored when set to None. The to_dict and from_dict methods have been updated to exclude these attributes if they are None, since they will pick up the None on instantiation, and it would create confusing verbiosity in the .json files for users not actually specifying them for both Transducer and Element. The addition to Transducer has the benefit of making the json file shorter - if you determine that your array is less, sensitive, you don't need to change every element, just the overall sensivity.
3. Compression of Element attributes (x,y,z becomes position, length,width becomes size, and az,el,roll become orientation.
4. A module_invert attribute has been added to Transducer, which trickles through to register computation, allowing particular modules to invert their output to compensate for flipped polarity arrays
5. The io module has been updated to handle the module_invert attribute
6. Solution objects now carry around the Transducer that was used in their creation. This alleviates the need to separately carry around the Transducer for bringing it's module_invert attribute into LIFUInterface.set_solution
7. DVC is updated with new example transducers.
8. Updates some of the example scripts in notebooks
9. Updates unit tests to account for these changes

[ebrahimebrahim]

I think you forgot to dvc push

[ebrahimebrahim]

Heads up that I will start pushing to and potentially rebasing this branch as I work on upgrading SlicerOpenLIFU to it. I've reviewed much of the code and it looks good -- no changes will be requested from your end. It's in my hands now.

Couple of initial comments below on the DVC data.

---

Did you mean to add these users shown in green? I will remove them if not

---

The transducer openlifu_2x400_evt1_005 was not added to the transducers.json, so I will add it

[ebrahimebrahim]

There is a folder db_dvc/transducers/openlifu_2x400_evt1/openlifu_1x400_evt1 that I think wasn't supposed to be there. I will delete it

[ebrahimebrahim]

This is raised when using the openlifu_2x400_evt1_005.json example, because len(self.impulse_response) is 1 in that example:

{
    "type": "TransducerArray",
    "id": "openlifu_2x400_evt1_005",
    "name": "OpenLIFU 2x 400kHz EVT1 S/N 005",
    "modules": [
        {
            ...,
            "impulse_response": [
                1350.0
            ],
            ...,
        },
        ...,
    ]
    ...,
}

[ebrahimebrahim]

This issue is making it so that the transducer openlifu_2x400_evt1_005.json cannot be loaded into SlicerOpenLIFU. But I am not sure how to fix it unless I understand the intention behind enforcing len(self.impulse_response)<2.

Once way to see this error in the unit tests for quick debugging is to change impulse_response in tests/resources/example_db/transducers/example_transducer_array2/example_transducer_array2.json to a list of length 1 instead of 2 by deleting an element.

[peterhollender]

Ooh maybe the re-uploaded dvc doesn't have the correct fixes...

[ebrahimebrahim]

Note that there is no way to write a TransducerArray to database. If that's something we want to support we could open an issue.

EDIT: Correction -- you can use Database.write_transducer on a TransducerArray, and it should use TransducerArray's to_file, but for reasons I can't remember it did not work out for me. So in any case something has to be done if we want to support writing TransducerArray to database

[ebrahimebrahim]

Alright, everything looks good now and I think it's all working in SlicerOpenLIFU branch here: OpenwaterHealth/SlicerOpenLIFU#478, with the exception that openlifu_2x400_evt1_005.json cannot be loaded in SlicerOpenLIFU as indicated in the comment. This is not part of any actual example session though, so no sessions are broken.

I think it just remains to fix the openlifu_2x400_evt1_005.json example if you want to, and if you don't then let me know and I will merge

[ebrahimebrahim]

Thanks for fixing the _005 definition -- it loads in SlicerOpenLIFU now!

Merging!