I have a complicated set of first-order differential equations, which Maple seems capable of solving. So far so good. The obtained solution is fed into another complicated set of first-order differential equations, which, again, Maple seems capable of solving.

But this final (combined) solution cannot possibly be the complete one as it does not contain a specific (sub)solution which DOES satisfy both sets of equations (checked in Maple by evaluating these equations for that specific solution). And there is no warning raised concerning any solutions that may have been lost.

The problem seems to be that the integrational constants associated with solving (in turn) the two sets of equations become messed up together, or erroneously 'reused', in some mysterious way. For if I rename the integration constants of the first solution before feeding it into the second set of equations, then this specific subsolution IS contained in the final solution.

Therefore the following questions:

1.) Could there possibly be some erroneous 'reuse' of integration constants going on? It seems to me that in solving the second set of equations, PDEtools:-Solve would have to make sure that it numbers any new integration constants in such a way that there would be no conflict with the ones obtained in solving the first set of equations.

2.) Is there some (global) variable that determines what letter is assigned for the integration constants? I could use any such to easily switch names between the first and second solving.

PS: I think, it makes little sense to upload any code/worksheet here.

When I resave a worksheet that is already saved on the computer desktop, it changes the position of the icon on the desktop: it is moved to the most left-upper column-row possible. Why that? Can anyone else reproduce that odd behaviour?

A worksheet can be closed using the Windows standard shortcut Ctrl-F4. But the Maple program itself cannot be closed using the Windows standard standard shortcut Alt-F4. Why that? Can anyone else reproduce that odd behaviour?

PS: I am using Maple 2017.1

This might be considered nit-picking, but nonetheless I think there is an issue: The metric tensor and its inverse are types (0,2) and (2,0) tensors, respectively. When once contracted with each other, the result is the Kronecker delta, which is then (necessarily) a tensor of type (1,1). I am therefore surprised to find that in Maple, this Kronecker delta is implemented as a type (0,2) tensor, via the command KroneckerDelta:

KroneckerDelta[mu,nu];

I don't think this makes any proper sense. I think that such an object of type (0,2) is, in fact, the metric itself. On a similar note, the (mixed tensor type) objects g_[mu,~nu] and g_[~mu,nu] are actually both Kronecker deltas, because they correspond to the metric having one index raised by contraction with the inverse metric itself. But, nonetheless, the following is the case:

g_[ mu,~nu],
g_[~mu, nu];

Relatedly, consider the following single contraction of the metric with its own inverse:

SumOverRepeatedIndices(g_[mu,nu]*g_[~nu,~sigma]);

Although this sum is formally quite correct, I think it should be given as just a Kronecker delta (of the correct mixed tensor type, that is).

Perhaps I am being stupid, but I have a problem with functional operators, more specifically with looping through a collection of them. Consider the following code (just a study case):

nonIdMaps := []:
for f in [x -> x,x -> 2*x,x -> 3*x] do
   f,f(y);
   if f(y) <> y then nonIdMaps := [nonIdMaps[],f] end if
end do;
nonIdMaps,map(f -> f(y),nonIdMaps);

There are two things I do not understand about this output: 1.) Why the f's rather than the specific maps as given in the list? 2.) Why two times 3*y in the last line, rather than [2*y,3*y]? (this issue being of course quite likely a consequence of the first one). This behaviour can be compared with the following:

nonIdMaps := select(f -> f(y) <> y,[x -> x,x -> 2*x,x -> 3*x]):
nonIdMaps,map(f -> f(y),nonIdMaps);

the output of which I do understand, being as I expected it to be. I guess that there are some scoping rules I do not understand, or what?

Using Tools -> Check for Updates, I have just tried to update my Maple installation from 2017.0 to 2017.1. The download itself went without a hitch, but then nothing happened. In view of the fact that I clicked a button titled 'Download and Install', I would certainly expect the installation to have started automatically after download. Are anyone else experiencing the same odd behaviour?

PS: Related question of mine is Automatic update of help pages?