thorstone25 / qups Goto Github PK

Error using example_ (line 57)
Error setting default value of property 'impulse' of class 'Transducer':
Undefined function 'mustBeScalarOrEmpty' for input arguments of type 'Waveform'.

There seems to be an issue on macs where QUPS is on the path, but "ChannelData" is not a recognized class. It seems it could be a bug with MATLAB's path resolution, or perhaps a subtlety of how macs handle path resolution differently from Ubuntu or Windows.

Would it be possible to have an example of Eikonal beam-forming with heterogeneous sound speed fields? Seems unsupported for now.

It appears that parallel SIMUS doesn't work out of the box. I just downloaded the MUST toolbox and ran into the following error:

Error using simus (line 293)
DATENUM failed.

Error in UltrasoundSystem/simus (line 682)
            parfor (m = 1:M, kwargs.parcluster)

Caused by:
    Error using datenummx
    Use of function datenummx is not supported on a thread-based pool.

I suspect that MUST doesn't support this type of parfor syntax natively. It might require working with the maintainer to figure out a workable solution.

It appears every now and then, the UltrasoundSystem.DAS() returns all 0s on CUDA-enabled computers. I think its likely related to the ptx-file version. It's unclear why exactly this happens, whether it's related to MATLAB or CUDA behaviour or simply versioning issues, but is likely related to the ptx-file version.

Recompiling by running setup cache and recreating the UltrasoundSystem or us = UltrasoundSystem('recompile', true); should provide a work-around for now.

Currently I have something working for Windows compilation in my fork. How best do you want to proceed in merging it?

When I tried using the aperture growth apodization function with a curvilinear transducer (TransducerConvex), I got a warning that only linear arrays (TransducerArray) are currently supported. Are you planning on expanding the implementation of that apodization function to include curvilinear transducers in the near future?

Computing the beam pattern seems to be a very useful feature. It can be used for analyzing a custom Transducer or defining default apodization schemes.

FieldII has calc_hp for this. MUST computes the beam pattern via pfield or pfield3. k-Wave would require just recording p_max(x,y,z) throughout the field rather than p(x=x0,y=y0,z=z0,t) at the transducer surface over time.

To implement this per simulator, one needs to:

1. Expand the existing respective function to take an input to compute echo (default) or field and select the aperture tx (default) or rx.
2. Make a branch (i.e. if-else or switch-case) to preserve the existing functionality
3. Forward the relevant arguments to the field simulator

• For FieldII / MUST, that means us.scan.positions to calc_hp or pfield
• For k-Wave that means sensor.record = 'p_max' and bypassing the receive aperture post-processing

4. Return a regular array instead of ChannelData defined on us.scan (like the beamforming functions).
5. Update the documentation