@Kitonum I know how to solve this problem by hand - this is a simple example of something that is giving my problems in Maple's code, not something that I don't know how to calculate - I need to do some significantly harder problems.

@Axel Vogt As for the formal, physical reason, you'd have to ask my thesis director about that - I'm not sure myself. But he's told me time and time again that this is the case (especially because it was observed in experiment, no less!).

What do you mean splitting into two cases? If you referring to the different parameters - mK and mD for the two different plots - that's because the parameters represent two distinct physical systems.

@acer Oh - I misunderstood what Axel said. I'll have to try that as well.

As for Optimization - at the moment, I am using DirectSearch v.2 package. Is the built in Maple function faster/less memory intensive? I have been having memory problems (but that's another issue) so I am trying to be as conservative with memory as possible. However, because the problems are not necessarily convex (likely, but not always), I can't guarantee that it'll find the global minimum, which should occur at zero. Or is that not how it would work if I tried using Optimize on the constraints instead?

The range option on fsolve that I shoehorned in used to be necessary but now I use it only as a last resort - with the exception of a few rare cases (haven't run into any yet for this particular sheet) fsolve could not find the (physical) result without the range option. As for using an initial guess - that's a good idea! I'll have to try that. Or maybe I can just use a reasonable initial guess which could be automated - I expect the roots to lie near M0*2*m, so maybe I use M0*2*m + 0.01*i for the initial guess. Food for thought, anyway.

@one_man Thanks for the suggestion! While the solutions aren't particularly quick (for reasons unknown to me), it does find solutions, which is great. It uses a lot of memory too, so it's not the perfect solution. But it'll find me roots alright!

@Axel Vogt I'll try using more digits, but I've tried out to Digits:=100 and it didn't seem to solve the problem. I feel like it may not be a digits issue, unfortunately. But I'll try to do it manually to see if I can find a zero in that case. Thanks!

@Axel Vogt 

What I seem to find when I plot it is that there is a a value that is extraordinarily close to being zero but not actually zero. This leads me to believe that this a numerical issue and not a solution issue, if only because the equation I am using models a physical system which should have a pole. Further, it seems like a coincidence that only in this region does it not have a pole but instead has regions that are arbitrarily close to being a pole.

Does that make sense?

@acer You are correct - the problems have all been distinct. The only reason I am using the same name (or similar names) is because it's the big worksheet for my thesis. However, I've been editing them to include only the relevant portions each time.

My laptop's harddrive recently crashed, so I had to get a new version of Maple. That said, I had Maple 13, and now I have Maple 18.

@Carl Love I see. Which Re operators do you think aren't necessary? I think I've removed them except in the case where I evaluate the real part of the Heaviside, but the Heaviside isn't differentiable anyway, so that shouldn't cause it to lag out even more, I don't think. And I don't think you could be right about the integration considering it only seems to integrate 4 times when I plot it even though it clearly is evaluating the integral many, many times.

@sazroberson Yes, we can add that M and g are real and non-negative. However, one of the key aspects is that while Re(s) > 0, we are actually looking for complex solutions to the equation for M > 1. In fact, we expect s to be complex for any M > 1. Is taking the real part of an expression a long computation process, though? I would think it would be easy - it's essentially truncation. I thought the longest part of the calculation was the numerical integration, which is what I am worried about.

@Carl Love Righto! That makes my life a lot easier. Thanks for all of the help!

@Carl Love Ahah! It works! Thanks for the help.

In the event that I don't know exactly where the real root is but I know it's real, how can I specify that?

Also, is there a way to specify a complex range?

@Preben Alsholm My Maple (version 13) still gives the result quoted above (-6 -1.4i). Maybe you are getting that result because you're in Maple 18.02? I should be able to get that result somehow, though, on Maple 13.

@acer Thank you so much! That works perfectly.

However, is there a way to set what I want the right-hand side to be equal to? I.e. without changing the left side of the equation, is there any way I can make it so f(s) = 1.4 or something? Because the solution you gave always searches for roots, no?

@Carl Love Sorry! That was a different version. Will edit OP to upload a fixed version. The problem is still there, though.

Oh. I'm just so used to doing it the other way =p Well, good to know. Thanks!