@mmcdara I generally like your Heaviside workaround better than my FTOC (because I'm skeptical about applying it to a discontinuous integrand). However, you need to correct the undefined that appears in your final piecewise. You can do this by setting Heavside(0):= 0 (or 1) anywhere before the final conversion back to piecewise.

And why reinforce the OP's bad practice by not using unapply for your definition of G?​​​​​​

@tomleslie The bivariate piecewise result shown as your final result is surely not the intended result: t is clearly meant to be a bound variable in the integral (despite the bug in the original piecewise), thus it can't be a free variable in the result.

I haven't looked at your worksheet yet. I just have some observations and questions about the 3D plot that you show.

1. It appears to be constant with respect to x. Is that true, and, if so, would the plots that you want to produce always be like that?

2. I assume that the legend represents the vertical‐axis value. If so, why does the plot have a pink level (~0.2) that's lower than a nearby red level (~0.3)?

@adel-00 That expression determines the coefficients for a system of linear equations, and you're correct that those coefficients are real; but that expression doesn't specify the rhss of those equations. The rhs of ode1 contains the subexpression x^(2-alpha) (where alpha=0.2 is constant). When you evaluate this for x < 0 (which you do do to get the rhss of your linear equations), you get nonreal values.

@adel-00 The true solution of the ODE is in general complex for negative x. If you do the dsolve without initial or boundary conditions, you get

y(x) = 1259244087*x^(19/5))/14440000000 + 19*x^2/20 + _C1*ln(x) + _C2

@acer I totally agree with you that using a remember table doesn't help in this situation, and I had even expressed my skepticism about it in a Reply to Rouben. I will edit my Answer to reflect that.

My original enthusiasm for it was motivated by the fact that if a table were desired, the mechanism required to create it is totally non-obvious.

@lcz I'm not sure whether your first response in this thread indicates that your original Question requires no further Answer. Is that true?

@lcz No worries (a common colloquial expression that can mean "there's no need to be sorry")^[*1]_. I'm well aware that many (perhaps most) users here don't have English as their first language. I only point these things out when there has been (or there is likely to be) confusion. I am happy to provide any help that I can with English usage, Maple usage, general math, computer science, and other subjects.

And I wouldn't exactly call what I provided in this case a "correction" because even indefinitely seems inadequate for this particular situation. I was trying to describe why "temporarily" is certainly incorrect, as well as confusing.

[*1] "No worries" is perhaps better known and older from a colloquial Jamaican dialect. In that case, the meaning is somewhat different. The present usage comes from colloquial Australian.

@tomleslie The reason that we continue to discuss numeric methods for the solution of this problem is that producing plots that use varying parameters of an ODE system (whether or not those parameters can be included in dsolve's parameters option) is an important problem and a very common subject for Questions here on MaplePrimes. You've Answered many of those Questions yourself. Unless the system is linear (as is the case here), the likelihood of the analytic approach working is practically nil. So, while your approach is indeed quite timewise efficient, unless the system is linear, it's not likely worth the effort to make an analytic attempt for a practical problem (rather than a textbook problem).

@lcz Possible adverbs to use instead of temporarily are indefinitely, currently, presently, at the moment, or at this time. The adjective temporary or its adverb temporarily can only be applied to a period of time that is definitely known to be finite although its exact length is perhaps unknown. Considering the subtlety of this distinction, it was suprising to me how confusing "temporarily" was in your context. Of the five alternatives that I presented, indefinitely is the only one that emphasizes the distinction between "known to be finite" and "not known to be finite".

@Rouben Rostamian  I'm curious to measure the time savings, if any, that come from this. It does use a lot of memory, because procedures returned by dsolve are huge. At the moment, I don't have the patience to wait it out. Those savings may be strongly influenced by whether the plot uses t-major or delta-major order.

Nonetheless, this trick is important because it's the only way I know to save these procedures (to disk perhaps) for use in another session, regardless of any savings; likewise for any instantiation that doesn't directly change a procedure's code (via subs).

@Rouben Rostamian You must've read and/or downloaded my code in the few minutes between when I first posted it, then noticed the same problem that you did, then posted a correction. The correction is only to the last line in Ndelta, where I do a weird-looking back-and-forth conversion of the extracted procedure to "%m" (Maple internal code storage format) string form. The internal format is necessary to capture the instantiation of delta. Exactly the same thing happens with a save/read back-and-forth to a disk file: The file must be put in ".m" form to capture instantiations that are not local to the procedure being saved.

So, it's definitely not a dumb mistake. And thank you for presenting me an opportunity to explain this weirdness.

I haven't looked into the details of your Question yet, but I have a question about your first sentence: What do you mean by "temporarily" in the phrase "temporarily difficult to be generated"?

That Maple Math mode in MaplePrimes produces horrific results due to the font used being nearly unreadable (somewhat as if handwritten very small and with a shaky hand). I'm glad that people seem to have mostly stopped using it.

@mmcdara A few clarifications for various things that you said above:

1. There's nothing special about delta in Maple, so there's no need to make it local; but doing so doesn't hurt either.
2. I don't think that it's possible to use odeplot to produce a plot that varies a dsolve parameter.
3. See my Answer for a trick for doing the plot3d.
4. Since there are no derivatives with respect to delta, the system can be solved (and plotted) as an ODE system. Perhaps in some more-formal mathematical context one might consider it a PDE system.