@Markiyan Hirnyk 

The result of

a := Array([1, 2, 3]):
b := Array([4, 5, 6]):
zip(`[]`, a, b);

is an Array of lists. That is, it is one-dimensional Array each element of which is a two-element list. So, yes, the zip command works in this case, but probably not in a way that a new user would find useful. To combine two one-dimensional Arrays into a two-dimensional Array, use angle brackets:

c:= <a,b>;

@jonlg 

Perhaps the reason that it is coded as exp(x) rather than e^x is so that the procedure can be written using Maple-level code. See

showstat(exp);

If you really prefer e^x, then you can do

e:= exp(1):

and then proceed to use e^x. AFAIK, the notation exp(x) is used in most computer languages.

@jonlg 

Lists and Arrays are different entities in Maple. You may be confusing the two. In the following code, A, B, and C are all lists (and C is a special type of list called a listlist).

A:= [1,2,3]:
B:= [4,5,6]:
C:= zip(`[]`, A, B);

First, master the use of lists, then we can discuss Arrays when your need for them arises.

@Kitonum 

The plots for this PDE system produced using the default option settings to pdsolve are completely erroneous. There are two ways that I can tell:

1. The plots for Th, Tw, and Tc are identical.

2. When you change the timestep or spacestep options, the plots are completely different.

The system might benefit from rescaling, for example, replacing Tw with TW= 1e6*Tw.

I can write you a routine that will separate the last term from all sums and Sums in an expression. Would that satisfy your need? Or do you need it to be specific to sums and Sums that end with an n+1 term? And, if so, do you need it to apply only when the final term is specifically with the variable n, or would you like it to apply to m+1, etc.?

@Carl Love 

As Kitonum's Answer shows, simply choosing among multiple solutions for the highest derivative is not enough. You have to do that AND verify that the initial conditions satisfy the original. Is that sufficient to guarantee the existence of a solution in some neighborhood of the initial point?

@Rouben Rostamian  

Do you pay any attention to the Answers already posted?

@Kitonum 

There's no need to be so specific. It's easy to write a one-liner that works for any n and any L.

shift:= (n::integer, L::list)-> `if`(L=[], [], (N-> [L[N+1..-1][], L[1..N][]])(modp(n,nops(L))));

If this is supposed to represent an actual mechanical process, then it difficult to understand what is controlling the complicated rotations of the cam; whereas with your 2d cam (previous post), it is easy to understand.

@Markiyan Hirnyk 

I don't know the internal workings of DirectSearch:-Search, but the points that you are being shown are all the points at which the objective function is being evaluated. The only reason that I displayed them was so that you could see that some progress was being made. If you stop seeing a new point every few minutes, then it might be a good guess that it is stuck in some infinite loop.

Uh oh.... I just noticed another potential problem. I suppose that you expect that the a, b, x_1, phi_1, etc. that you use as global variables in the setup code will be the same as the a, b, x_1, phi_1, etc. that you use as the parameters to dist. It doesn't work that way; the variables are not the same even though they have the same names. Anything in the setup code that gets used inside a subsequent procedure and which refers that procedure's parameters needs to itself be a procedure---preferably one created with unapply. I don't have the patience to implement this right now. Maybe tomorrow.

@Markiyan Hirnyk 

Your own timing of dist on a test point shows that trying a single point takes more than three minutes.

If you include a userinfo statement in dist (so that you will be informed of each point that is tried), and if you stop using that ridiculous 2d input (which prevents you from seeing the userinfo output until the whole execution group is finished), then you will see that it is actually computing numeric points; whereas if you do the same with your original constraint, then you will see that it is not computing any points at all. At over three minutes per point, this is going to take some time.

Here is an updated worksheet where I have implemented the new constraint, the userinfo, and converted the DirectSearch:-Search call to 1d input.

twocubes_corrected.mw

There are other efficiencies that could be implemented here and there. Most important I think would be making sure that dist is the last constraint checked. It is ridiculous that dist is being called on points for which a > 1. You could replace the objective function in dist with (t1-s1)^2 + (t2-s2)^2 + (t3-s3)^2 and avoid the square root.

@acer 

Preben has found a way with no call to solve or fsolve required. Apparently, boundary conditions can involve more than one derivative, which I wasn't aware of before. In this case, the additional boundary condition is

Note that in the case of a BVP you cannot simply introduce a new function equal to the second derivative because that would make the system a DAE and dsolve has no DAE-BVP solver.

How can we possibly diagnose your problem without seeing any code? Either cut-and-paste your code as plaintext directly into your post, or use the green uparrow on the toolbar (last thing in the second row) to upload a worksheet. Using pictures to post code is frowned upon here because then we need to retype your code.

@acer 

Thanks for confirming my suspicion about the unevaluated D.

I did not mention your other method (augmenting the ODE system before the call to dsolve) in this thread because I don't see how to make it work for a BVP. I understand how to do it for an IVP. If you can make it work for a BVP, please show me.

@nm 

hastype(eval(g,1), specfunc(anything,int));