This solution is outdated. To rescore this solution, sign in.
I noticed the same problem that Sebastian mentioned with the transfer function not being within the very tight numerical accuracy that the test suite requires. For this solution, I combined the ODEs to form one governing ODE, which also appears to provide the correct answer, but, alas, not to within the test suite's tight tolerance... Can this tolerance be loosened slightly to allow multiple solution methods?
Go to Matlab and write:
>> format long;
That is the conversion constant of rpm to rad/sec. Using |format long| gives you the answer within Matlab's working precision.
I tried that, but it didn't work. Leaving the constant as 60/(2*pi) is slightly more accurate than copying the result. By any means, I went back and solved the coupled ODE system, which did work. It's just frustrating that the solution bounds are so tight that no other method seems to work with the solver (this or the transfer function that Sebastian mentioned, which I also tried).
Have you tried to to the same for your "Gain2" port? A simple check yields: >> 20.02 - 0.1/(0.5*0.01) - 0.01^2/(0.5*0.01) >> ans = -4.2674e-16. Perhaps this is what throws you out of tolerance.
Another thing I can recommend is trying with a different circuit. Nonetheless, I do agree with you that the tolerances ought to be looser. You may suggest it to Guy and Seth: http://blogs.mathworks.com/seth/2015/08/07/modeling-and-simulation-challenge-in-cody/
Return the largest number that is adjacent to a zero
Prime factor digits
Get the area codes from a list of phone numbers
Back to basics 16 - byte order
Choose a web site to get translated content where available and see local events and offers. Based on your location, we recommend that you select: .
You can also select a web site from the following list:
Select the China site (in Chinese or English) for best site performance. Other MathWorks country sites are not optimized for visits from your location.
Contact your local office