Allow for any smooth particle

[arturgower]

I think we should: use the T-matrix to allow for any (smooth) particle. For some details on the maths, see T-matrix.pdf, which also shows how to use a generic incident wave #10.

For the particle shall we just:

abstract Particle

type CircularParticle{T <: AbstractFloat} <: Particle
    x::Vector{T} #position of the centre
    r::T # radius
    c::Complex{T} # phase wave speed inside the particle
    ρ::T # the particles density
end

function tmatrix{T}(sim::FrequencySimulation{T}, p::CircularRectangle{T}, k::T, hankel_order::Int, exciting_hankel_order::Int=hankel_order)
    if hankel_order == exciting_hankel_order
        Zn{T}(sim, p, k, hankel_order)
   else 0
   end
end

Do you envisage any efficiency problems with this?

[jondea]

This would be an amazing feature, and thanks for the notes.

The Zn that creates the T-matrix is independent of the position of the particle, if this is the case for all T-matrices (which it looks like it is), we may want to make this structure obvious.

On a side not, we've missed a pretty obvious optimisation in the current code, given that the Zns are recalculated for each particle

It's also kinda odd that tmatrix() requires a simulation object, but this is how we've set up Zn(). Starting to regret some design choices...

We could also use a structure a little like this

type Particle{T,S} where T <: AbstractFloat, S <: Shape{T}
    x::Vector{T} #position of the centre
    shape::S
    c::Complex{T} # phase wave speed inside the particle
    ρ::T # the particles density
end

I think it would then be possible to implement the tmatrix function as

function tmatrix{T}(p::Particle{T,Circle{T}}, k::T, hankel_order::Int, exciting_hankel_order::Int=hankel_order)
    if hankel_order == exciting_hankel_order
        Zn{T}(p, k, hankel_order)
   else 0
   end
end

the dispatch would then be on the parametric type. Not sure what's best, will continue to think about it.

[arturgower]

The dispatch based on parametric type does look simpler! One issue is that the particle might not have a constant c and ρ. For a capsule there would be two different soundspeeds, densities and radiuses. How would all that info be carried is not in a Particle subtype? We need these bits of info to simulate internal waves. The only attribute that particles have in common is some central position x, and some outer radius of circle which completely surrounds the particle.

Yes it is a little odd that Zn takes a whole FrequencySimulation as an argument. It only requires the background soundspeed and density. Now is a good time to restructure if we want to...

The T-matrix is independent of particle position and of the incident wave.

[jondea]

One way to solve this would be for Particle to have a medium too, take a look at PhysicalProperties in physics.jl. Then a capsule would have a difference PhysicalProperty which has inner and outer properties and perhaps a ratio of radii?

The outer radius can be a method of the shape, rather than an attribute of the particle. Where is the outer radius used?

[arturgower]

That could work. The physical properties and shape (included outer and inner radius) are needed to generate the t-matrix, internal waves and place particles. Not sure I understand how the outer radius can be only a method of the shape, without storing it as a property as well. Could you perhaps give a code snippet =]?

[jondea]

outer_radius(shape::Circle) = shape.radius
outer_radius(shape::Square) = shape.width/sqrt(2)

outer_radius(p::Particle) = outer_radius(p.shape)

[jondea]

The machinery is currently in place, for each physics type and shape, you just need to implement the necessary t_matrix function. We just need a test case.