The community will undergo maintenance on October 16th at 10:00 PM PDT and will be unavailable for up to one hour.
Hello, everyone!
I've noticed that there is a friendly and helpful community here, so maybe you can help me out with my issue.
I'm solving a differential equation with odesolve command, and everything works no problem.
Now I'm trying to add a periodic square wave function with variable duty cycle into the equation, and everything gets more complicated. I've used two similar methods to define the periodic function and they both work almost the same.
The trouble is - with bigger values of duty cycle it works flawlessly, but as soon as I try to lower it, it seems that odesolve misses some values and the solution looks obviously wrong. My first guess is that it is a numerical problem, as the equation also contains some relatively small and big numbers, changing some of which also helps a bit, but that's unfortunately not an option. Maybe there is an option to use some other method besides odesolve, or any other trick to fix this behaviour?
All other comments and graphs are in the attached file.
Any help is highly appriciated!
BR, Maxim.
Solved! Go to Solution.
See attached. The default solver was the problem! I changed it to Adaptive (right-click on the word Odesolve to see the options).
Alan
See attached. The default solver was the problem! I changed it to Adaptive (right-click on the word Odesolve to see the options).
Alan
Wow, that was easy!
Thank you so much! Wish I could be as proficient in Mathcad as you are.
I had no idea that changing solvers is such a simple, but kinda hidden process.
Thanks again.
Maxim
Guess I wouldn't have thought of that.
But here again a further disadvantage of Prime as we cannot influence the algorithm used in that program.
We had the very same question three weeks ago here http://communities.ptc.com/message/240188#240188 but because Prime was used, the best solution was to redefine the function to replace the verticals by steep slopes, getting rid of the discontinuities which make the adaptive algorithm fail.
Thanks for your input!
Making slopes is a way around, but as it turns out not best one possible (thankfully!).
Yeah, seems like another reason not to transfer to Prime. I've been hearing this kind of feedback on Mathcad Prime for a long time now, so I'm sticking to v.15 for calculations and MS Word for formalization. It has proven to be a reliable workflow many times.
Werner Exinger wrote:
Guess I wouldn't have thought of that.
But here again a further disadvantage of Prime as we cannot influence the algorithm used in that program.
We had the very same question three weeks ago here http://communities.ptc.com/message/240188#240188 but because Prime was used, the best solution was to redefine the function to replace the verticals by steep slopes, getting rid of the discontinuities which make the adaptive algorithm fail.
I went back to the earlier Buck converter problem and solved the original square wave input using RKadapt and it worked fine. I didn't even change the TOL (unless the original author had changed it). The help file says that odesolve is supposed to change the algorithm if it detects a problem, and RKadapt is included in the list that it can use. Apparently, the alorithm doesn't pick up the type of error experienced with the AdamsBDF routine.
In the end, Prime solved the original square wave problem without the curve modification, we just had to know how. It would be nice, though, if we could do the right click selection as in MC 15.
I went back to the earlier Buck converter problem and solved the original square wave input using RKadapt and it worked fine.
Ah, good to know it works at least that way.
In the end, Prime solved the original square wave problem without the curve modification, we just had to know how. It would be nice, though, if we could do the right click selection as in MC 15.
Fully agreed. We would need a rightclick context sensitive menu in a lot of situations like formatting in all its facettes, disable/enable region, assigning labels, ....