@mmcdara 

Sure. After the fact, it seems to make sense that Set() should be used only after Setup().

But one would think help will say that. Looking at the help page for Set() there is no mention at all of this.

It will also be nice if calling Set() before calling Setup() would issue a warning to the user to alert them. This would have saved me 2 days of work trying to find what is wrong and why I was not seeing output on the screen.

A simple warning message is all what was needed.

If I was the programmer who wrote Grid, that is what I would have done. I am sure inside the Grid package, it knows if Setup() was called or not before. A simple flag internal and private to the package would do the job.

#somewhere inside Grid package

....
local SETUP_WAS_CALLED::truefalse:=false: #this flag will be set to true by Setup()
.....
export Set:=proc(....)

      if  not SETUP_WAS_CALLED then
           print("WARNING: You are calling Set() before Setup().");
     fi;
....
end proc;

Update 1/29/2025

An important note for those who might read this later:  Set() works if no Setup() is called after it. i.e. using the default numnodes, which for my pc is

Grid:-NumNodes()

           24

Set() does not work if called before doing explicit Setup("local",numnodes=24).  So to be safe, do not call Setup() at all, unless you want for some reason to change numnodes from default value.

So in summary

# OK
Set(....)   


#BAD
Set(...)
Setup(....)   

#OK
Setup(....)   
Set(...)

Using Maple 2024.2 on windows. The above could change in future versions of Maple.

@mmcdara 

Thanks. You did not say why yours worked and mine did not.

I guess you wanted one to find out, right?. But I did :)

The trick is to write

Grid:-Setup("local",numnodes=3);
Grid:-Set(foo):

Instead of what I was doing, which is

Grid:-Set(foo):
Grid:-Setup("local",numnodes=3);

When writing Grid:-Set(foo): after Grid:-Setup("local",numnodes=3); files are created OK now.

Did you find this by trial and error? Or was it by accident? Is this documented anywhere? Or do you think this is a bug I should report it?

Why does the order makes difference?

Btw, I tried your trick on the print() issue I have not showing,

Why-Calling-Proc-Via-Grid-Do-Not-Print-On-Screen

and this also fixed it !

So you hit two birds with one stone. All what is needed is doing Grid:-Set() after Grid:-Setup("local",numnodes=...); May be you can add this as answer to the print() question I have, saying to change the order of Set and Setup and I will be happy to accept it.

I'll add this to my cheat sheet. 

@mmcdara 

I also could not make printer option work with numnodes set.

It works if there is no numnodes option. But once this option is there, it no longer works.

An example in help page would be nice to show how this option can be used. But Maple help is horrible to say the least. Sorry, but it is true.

Very little examples to illustrate things for users.

And what does "line of output available" actually mean in the following? Available how? Available to whom? 

The printer procedure will be called with a string every time there is a line of output available from an external computation.

Instead of saying things in mystery like the above, why not just show an example??

Here is my attempt.
 

Download grid_question_jan_27_2025_V3.mw

This below is same thing as above but without numnodes option. Now it works and printer proc is called indeed. This shows that printer proc only works if numnodes is not used.

But printer proc is not really needed if one is not using numnodes, as print() from node shows on the screen on its own and no need to use print proc in first place.

So now I am having hard time debugging my Grid code, since when I print something it does not show on the screen. But I need to use numnodes option, as I found there are problems that go away when I use this option. So I have now to find a way to print debug messages. May be send them to file and look at them later.  

I do not think numnodes is supported well in Grid package.

Download grid_question_jan_27_2025_V4.mw

@C_R 

I have not tried that. I do not even know now what options and settings I need to change to tell Maple to run/use only one core.

my PC has intel CPU with 16 cores and 24 logical processors. 

I just run Maple/start using whatever defaults it uses on windows 10.

@aroche 

Thanks for the fix. Great job.

But could you please explain to us in terms we could understand, why it was happing at random? This is the part which I do not understand.  

Should not Maple, after a restart behave the same way each time given same input?  You said

             There was a recursion error in `trig/normal` which has now been fixed:

Does Maple uses random number generator somewhere inside trig normal that was causing different behaviour even though the commands were all issued after restart?

I will do more tests, but initial tests shows this bug is fixed. But I need to run it on my main script which takes days to finish to make sure. 

Thanks again for the fix.

@manasp 

opps, thanks,. I did not read help carefully. It is 

           Grid:-Run(node,command,[args])

and not like I did

           Grid:-Run(node,command(args))

Btw, you have to give a node number, If you do not, like you showed, it will run the command on all nodes. I have 26 logical cores, so it solved it 26 times, in parallel.

So this is what I changed it to and now it worked

restart;

P:=[diff(x(t),t)=t*x(t)-y(t)+exp(t)*z(t),diff(y(t),t)=2*x(t)+t^2*y(t)-z(t),diff(z(t),t)=exp(-t)*x(t)+3*t*y(t)+t^3*z(t)]:

Grid:-Run(0,dsolve,[P],'assignto'='ans1'); #result of dsolve in ans1
Grid:-Wait();
ans1

And now it gives same answer as not using Grid.

@dharr 

Thanks, I was using link that google search gave and I did not know I landed on a "review" page of the application and that there was a "main" page also with more download links. 

if you have access to google AI, you can type this. It even gives code

ps. I assume code works. I did not try it.

@C_R 

fyi, I found another example of this random behaviour. I also tried your forget(all) before each call to odetest, but it had no effect.

Also this time the error is not related to sincos, but new one related to  too many levels of recursion.  But the common thing, is that it is also random.

In Maple 2024.2 on windows, it returns unevaluated. So there is no bug. Returning unevaluated is not a bug.

May be you are using older version of Maple and this was fixed?

Download no_bug_jan_14_2025.mw

@dharr 

thanks for confirming. I am sorry you had to reboot your pc. hope you did not lose any work. For me, CTRL-ALT-DEL then using task manager I was able to kill the whole Maple program. But I am using windows 10 pro. Not windows 11, may be this makes difference.

@Christian Wolinski 

The output solution was generated by a program.

But I am confused by your answer. You have given a workaround. Sure. A nice workaround also. But it is a workaround and does not explain what is going on.

Or are you saying or implying that because the user did not simplify the input as well as they could have, then Maple now is allowed to give different responses for same input or behave differently for same input?

How could this be possible?

@C_R 

Needs to be reported, IMO

The problem is that it is random. sometimes it happens and sometimes not. I've send bug reports before where I get reply they can't reproduce it, because tech support tries once and if they can't reproduce it, they will not enter it.

Here is worksheet, where I started Maple fresh, and had to do many trials to get this internal error to come up.

It seems Maple uses some random number generator to do something internally.  I can't explain this. Maple is the only CAS software I know where I can get different results running the same exact code.

Download why_odetest_sometimes_fail_internal_V2.mw

But I will send this report now to Maple tech support. Even though I am sure I will get reply that they can't reproduce it.

@acer 

Yes, this works! when I did convert(ode,D) I saw the output has (y)(x) and my eyes saw it as y(x) so I did not bother using has(..,y(x)) on it as I thought it will also return true. I should have tried it.    

Now I can get rid of the loop as not needed.

Thanks

@gkokovidis 

Thanks. I tried it, but it does not do what I want. Examples below. It seems dirfield=n means n arrows, and not n lines.

I want to change the number of field lines as in examples I showed using the other system. Not number or arrows.

So I am not able to get same effect as the other systems. Below are examples changing dirfield.

Download change_number_of_arrows_dirfield_jan_4_2025.mw