constant_lags contains 0.0

[ISCOTTYI]

Not sure if this is intended (or breaks something somewhere else) but I noticed that if the constant_lags keyword in DDEProblem contains a lag of 0.0, the computation fails with

Warning: dt(0.0) <= dtmin(2.220446049250313e-16) at t=0.0. Aborting. There is either an error in your model specification or the true solution is unstable.

since dt is set to zero. This (I think) happens here: https://github.dev/SciML/DelayDiffEq.jl/blob/bdc2887f755812102533c699afdfadd356c7a155/src/solve.jl#L120

A case where this might be bad (and where I encountered the problem) is, when you have a problem including a sum (or integral) over different lags, e.g.

constant_lags = 0.0:0.1:10
dx[1] = - sum([h(t-tau) for tau in constant_lags])

[devmotion]

I'm not sure if you ever want to add a zero delay - that's not an actual delay so you should not use the history function for evaluation. Generally, the line you pointed out is not hit since algorithms by default are not constrained (i.e., isconstrained(alg) evaluates to false). There are some other parts of the code though where zero constant delays will cause problems.

In your example, I would suggest rather using something like

function f(du, u, h, p, t)
    constant_lags = p
    du[1] = - u[1] - sum(h(t - tau) for tau in constant_lags)
    nothing
end

constant_lags = 0.1:0.1:10
prob = DDEProblem(f, u0, h, constant_lags, tspan; constant_lags)
solve(prob, ...)

[ISCOTTYI]

Thanks for your reply. I guess I see your point... I thought it would be a nice consistency feature to have that but if it causes problems its probably not worth it.. In the future it might be worth adding a more descriptive warning message if a constant lag of zero is detected -- took me a bit of time to debug this.

[ChrisRackauckas]

Delays of zero are funky from a numerical sense. When you have state-dependent delays, the possibility of a lag hitting zero is crazy enough to be its own entire class of DDEs that have different convergence properties similar to DAEs due to getting an infinite number of discontinuities (unlike the finite number of 0th order discontinuities expected in a normal DDE). So 0 delays in a DDE solver is always something special. When you have constant lag, it's best to just error out in that case because it's not a real lag and this numerical pain really only wants to be handled at finitely many points. While one may thing that a zero lag is just an ODE, it's very different numerically unless it's very special cased, in which case, I'd recommend just using the ODE solver or not having that lag component.

In the future it might be worth adding a more descriptive warning message if a constant lag of zero is detected -- took me a bit of time to debug this.

Yeah I think it's fine to throw an error at construction that that is explicit about this.