What do you want to do with that text file? Do you want to be able to read it a in text editor? Or do you simply want to save it to reload into another Maple session? Or do you want to load it in some other math software?

And, no, you're not allowed to trap assertlevel errors with try/catch or any other method. Any Maple library code that violates assertlevel=2 should be reported as a bug. Either the programmer put in the assertions to catch bugs, or their supervisor made them put it in for the same reason. There's no other purpose for the ::type assertions that are used with local declarations, which is exactly the ones caught by assertlevel=2.

@tomleslie Unfortunately, CodeTools:-Usage(..., iterations= ...) doesn't control for caching (aka memoization).

@acer The dimension of the result should be A^2*s (or, more formally stated, current^2*time). The dimension of an integral is always the dimension of the integrand times the dimension of the bound variable. 

By the way, the command randomize that appears in your worksheet does nothing. The correct command is.randomize().

I tracked down the error that occurred with 30 Digits. One of the integrations in the 12th iteration of the loop returned unevaluated because there were not a sufficient number of "guard digits" to achieve the requested accuracy (of 30 digits). The problem can be corrected by including the epsilon option in the Int command. I used epsilon= 1e-9 and it "worked" in the sense of producing a result. I do not know whether that result meets your accuracy needs. In practice, the value of epsilon used should be based on Digits rather than constant, something like epsilon= 10.^(3-Digits).

I can't address your issue with $include. However, you can't in general substitute read for $include, and the error that you get using read is totally expected. You see, read is a command of the Maple language, so the presence of read before a subsequent export is putting an executable command in the declarations section of the module, which isn't allowed. On the other hand, $include is not a command of the Maple language, so it should work. But, as I said, I can't address that further.

@zphaze I think that you're failing to see the significance of acer's 2nd example. He did a restart, so this example is not using any package at all. That's not quite what I'd call "switching packages".

@adel-00 I've made numerous Posts and Answers here over the years showing 3d plots of parameterized dsolve solutions where one or both of the.plot's independent variables are parameters of the ODE system. I prefer to use plot3d for this (as shown by mmcdara (vote up)) rather than surfdata because plot3d lets you view the parameter as a continuous variable and because using surfdata feels too much like mucking around in the low-level details of plot structure. 

@nm It is well known that some Maple results are session dependent. This particularly affects the order of results, but it may also affect the form. This can mean that solution pathways through algorithms may depend on random factors or factors out of the user's control. Are you sure that that is not what you're experiencing, with the warnlevel thing just being an unrelated coincidental factor?

@MapleMathMatt Your first method, using indices, is very inefficient compared to hasindex or assigned, the lookup time through a list being proportional to the list length (O(n)), and also the creation of the list is O(n). One of the most important things to know for efficient Maple programming is that table index lookup uses nearly constant time (O(1)) regardless of table size (and that constant is very small). It's unfortunate that documentation of this is buried in a terse and densely packed appendix of the Maple Programming Guide.

If you had a situation where index memberships checks occurred significantly more frequently than index additions or deletions, then it might be worthwhile to use the set of indices for the lookups. The ratio of checks to changes would need to be at least o(n) (little-o not big-O) for this to be worthwhile. 

What is `Y1"`? Is it a function that you've already defined?

My guess is that the difference is not in dsolve itself but in simplify (or something related to that). 

This Reply is only to point out an issue with your terminology. I don't at the moment have any solution advice (mostly because I'm on my phone, not Maple). 

Your problem is a boundary-value problem (BVP), not an initial-value problem (IVP). While that distinction may seem like a triviality, BVPs are often much more difficult to solve. 

Your last line of code contains a variable j which isn't used elsewhere. What is it? Is it the same as the imaginary unit I?