By a process of elimination, I can reproduce the error which you are seeing with the "minimal" example

restart;
eqs:=[-2^(1/2)/_F4(t__3)^(1/2)*diff(_F4(t__3),t__3) = 0,
            2*2^(1/2)*_F4(t__3)^(1/2)*(diff(_F4(t__3),t__3)*t__2+diff(_F5(t__3),t__3)) = 0,
            4*_F4(t__3)^2+2*`A__4,2`(t__1, t__2, t__3) = 0
         ]:
vars := [`A__4,2`(t__1, t__2, t__3),
               _F4(t__3),
               _F5(t__3)
       ]:
dsolve(eqs, vars);

Just examining this example "carefully", the equation which "bothers" me is

            4*_F4(t__3)^2+2*`A__4,2`(t__1, t__2, t__3) = 0

Note that since _F4() depends only on t__3, then `A__4,2`() can never be dependent on t__1 or t__2. So (as a test), I modified the above "minimal" example to

restart;
eqs:=[-2^(1/2)/_F4(t__3)^(1/2)*diff(_F4(t__3),t__3) = 0,
            2*2^(1/2)*_F4(t__3)^(1/2)*(diff(_F4(t__3),t__3)*t__2+diff(_F5(t__3),t__3)) = 0,
            4*_F4(t__3)^2+2*`A__4,2`(t__3) = 0
         ]:
vars := [`A__4,2`(t__3),
               _F4(t__3),
               _F5(t__3)
           ]:
dsolve(eqs, vars);

and this now "works", producing the answer

[{_F4(t__3) = _C2}, {_F5(t__3) = -t__2*_F4(t__3)+_C1}, {`A__4,2`(t__3) = -2*_F4(t__3)^2}]

If I make the same minor change to your complete second example, then it too also "works".

A couple of caveats, which I can't explain

1. Should Maple be able to follow my thought process, and come up with somethiing like `A__4,2`(t__1, t__2, t__3) =_Fn(t__3) as part of the solution set? I really can't think why not!
2. Notice that in the minimal examples quote above, I have used dsolve() rather than pdsolve(). If I use the latter, then the same error returns, even in my "working" example above. Setting infolevel[pdsolve] := 3 doesn't help very much because the error occurs before the 'info' returns anything at all.

Could this be an Maple "bug", or maybe just a "limitation" - I honestly have no idea

post responses to my personal email. All communication should be done through this site.

I have just rechecked the code in my original post in Maple 2017.3 with Matlab R2017b and it executes perfectly. If you are running old versions of either of these packages then issues may occur. I'm going to assume that you are reasonably up-to-date, although if you provide version numbers, I can check this in the last three or four major releases of either of these applications

Otherwise from your email, when you state

1) This statement dose't work on windows

writeto("C:/Users/TomLeslie/Desktop/mattest.m");

This work!!

writeto("C://Users//TomLeslie//Desktop//mattest.m");

2) Run dose't work either

instead  for Matlab

matttest

then I can believe that neither of these commands (as quoted above) will work. You appear to have ignored the comment in my original post which stated (emphasis added)

Note that you will have to change the file paths in the above to something relevant for your machine

So when you state that

writeto("C://Users//TomLeslie//Desktop//mattest.m");

works - impossible, because the rlevant directory will not exist,  unless you have added me as a 'user' on your machine, which seems unlikely!

Similarly when you state that the simple

mattest

will work in matlab - unlikely, because matlab will have no idea where to look for this file, unless you have appropriately revised your matlab searchPath.

Accept that I do Maple->Matlab->Maple transfers on a regular basis. Consider as an illustrationmy responses to the thread

https://www.mapleprimes.com/questions/223790-A-Question-About-Using-Maple-Engine-On-Matlab

which shows (one of) the "advanced" ways of doing maple-matlab communication

" the F3(t) = 0 equation is unnecessary ", try

restart;
{sqrt(2)*sqrt(F1(t))*diff(F2(t),t) = 0};
dsolve(%, [F1(t), F2(t)]);

which gives both of the required solutions.

As a few general guidelines

1. Try to avoid including irrelevant equations as arguments to dsolve()
2. If at all possible try to have the same number of dependent variables as there are ODEs
3. Since you claim to have a "larger" calculation, for which you *think* this illustration constitutes a fundamental issue, consider posting the "larger" problem. That way, no-one here will waste time addressing irrelevancies

@Kitonum 

See highllght below for code correction

restart:
with(Physics[Vectors]):
Setup(mathematicalnotation = true):
r1:=t->2*t^2*_i+16*_j+(10*t-12)*_k;
r2:=t->(20-6*t)*_i+4*t^2*_j+2*t^2*_k;
v1:= unapply(diff(r1(t),t), t);
v2:= unapply(diff(r2(t),t), t);
arccos(v1(2).v2(2)/(Norm(v1(2))*Norm(v2(2))));  # Angle in radians
evalf(%*180/Pi);  # Angle in degrees

The command

indets(sys)

indicates that in your ode system 'sys', you have the undefined variables u[1], u[2], u[3].

These may(?) be typos for the defined variables mu[1], mu[2], mu[3]

Download hfProb.mw

Notice the 'jump' in digits between j=9 and j=10, and that for j>=10, evalf[j]() returns the same number of decimal places

@Kitonum 

I was about to make the same suggestion, except that since Maple's default Digits setting is 10, I thought that evalf[10]() would be the more "appropriate" choice.

Use of evalf[n] for n=1..9 in the OP's problem, but use of evalf[n] for 10<n<16 does nothing - the returned number of digits is unchanged, and I have no idea why!

so I will just add a few observations/stuffToContemplate on your latest post

There is something that is not explicitely stated (unless yoy pay a lot of atention to the help pages and read between the lines).
I have read more carefully these help pages and I agree with your reply.

Maple's help pages seem to prize brevity over clarity. Over a few years I have learned to read these both slowly and very, very, carefully. The required information is (usually) there, just not obvious!

By the way : Why did I asked a question about  Grid[Server] ?
Briefly :
I have to read 100 files containing each a 20000x50 matrix of floats.
Using readdata on a single proc does the gob in about 10 minutes.

If I was doing this, I'd probably be using the ImportMatrix() command, assuming that the input data is organised in some semi-sensible way: readdata() is going to give you a list (or maybe a listlist) which will require(?) conversion to a matrix. Probably better to actually read as a matrix with ImportMatrix()

If I use the 8 'nodes' ( 4 cores, 2 threads/core) on my machine the reading task is done in about 2 minutes. But I need to transfer the read matrices (Grid[Get]) to the main node 0, which takes somewhat more than 1 minute.

A couple of things.

Firstly I'm slightly surprised that parallelizing a 'read' process would speed things up!. I would have expected that the limitation on the process would be" storage access times". For example, assuming that all the data is on the same HDD, I'm surprised that parallel reads are faster than sequential reads, since I would expect that HDD access time would dominate. In fact, I would have expected sequential reads to be faster - less jumping around on the HDD.

Secondly, if parallel reads are faster, then I would recommend using the Threads package - AFAIK, in this parallel programming  method, there isn't really the concept of transferring data between nodes

Having these 100 matrix on the current node I can do some computations (typically drawing Boxplots and Histograms).
Unfortunately I receive a "connection to server lost" message, whereas the same job (reading task and drawings) run on a single processor works perfectly well (the issue is reproducible).

Hmmmm - interesting one. I actually doubt that this has anything to do with the use of parallel programming. Without parallel programming, Maple has a sort_of client/server structure where the client is the "window process" (maplew.exe) where you enter commands and view output. Data is transferred to and from this "window process" to the server process (mserver.exe) which is the Maple 'engine' actually performing all the computations, Connection between these two processes can be "lost" for a variety of reasons, none of whihc have anything to do with parallel programming. The fact that "a single process" works, suggests that this is some kind of memoryManagement/garbageCollection issue

I suspect that some background child processes still run after each processor have return control to the main processor (if you use Windows it's easy to verify, through the task monitor, that the jobs run on processors 1 to 7 are not killed when they are finished) 

Not an issue I have seen when using the Threads package - 'child' processes just disappear when they are finished. I note from the help pages that the StartServer() command starts a 'server' process as a 'child' of the Maple process. Do you explicitly stop this process by using a StopServer() command. If you do then you ought to be back to a simple (non-parallel) Maple process, albeit with a lot of data loaded. The fact that your 'child' processes are not terminated just seems wrong

I thought that using Grid[Server] could provide me a better control of the situation

and decided that my understanding of parallel computing with Maple was deficient.

It is possible to use the Grid() package on a single machine to distribute processes across multiple cores/threads. I've just tried, with the toy example on the Grid:-Launch() help page, ie

hello := proc()
                      uses Grid;
                      printf("I'm node %d of %d\n",MyNode(),NumNodes());
                      Barrier();
             end;
Grid:-Launch(hello,numnodes=8);

which returns

I'm node 1 of 8
I'm node 0 of 8
I'm node 3 of 8
I'm node 2 of 8
I'm node 4 of 8
I'm node 6 of 8
I'm node 5 of 8
I'm node 7 of 8

so it seems as if can use all  8 'nodes' ( 4 cores, 2 threads/core) on my machine.

So, some parts of the Grid() package will run on a local machine - and I will investigate whether this gives me any more functionality than the Threads:-Tasks() approach which is what I normally use for parallel programming.

However, your original problem was with the Grid[Server]StartServer() command. Relevant excerpts from the help pages would seem to be

Grid[Server]StartServer
start a hpc Server on a machine

Note the statement that this command starts an 'hpc' server. Now check the Grid[Setup] help, whiich is used to

designate the mode of operation for Grid computing

where the 'mode' of operation can be one of "mpi", "hpc", or "local". Note that the default mode is "local", which is why the toy example I mentioned above actually ran on my machine. However, further down the help page for Grid[Setup](), it states

"local" - This mode provides support for multi-process parallel computation on a single machine.  This is the default setup, and is available as part of a regular Maple installation.
"hpc" - This mode provides support for multi-process parallel computations distributed across a heterogeneous network.  Job scheduling and control is monitored by daemon processes running on each node in the grid. This mode can only be enabled if the Grid Computing Toolbox add-on has been installed.
"mpi" - This mode provides support for multi-process parallel computations on a cluster using standard Message Passing Interface (MPI) protocols.  Job scheduling is batch oriented and controlled by the operating system. This mode can only be enabled if the Grid Computing Toolbox has been installed.

It would therefore seem that the Grid[Server]StartServer() command will start an 'hpc' server - but you can only start such a server if the Grid Computing Toolbox has been installed

I forgot with(plots), or plots:-fieldplot.

I have corrected this in the following

fplot.mw

1. For parallel programming on a single machine, one uses the Threads() package. This capability is included within a basic Maple installation - ie definitely no paid-for add-ons required. I use this is on my 4-core/8-thread Windows machine, and it works as expected.
2. Since the Threads() package, gives the user parallel programming capability on a single machine,  I had always assumed that the "Grid" functionality was designed to run problems on multiple machines. Furthermore one could use the Threads() package 'within' the Grid() package in order to use multiple threads on multiple machines (gulp!).

My interpretation (above) is based on two factors

First of all from the Maple help for the Grid package, it states (my emphasis)

Functionality for running parallel processes on your local machine is included with Maple.  This lets you take advantage of your multi-core and multi-CPU architectures. With the addition of the Grid Computing Toolbox you can also deploy your algorithms to external machines on a network or cluster.

Secondly, in order to use the Grid Computing Toolbox, one therefore needs access to a server farm of some sort. In general, this would probably mean some kind of 'institution', rather than an individual (like me). It also makes (some) sense of the fact that the Grid Toolbox is a paid-for add-on: anyone with a server farm can probably afford the extra cash!

I wouldn't put too much faith in the fact that you can use 'other' commands within the Grid package. From MapleSoft's viewpoint the only one they need to block (and make you pay for) is the point at which you can distribute to multiple machines

restart:
h1:=z->1-(delta2/2)*(1 + cos(2*(Pi/L1)*(z - d1 - L1))):
h2:=z->1-(delta2/2)*(1 + cos(2*(Pi/L2)*(z - d2 - L2))):
h3:=z->1+(delta2/2):
assign(seq(K[i]=((4/h||i(z)^4)-(sin(alpha)/F)-h||i(z)^2+Nb*h||i(z)^4), i=1..3)):

lambda1:=Int(K[1],z=0..0.2):
lambda2:=Int(K[2],z=0.2..0.4):
lambda3:=Int(K[3],z=0.4..0.6):
lambda:=lambda1+lambda2+lambda3:
 
F:=[0.2, 0.25,0.3]:
L1:=0.2:
d1:=0.2:
d2:=0.2:
L2:=0.3:
alpha:=Pi/6:
plot( [seq(seq(eval(lambda, [Nb=j,F=i]), j in [0.1,0.2,0.3]), i in F)], delta2=0.02..0.1);

when

expand(5*(x^2-1)*(x^2-x-4)+1);
solve(a*x^4+b*x^3+c*x^2+d*x+e,x, explicit):
eval(%,[a=5, b=-5, c=-25, d=5, e=21]);

seems to work

try

restart;
f:=5*x^3-5*x+1;
solve(f);
evalc([%]);

that you can achieve pretty much the same thing by using a float as on of the coefficients in hte original polynomial definition - then you can happily use solve() rather than fsolve(), as in

f:=5*x^3-5*x+1.;
solve(f);