Hi Viacheslav. Please, explain me with more details about what do you do. I have two questions:

1. Original equations are decupled? Sorry, I don't check that, I ask it because I assume you see this problem in depth and it's easy for you answer this.
2. Is your setup general for solve an ode with a large interval of integration? This is, I know that if the domain for an ode is too large, numerical methods can be implemented "by parts", with small portions of it, but actually never use that in the practice, or remember practical examples of it.

Best regards.
Alvaro.

No. I showed the same method, only written differently. For this example both algorithms do almost the same thing.


Yes, you can split a large interval into small portions. The solvers themselves do this. Usually inside the solver there is a loop in which a so-called step-function is called for each portion. This step-function can also split the portion into small parts depending on the complexity or accuracy of the method.

I didn’t point out correctly that it can be integrated separately. I meant that you can split the vector of derivatives D(t,x) into separate parts and integrate each element separately. Since the equations are dependent on each other, then this should be done as I showed.

I did this to make it easier to add elements to the vector of derivatives. Instead of one huge program block, you get many small expressions. This may not always be done, but if the derivatives are smooth over a given interval, then you can even use Euler's method.

I just took the inner for-loop of the solver out and limited the solution to two points (one step). That's all.

Hi. Thanks Viacheslav for your answer. In the attached, the usual setup for the system of two equations with two unknowns, showing that uni's solution it's the same than the given by Rkadapt. I also can setup a good solution for a 4x4 ode system, but the r's coeffs must to be recalculated before the concentration of O & CO. If not we get a nonsense solution, and guess that this issue is why it's hard to setup a system with more variables, as efus comment that is required. So probably he must to study in which order the updates must to be evaluated for the physical situation.

But what's more impressive to me, it's the Viacheslav intuition for the magistral setup that he do for solve the problem with a runge kutta method with ... one as the step!. Ok, he's the author of the solver plugin, maybe he know what it's talking about.

Modeling respiration-transpiration in a modified atmosphere packaging system containing blueberry 2 (uni).sm (24kb) downloaded 6 time(s).

Best regards.
Alvaro.

In any case, I have really to give a very big thank you to every one of you.

What I'm learning from all your post is really useful and interesting.

The ancestor of all these solvers is Euler [Fortran 1970], print stars instead of line.
Your two system DE's can you make them Euler style ?

ODE Euler Multitask.sm (130kb) downloaded 17 time(s).

Why don't you stick with the two DE's from the paper ?
In fact you just want to reproduce the paper, before getting lost in adventure.
If all those things/coefficients aren't identified, may as well don't have.
Presume some smart cat has done the project otherwise than Smath,
looking at your proposal will discredit both in red cross all over.
Why not first reproduce the paper 1/1, c/w the plotted solutions ?
From there, if solutions deviate from lab test ... what is the cause.
This is in fact the interest of the adventure, isn't ?

Jean, unfortunately, the model on paper has more than these two ODE, so even for the comparing of results would be needed to implement all the other pieces. The respiration and transpiration rate are both temperature-dependent.



In any case, the implementation of the system of two made by Viacheslav work really well and the results have a physical sense, so being more precise require do add more things.


Someone suggest me to try to use lsoda for this problem...I have to try.

You know "Audentes Fortuna iuvat"

Hi uni. I forgot this feature because I always thinks that it was the same as the matlab parameter placeholder, just to avoid to declare global variables for the local ones that usually appear in the m-script for define the function D. This could be more or less useless in SMath but here I think that you have an actual example of a mandatory use for this feature, because if not the RK procedure gives a bad solution if you don't pay attention to the order of the updates inside the D procedure, as first issue. I guess that there are more.



I bad implement this feature in my example, and you show how to implement it well. Just as comment, for no pass parameters as global values at all, this is a minor modification:





Thanks efus for this drawing describing the physical situation.

Best regards.
Alvaro

Edited by user 01 December 2020 19:44:36(UTC)  | Reason: Not specified

Ok, starting from an example from Viacheslav (Thx really a lot for all your work) I was able to use lsoda for the two and the result is quite good, so I will try to work another little on this road and we will see if I will be able also to add the others pieces.

Edit.

Ok, probably how the system is written isn't the most elegant thing to see, but the loss of weight due to respiration seems to be well represented (green line). The effect of the humidity isn't, at the moment, represented, but with a little bit of work I think it will do.
lsoda MAP.sm (44kb) downloaded 7 time(s).






Thx a lot Jean, now I give it a look, I'm quite sure that I can learn useful stuff from it!



Ah google come in my help for the pictures, but yes, it describes exactly what happened in the package.

Edited by user 01 December 2020 22:36:18(UTC)  | Reason: Not specified

The plugin is for sure interesting! I have intention in the future to face some problem related to respiration with a pure thermodynamic approach, so for sure it will be handy!

Regarding "things happens" I have to make some confrontation in the results, but for sure know this is extremely important! So thank you a lot!

Francesco.