Wrote

Wrote

But from the top of my head - the X-axis should represent time in minutes, not temperature.

Also, it took quite some time for the sheet to finish calculating.

Best regards,
Hans Kristian

1. You can leave it in native 't'
2. the default Integration accuracy is 100, set it 50
it will have no influence in this application but much faster.
1.7 min in my 1.66 GHz laptop runs 225 greedy maths.
3. Does your version bracket t:=[0,5..600] ?
rather than Smath 6179 t:=0,5..600

Temperaturforlop Compactum Copy.sm (53 KiB) downloaded 43 time(s).

For solution 1/part 1 of the DE the domain is from t=0 min to t=x min, and f(t=0)=20 degC to f(t=x)=600 degC

t=x such that f(x)=600 is the IC for solution 2/part 2. Similarly for solution 3 t=x such that f(x)=735 is the IC.

When I open your sheet t:= is in brackets, yes. Did I understand you correct?

Best regards,
Hans Kristian

Wrote

When I open your sheet t:= is in brackets, yes. Did I understand you correct ?

Thanks for confirming [ ... ] bracket conversion from 6179 => 6671.
Some external use were demonstrated for local use.
Within a "forLoop", can't see the use for ... crowds the code.
I asked for a demo that 6179 couldn't do ... still waiting !
=============================
Numerical maths work unitless on dummy scalar iterator.
You can post identify that the running Cartesian 'X' is '°C'
That's what I understand from your first comment.
============================
I visited several sources of that standard *.PDF
Zillions pages empty except for what is text.
Can't see the use of a web document all empty !
Maybe you can confirm the final graph solution.

Jean

Temperaturforlop Compactum Copy.sm (52 KiB) downloaded 53 time(s).

After recently learing how to write for loops, this forgotten project popped back up in my mind again..

My newfound knowledge got me quite a bit further, to the point where i think this project is complete as well.

Just one question - is it possible to define a function quickswitchODEsolver(a,b,c,d,e)=ODEsolver(a,b,c,d,e) <-- This could be Rkadapt() for example, or maybe another solver.

Can the 8 different resolutions then be solved by quickswitchODEsolver()?

The goal is to have to change the solver function only one place rathere than 8, if I want to switch.

Cheers.

Temperaturforlop.sm (119 KiB) downloaded 37 time(s).

Try this https://en.smath.com/forum/yaf_postsm51257_DotNumerics.aspx#post51257

Wrote

Try this https://en.smath.com/forum/yaf_postsm51257_DotNumerics.aspx#post51257

Thanks.

I have tried to apply that approach to selectiong solvers, but my results does not come out correct..

Also, I have tried manipulating ZedGraph setting with the setprop(), but I cant get it to work with existing plots.. only new plots.. any ideas?

Best regards,

Temperaturforlop_test.sm (190 KiB) downloaded 34 time(s).

Wrote

Also, I have tried manipulating ZedGraph setting with the setprop(), but I cant get it to work with existing plots.. only new plots.. any ideas?

setprop() is experimental and I will add differ method to control region properties (using math variables as values for them). Yes, now it works only for new plots with 'zGraph' name. But you can't save this value with the document. This is because region has binary content in xml file and for now I can't change it by adding new properties.
I am not the author of the component, so it is difficult for me to modify it.

As for the solver I hope someone can suggest a solution.

Wrote

Wrote

Also, I have tried manipulating ZedGraph setting with the setprop(), but I cant get it to work with existing plots.. only new plots.. any ideas?

setprop() is experimental and I will add differ method to control region properties (using math variables as values for them). Yes, now it works only for new plots with 'zGraph' name. But you can't save this value with the document. This is because region has binary content in xml file and for now I can't change it by adding new properties.
I am not the author of the component, so it is difficult for me to modify it.

As for the solver I hope someone can suggest a solution.

Thanks for clarifying. Looking forward to this feature in the future.

Few comments:
1. As soon as you can plot something, plot ... this is a must.
2. RK solvers are known to over-shoot [Mathematica, Mathcad/Mathsoft ]
3. The Simpson "Premise" is all correct in there.
4. Use solve(,,,,) instead of your other junction.
5. Red top to bottom in SS 6179

Temperaturforlop_test [1].sm (34 KiB) downloaded 30 time(s).

Wrote

After recently learing how to write for loops, this forgotten project popped back up in my mind again..

My newfound knowledge got me quite a bit further, to the point where i think this project is complete as well.

Just one question - is it possible to define a function quickswitchODEsolver(a,b,c,d,e)=ODEsolver(a,b,c,d,e) <-- This could be Rkadapt() for example, or maybe another solver.

Can the 8 different resolutions then be solved by quickswitchODEsolver()?

The goal is to have to change the solver function only one place rathere than 8, if I want to switch.

Cheers.

Temperaturforlop.sm (119 KiB) downloaded 37 time(s).

There might be smoother ways but this works. Note that I had to replace the sliders because the old regions don't seem to work any more with new SMath versions.


Section Math ODE precision.sm (23 KiB) downloaded 35 time(s).

Wrote

There might be smoother ways but this works. Note that I had to replace the sliders because the old regions don't seem to work any more with new SMath versions.

Thanks. I already had a go at this approach as uni directed me towards it.

It works fine when I apply it to ODE itself, but when I wrap the ODE into a for loop (a necessity to establish boundary conditions for the whole set of ODEs) something goes wrong..

Cheers

Wrote

Few comments:
1. As soon as you can plot something, plot ... this is a must.
2. RK solvers are known to over-shoot [Mathematica, Mathcad/Mathsoft ]
3. The Simpson "Premise" is all correct in there.
4. Use solve(,,,,) instead of your other junction.
5. Red top to bottom in SS 6179

Thanks for putting me on a different track.

Solve() also serves the purpose of finding the boundary conditions for DE2-4, although I guess the way I have set it up (might be other ways) does make the ODEs compute a lot of unecessary results (they all go all the way up to t.final, but they only have to go up to t.lim - hence the for loop).

This way the mkraska method of switching solvers work, and it is quite interessting to see the discrepancy in computational times. dn_AdamsMoulton takes way longer to compute, and actually runs into trouble when the tolerances are high..

Any ideas on a setup that stops the DE's when they reach t.lim rather than t.final while still being able to choose the solver?

Cheers.

Temperaturforlop_test_2.sm (92 KiB) downloaded 30 time(s).

Another question regarding stiffness and solvers.

What does it say about the stiffness of a ODE if both a stiff solver and a nonstiff solver is able to solve?

And for this particular set of ODEs, I have seen several articles discussing how to solve using the MS ExCeL method using a set timestep of dt=5s. If that is a proven method to solve this problem, that would confirm the system is nonstiff, right?

Wrote

but when I wrap the ODE into a for loop (a necessity to establish boundary conditions for the whole set of ODEs) something goes wrong..

1. The for loop not needed
2. something goes wrong argument must be scalar
't' is not a free running scalar in your for loop.

Wrote

There might be smoother ways but this works. Note that I had to replace the sliders because the old regions don't seem to work any more with new SMath versions.

Thanks Martin for that superb ClassRoom demo ! Works well SS 6179.

Wrote

Another question regarding stiffness and solvers.

What does it say about the stiffness of a ODE if both a stiff solver and a nonstiff solver is able to solve?

And for this particular set of ODEs, I have seen several articles discussing how to solve using the MS ExCeL method using a set timestep of dt=5s. If that is a proven method to solve this problem, that would confirm the system is nonstiff, right?

You can exercise all 17 Smath native ODE solvers.
From the look, your first D1 is not stiff.
Assume the Premise Algo is some kind of yard stick, exercise the 17 ODE solvers.
After all, all those represent experimental data, not exact anyway.

Integrate ClassRoom Premise_Maple.sm (57 KiB) downloaded 27 time(s).

... visit Fehlberg .
The code sources agree: Mathematica & Mathcad 11 Smath as well .

ODE Fehlberg Integrator-Interpolate.sm (77 KiB) downloaded 29 time(s).

Wrote

You can exercise all 17 Smath native ODE solvers.
From the look, your first D1 is not stiff.
Assume the Premise Algo is some kind of yard stick, exercise the 17 ODE solvers.
After all, all those represent experimental data, not exact anyway.

Jean, I'm not sure I get your reference to the "Premise Algo"...

Wrote

Jean, I'm not sure I get your reference to the "Premise Algo"...

Ignore as it was given. I couldn't find the trick to scale appropriately.
Some interesting visit attached... Jean

ODE Valery Reaction.sm (18 KiB) downloaded 29 time(s).
Integrate ClassRoom Fehlberg.sm (52 KiB) downloaded 23 time(s).
ODE HIRES.sm (67 KiB) downloaded 23 time(s).

... refused to upload this one

Integrate ClassRoom Premise Algo [kernel(f,a,b,n)].sm (45 KiB) downloaded 32 time(s).

Turns out the ODE solvers cant handle if() in the D argument, which led me down the path of creating a system of ODEs.

I just found out the ODE solvers can deal with cases(), which means there is no reason to separate the ODEs in the first place.

No need for for loop or solve function to find where one ODE ends and another start anymore....