wedge definition

[andreasschumm]

We have implemented the MFMC 2 .0.0 specification for our UT propagation modeling software. I would like to comment on the wedge definition:

• I would suggest not to use normal information, but the more familiar incidence and roof angles, which are less susceptible of rounding errors. In practice, manufacturers will always provide angles, and never normal vectors.

• I found no way to represent the surface of the wedge in contact with the part. This is important for angle beam wedges, where some elements at the extreme ends of the transducer may have to be turned off when delay laws with large refracted angles are used.

• Would TRL wedges be implemented in terms of two distinct wedges (for the transmitter and the receiver part), or as single wedge?

[paulwilcox1971]

I would suggest not to use normal information, but the more familiar incidence and roof angles, which are less susceptible of rounding errors. In practice, manufacturers will always provide angles, and never normal vectors.

Noted. The general reason for using vectors and avoiding angles in the file spec is to avoid confusion from the multiple conventions used in 3D for angles (cf. a vector which is unambiguous). However, there is a more general point about standardising the naming of optional fields used to represent common parameters (e.g. incidence and roof angles for TRL probes) which the user group should look at.

I found no way to represent the surface of the wedge in contact with the part. This is important for angle beam wedges, where some elements at the extreme ends of the transducer may have to be turned off when delay laws with large refracted angles are used.

This should be possible within the current spec (Sec 4.3.2), by using the {probe}/WEDGE_SURFACE_POINT and {probe}/WEDGE_SURFACE_NORMAL parameters, which together define a plane representing the working surface of a wedge relative to the probe.

Would TRL wedges be implemented in terms of two distinct wedges (for the transmitter and the receiver part), or as single wedge?

Either of those methods is allowed by the file spec: Method 1: Define two separate probes (focal laws reference both probe and element and probe position during a scans can be specified separately for each probe used); Method 2: Define one single probe in the file that represents two physical probes (e.g. elements 1-32 in one physical probe, 33-64 in the second). From a software point of view, a probe is defined as a number of elements that remain in a fixed position relative to one another. For a TRL probe, either method can be used but Method 2 is perhaps most logical as all elements in both parts of the probe are fixed relative to one another when in operation. However, for a TOFD configuration where there is independent movement between two probes, Method 1 should be used.

[andreasschumm]

This should be possible within the current spec (Sec 4.3.2), by using the {probe}/WEDGE_SURFACE_POINT and {probe}/WEDGE_SURFACE_NORMAL parameters, which together define a plane representing the working surface of a wedge relative to the probe

Thank you Paul! My comment was ambiguous...it was not about the (infinite) plane on which the transducer resides, but about the limits of the contact surface, i.e. the dimensions of the part of the wedge in contact with the specimen.

[paulwilcox1971]

Sorry - my mistake. I was wondering why I thought you couldn't do this before but that explains it. So an alternative that could be considered would be to allow WEDGE_SURFACE_POINT to specify multiple points that define the footprint of the wedge (as an alternative to specifying the surface normal). The points could be simply the corners of a polygon defining the footprint (although the spec would have to be clear on how this should be interpreted if >3 non-co-planar points are specified).