@Carl Love 

I verified. modpol working well with prime-power numbers. How I can to speed up this? Maybe with modp1, GF or domains?

@acer 

Thank you!

@acer 

Great! Thank you very much!

@ecterrab 

So you do not rollback changes in 686?

@ecterrab 

> ..hmm you meant `μ` and `~μ`

Yes. And maybe `μ` should also summing with ~mu and `~μ` with mu ... Maybe we need all combinations to be summing...

> So at this point that has no simple solution (and going all the way to implement that may end up introducing a level of complexity in the package that is not a good idea).

It's reasonable. If it can cause problems better not to do that.

Converting to 2D is great. Thank you.

@ecterrab 

It's amazing. Thank you. But that's not all.

Functions like TensorArray and SumOverRepeatedIndices should interpret ~mu and mu as repeated indexes and summing over them:

@ecterrab 

> That said, I wonder your intention ... what was it?

I ran into these issues when I calculate covariantized pseudotensor Landau-Lifshitz and Komar superpotential for Kerr-Newman metric. So I began to sort through the various options to understand the behavior of Physics's functions. It was like QA's routine.

> Regarding ~mu, I this is a longstanding issue with the GUI: it transforms `~mu` into `μ`

More precisely - `~mu` into `~μ`

>  I will adjust the code to understand `μ` and `μ~` as valid `mu` and `~mu` indices when you use Define.

It would be great. Thank you.

@ecterrab 

> The computations are performed correclyt if in the definitions you use all free indices covariant

Yes, I did definitions with different indices intentionally.

I have some suggestion about indices.

May be it possible to allow using greek indices like greek letters with tilda for contravariant indices (like for covariant)?

Not only like this:

But also like this:

The look of the document would become even more elegant and readable.

And please look at my another question:

https://www.mapleprimes.com/questions/229636-Maple-2020-Default-Font-Size

Do you know how to fix this?

Thank you.

@acer 

The exactly same bug in WIndows.

@ecterrab 

Thank you for clear and quick answer.

Yeah, if I put setting of coordinates before setting of metric issue from cov_diff_bug_2 just become into issue from cov_diff_bug_1.

I found another issue. Pleas look at attached file cov_diff_bug_3.mw. Now no any transformation. Just defining of covariant dervatives by straight formula and by converted into d_ formula (with Christoffel's symbols). And this lead to different results.

This issue from previous version of Physics too. I couldn't check it with update 685 because I couldn't instal it. Installing just freezed in the middle and I canceled it after 10-15 min.

Thank you.

cov_diff_bug_3.mw

@Preben Alsholm 

Thank you.

Why interface(warnlevel) doesn't affect on this warning?

@itsme 

Of course.

@itsme 

> What CPU do you have?... unless you really have an 8 core machine (not 4 core / 8 thread one), setting numnodes to a higher number might not be helpful.

I have two Intel Xeon E5504 2.00 GHz - 8 cores/threads in all. And 8 nodes - most efficient mode on my machine in other cases.

@itsme 

> both the threaded as well as grid calls that you have showed (but with colons at the ends) seem to complete on my machine, without crashing...

How many nodes did you use when grid call?

(I've tried with numnodes=4 - worked normally. But I need full options - 8 nodes and may be more.)

>  i have set the java heap that maple uses to 2048 MB in the startap maple script

How you did this? Edit launch.ini ?

> other than that, an SCR might be your best bet, as Alejandro points out.

Yeah, I've submitted.

@Alejandro Jakubi 

Ok.