DBS protocol

[gabrevaya]

Allows setting up DBS protocols similar to those empirically used in clinical studies to obtain ERNAs.

[gabrevaya]

(I cancelled the last checks because I had only added some docstrings)

[harisorgn]

These parameters are set as tunable=true in paramscoping, was this intended for the current case? E.g. do you expect to fit such parameters in an inverse problem setting?

• If no, then I'd say just define your parameters explicitly here with tunable=false to avoid having them included in optimization/fitting problems.
• If yes, then maybe consider moving the paramscoping call at the beginning of the function, in case any of these parameters are Nums instead of numbers, so that the correctly scoped parameters will be used in your stimulus function. In a tunable=true setting it could be the case that multiple sources share the same parameters, so the input types could be the same Nums among multiple DBS sources. In this case you would need to overwrite the input parameters with the return of paramscoping e.g. like here
  

  Neuroblox.jl/src/blox/neural_mass.jl

  Lines 202 to 203 in 02fd048

  	p = paramscoping(τ=τ, H=H, λ=λ, r=r)
  	τ, H, λ, r = p

[gabrevaya]

Thanks for noticing this! I'm not expecting to fit these parameters, at least for now. Maybe in the future we could fit them, but we can change it to tunable=false for now and modify it in the future if needed.

[harisorgn]

Ye I wasn't expecting to fit source parameters either to be honest. Usually these are known.

[gabrevaya]

For setting parameters as non-tunable, which option would you suggest?

1. Use paramscoping and then untune all parameters with untune!
2. Manually set each parameter as @parameters $p = p [tunable=false]
3. Add a tunable flag to paramscoping:

function paramscoping(;tunable=true, kwargs...)
    paramlist = []
    for (kw, v) in kwargs
        if v isa Num
            paramlist = vcat(paramlist, ParentScope(v))
        else
            paramlist = vcat(paramlist, @parameters $kw = v [tunable=tunable])
        end
    end
    return paramlist
end

I would go with option 3).

[harisorgn]

Sure, go for it.

[harisorgn]

Besides the one comment above, could you add some tests for the new source & protocol?

[gabrevaya]

On a different topic, regarding conventions, currently, I call DBS the constructor of the simple stimulus and protocol_dbs the constructor of the protocol. However, I guess it should be more appropriate to use Protocol_DBS or ProtocolDBS, right?

Also, since Neuroblox's unit of time is ms, I'm using frequency here in units of 1/ms = kHz. However, I wonder if we should accept Hz as input and handle the conversion internally. This could be more user-friendly since users will be more likely to think in Hz, especially in the case of DBS, where frequencies are $\sim$ 130 Hz.

[harisorgn]

However, I guess it should be more appropriate to use Protocol_DBS or ProtocolDBS, right?

No strong feelings about it. Technically it is a constructor dispatch but I guess you use a different name (other than DBS) to keep the arguments as keyword for user-friendliness. I'd say ProtocolDBS between the two.

However, I wonder if we should accept Hz as input and handle the conversion internally.

Sure as long as you document that in the docstring. We should start using a units package soon.