ecterrab

14540 Reputation

24 Badges

20 years, 22 days

MaplePrimes Activity


These are replies submitted by ecterrab

@Sofi 

The Maplesoft Physics Updates with code for solving the PDE & BC you posted only works for Maple 2018. Regarding the math (your other question), give a look at  this other Mapleprimes post where it is all explained.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@Mariusz Iwaniuk 

Note that the solution you posted, using new routines described in this other Mapleprimes post, actually shows two equations for lambda[n], one of which is sort of redundant (due to an intermediate call to simplify that split the single equation into two). This is adjusted in version 200 or higher of the Maplesoft Physics Updates, so that now the output has one single equation defining lambda[n].

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@Rouben Rostamian

 

Just trying your worksheet today (version 195 of the Updates). I see that the other two issues you mentioned are also resolved.

pde := diff(u(x, y), x, x)+diff(u(x, y), y, y) = 0

bc1 := u(0, y) = 0, u(Pi, y) = 0, u(x, 0) = 0, u(x, Pi) = 0

 

Check the method that resolves the problem

infolevel[pdsolve] := 2

2

(1)

pdsolve({bc1, pde})

* trying method "_Fn" for 2nd order PDEs
   -> trying "linear_in_xt"
   -> trying "BC_equal_0"
* trying method "_Cn_cn" for 2nd order PDEs
   -> trying _Cn_cn
* trying method "Wave" for 2nd order PDEs
   -> trying "Cauchy"
   -> trying "SemiInfiniteDomain"
   -> trying "WithSourceTerm"
* trying method "Heat" for 2nd order PDEs
   -> trying "SemiInfiniteDomain"
   -> trying "WithSourceTerm"
* trying method "Series" for 2nd order PDEs
   -> trying "ThreeBCsincos"
   -> trying "FourBC"

   -> trying "ThreeBC"
   -> trying "ThreeBCPeriodic"
   -> trying "WithSourceTerm"
   -> trying "ThreeVars"
* trying method "Laplace" for 2nd order PDEs
   -> trying a Laplace transformation
* trying method "Fourier" for 2nd order PDEs
   -> trying a fourier transformation

   <- fourier transformation successful
<- method "Fourier" for 2nd order PDEs successful

 

u(x, y) = 0

(2)

By the way note (not documente yet) that since some versions of the Updates you can specify the method

pdsolve({bc1, pde}, method = Fourier)

* trying method "Fourier" for 2nd order PDEs
   -> trying a fourier transformation
   <- fourier transformation successful
<- method "Fourier" for 2nd order PDEs successful

 

u(x, y) = 0

(3)

On the methods:

indices(`pdsolve/BC/methods`)

[1], [2], [2, "Series"], [3], ["high_order"], [2, "_Fn"], [2, "Wave"], ["system"], [2, "Heat"]

(4)

These typically have submethods that in turn may more of that. For example

`pdsolve/BC/methods`[2]

["_Fn", "_Cn_cn", "Wave", "Heat", "Series", "Laplace", "Fourier", "Generic", "PolynomialSolutions", "Linear_diff_op"]

(5)

If the optional argument (method or methods) is a list, then only those methods and in the order you specify will be tried.

 

Some of the names you see today in these lists of methods will change to something more understandable.

 

The other problem you mentioned

bc2 := u(0, y) = 0, u(Pi, y) = sinh(Pi)*cos(y), u(x, 0) = 0, u(x, Pi) = 0

pdsolve({bc2, pde})

* trying method "_Fn" for 2nd order PDEs
   -> trying "linear_in_xt"
   -> trying "BC_equal_0"
* trying method "_Cn_cn" for 2nd order PDEs
* trying method "Wave" for 2nd order PDEs
   -> trying "Cauchy"
   -> trying "SemiInfiniteDomain"
   -> trying "WithSourceTerm"
* trying method "Heat" for 2nd order PDEs
   -> trying "SemiInfiniteDomain"
   -> trying "WithSourceTerm"
* trying method "Series" for 2nd order PDEs
   -> trying "ThreeBCsincos"
   -> trying "FourBC"

   <- trying "FourBC" successful
<- method "Series" for 2nd order PDEs successful

 

u(x, y) = Sum(2*sin(n*y)*exp(Pi*n)*n*sinh(Pi)*((-1)^n+1)*(exp(n*x)-exp(-n*x))/(Pi*(exp(2*Pi*n)-1)*(n^2-1)), n = 2 .. infinity)

(6)

The sum starts at n = 2.

NULL


Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Download The_other_two_issues.mw

 

 

@Mariusz Iwaniuk 

Thanks, version 194 includes also a fix to factor, but the advanced version of that fix got by accident into the code for 2018.2. It is corrected now in version 195 of the Maplesoft Physics Updates.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@Rouben Rostamian  

First of all, nice reply yours. It is exciting when the level of the discussion goes higher and at the same time stays respectful of other's (sometimes different) opinions.

On the contents: you are right in the distinction about classical and weak solutions; mainly: the solution could be discontinuous at the boundary conditions (e.g. in the example posted). So yes, I goofed here, prematurely discarding the problem because of the inconsistency of the boundary conditions posted.

On the other issues that resulted from this post: Maple's pdsolve does compute weak solutions, examples of that were posted, but the one of this post is not solved when it could - for instance, you show how - and the method (skipping details) is systematic. To cover this example and a family of related cases more work is necessary. We are working on that in this moment, among other things. I will post here again when it is ready.

@Carl Love 

Physics:-Fundiff implements functional differentiation, it computes a functional derivative, an operation at the realm of variational calculus. Because Physics is all about a principle of minimal action - a variational principle - it so happens that basically all formulations in classical and quantum physics require computing functional derivatives (of the action, and equating the result to 0). If one day you happen to work with variational calculus you will be surprised with the computational power behind Fundiff . Some of it is shown in several posts here in Mapleprimes about quantum mechanics and classical field theories.

If you are still not finding the computation familiar, check Wikipedia at https://en.wikipedia.org/wiki/Functional_derivative - to go to the point, search the page for Functional derivative o a function.

On the other hand, Physics:-diff implements, in a general/formal sense what in jet calculus is called jet space - frequently mentioned in the context of differential equations. Generally speaking, you consider independent variables, dependent variables, and their partial derivatives as a set of equivalent independent objects with respect to which you can differentiate. For example, all the Lie theory of symmetries of differential equations is based on this concept (to see the simplistic core of the implementation, give a look at ?PDEtools:-ToJet). The implementation of Physics:-diff in computer algebra is tricky due to the way Maple's diff (without Physics) got implemented day one, making necessary to implement together the concept of "computing the derivative with respect to x at fixed f(x, ...)" (see the help page), and in this way implement, for the first time in Maple, true partial derivatives, for real, as the ones you use when formulating thermodynamics for instance.

People sometimes think of these two commands as interrelated because, if you are functionally differentiating an integral, you can frequently express the result using a sum of terms all of which involve calls to Physics:-diff. But these two commands are actually different. Most of the things mentioned above are described in more details in the corresponding help pages.

By the way, it is remarkable that while these commands are at the very core of formulations in Physics, I actually coded them using Maple in 1994, they where my first programs, and it was the first time these operations got implemented in computer algebra - I even published a paper with them in Computer Physics Communications, still today there is no equivalent for them in Mathematica.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft.

 

There is clearly an issue here (BTW, good catch vv!), as usual splitting into two: "what is happening?" and "is that ok?". What is happening: Change is a wrapper for PDEtools:-dchange; debugging it you see that its input for 2J is not nearly the same as for J - mainly in the case of 2J only, the change of variables is performed first in the inner integral. The undesired output for J (not for 2J) appears while changing variables in J taking the iterated double integral as a multiple integral. "Is that OK?": generally speaking yes, however in cases like this changing variables one integral at a time takes you to a much simpler and readable result.

I'll give this a closer look later today or tomorrow and adjust the code to return the simpler form - then upload the adjustment within the next "Maplesoft Physics Updates for 2018.1" - will write here when it's ready.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

Carl, very beautiful post, illustrative and insightful!

Best

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

 

 

@zhuxian 

Check the help page of PDEtools:-Library (the set of programming routines with which the PDEtools package is built), in particular, PDEtools:-Library:-Specialize_Cn and its optional arguments are what you want.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@digerdiga 
 

restart

"  with(Physics):"

 

Set your metric, and in doing so give a closer look to both the default signature and the coordinates for this metric:

g_[[15, 23, 2]]

" _______________________________________________________"

 

" `Systems of spacetime Coordinates are:` {X=(u,r,theta,phi)}"

 

" `Default differentiation variables for d_, D_ and dAlembertian are:` {X=(u,r,theta,phi)}"

 

"`The ``Eddington (1924)`` metric in coordinates ``Finkelstein(1958)`"

 

"`Parameters: `[m]"

 

"`Resetting the signature of spacetime from `(-` - - +`)` to `(-` + + +`)` in order to match the signature in the database of metrics`"

 

" _______________________________________________________"

 

Physics:-g_[mu, nu] = Matrix(%id = 18446744078371044758)

(1)

So: the signature and coordinates are, respectively, (- + + +) and (u, r, theta, phi).

 

Now: what I explained in the previous reply is not "how to change the metric" but "how to set the signature". Recalling, generally speaking, for a curved spacetime, the signature only tells the form of the Minkoski metric in an orthonormal frame (the tetrad system, that you can define locally, at any point of spacetime), and generally speaking it changes nothing in the form of the non-flat metric you choose ([15,23,2] in this example).

 

So you can change the signature and that will not change the metric. For example, this is the signature in this moment

Setup(signature)

[signature = `- + + +`]

(2)

Here I change it and the metric is still the same as (1)

Setup(signature = `+---`)

[signature = `+ - - -`]

(3)

"g_[]"

Physics:-g_[mu, nu] = Matrix(%id = 18446744078370950190)

(4)

You noticed this but interpreted it incorrectly: the above is correct and according to the design here, there is no reason to think that changing the signature should change the metric (as said it only changes the metric in the local, tetrad system of references).

 

On the other hand, it is the case that, computationally, we frequently want to change the signature and with that also redefine the metric, signs, lines and columns, even reorder the list of coordinates. The command for that is Redefine . As said in the previous reply: the value of computer algebra is proportional to your use of the help pages, and getting skilled in grabbing the information you need without reading the whole thing is part of the game...

 

Anyway, here is some of this valuable command. First reset the signature to what it was when you loaded the metric

"Setup(signature = `-+++`)"

[signature = `- + + +`]

(5)

The metric is the same as (1) and (4)

"g_[]"

Physics:-g_[mu, nu] = Matrix(%id = 18446744078370862494)

(6)

Now open the help page for Redefine and play with it a bit. Your desired signature does not change the order of the coordinates so the first thing I would explore is this:

Redefine(metric, tosignature = `+---`)

Matrix(%id = 18446744078370860798)

(7)

But the metric has not been set to (7), the above is only a preview of the redefinition you indicated, the metric it is still equal to (1):

"g_[]"

Physics:-g_[mu, nu] = Matrix(%id = 18446744078370862494)

(8)

As explained in the help page this permits you verifying that the redefinition you are exploring is indeed what you want.  Just to get confidence in the command, ask it to redefine everything, expecting that the coordinates will not change of course

"Redefine(all,tosignature = `+---`)"

[X], Matrix(%id = 18446744078483705358)

(9)

Indeed the coordinates are still X = (u, r, theta, phi). Assuming that the changed metric (7) , which is the same one shown in (9), is the one you want, then proceed according to what the help page of Redefine says and set this metric

"Redefine(setmetric,tosignature = `+---`)"

Matrix(%id = 18446744078483694646)

(10)

Check now the metric: it got set to what you wanted, it has an overall different sign with respect to (1)

"g_[]"

Physics:-g_[mu, nu] = Matrix(%id = 18446744078371043558)

(11)

Summary: the command for redefining the metric, changing signs and eventually lines and columns, by changing the signature, is Redefine.

 

On the other question, how to collect in the line element, note first that it already comes collected:

g_[line_element]

(r-2*m)*Physics:-d_(u)^2/r+2*Physics:-d_(u)*Physics:-d_(r)-r^2*Physics:-d_(theta)^2-r^2*sin(theta)^2*Physics:-d_(phi)^2

(12)

But suppose it were not collected, say as in

"expand((r-2*m)/r*Physics:-d_(u)^2+2*Physics:-d_(u)*Physics:-d_(r)-r^2*Physics:-d_(theta)^2-r^2*sin(theta)^2*Physics:-d_(phi)^2)"

Physics:-d_(u)^2-2*Physics:-d_(u)^2*m/r+2*Physics:-d_(u)*Physics:-d_(r)-r^2*Physics:-d_(theta)^2-r^2*sin(theta)^2*Physics:-d_(phi)^2

(13)

In the above, d(u)^2 is not collected. First you need to see "what" is to be collected, the simplest way is to use lprint

"lprint(Physics:-d_(u)^2-2/r*Physics:-d_(u)^2*m+2*Physics:-d_(u)*Physics:-d_(r)-r^2*Physics:-d_(theta)^2-r^2*sin(theta)^2*Physics:-d_(phi)^2)"

Physics:-d_(u)^2-2*Physics:-d_(u)^2*m/r+2*Physics:-d_(u)*Physics:-d_(r)-r^2*Physics:-d_(theta)^2-r^2*sin(theta)^2*Physics:-d_(phi)^2

 

 

You see it is the d_ command you need to collect. So this collects the way you wanted.

"collect(Physics:-d_(u)^2-2/r*Physics:-d_(u)^2*m+2*Physics:-d_(u)*Physics:-d_(r)-r^2*Physics:-d_(theta)^2-r^2*sin(theta)^2*Physics:-d_(phi)^2,d_)"

-r^2*sin(theta)^2*Physics:-d_(phi)^2+2*Physics:-d_(u)*Physics:-d_(r)-r^2*Physics:-d_(theta)^2+(1-2*m/r)*Physics:-d_(u)^2

(14)

However, as said, never use a command without giving a quick look at is help page. Check collect  and you will see the options you have.

``


 

Download Redefining_the_metric_by_changing_the_signature.mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@unproductive 

I realize your frustration. Writing in a forum like this one, anyway, is supposed to be more about asking for help, and this is indeed something this forum does well, wonderful people around. Your post, however, may be seen more like a ranting (the frustration at the root, it is part of real life), but only that, without question. People just tried to interpret and help you anyway.

If there is a question or something we could help, I am sure many here would be happy to resolve the issue. No need to wait, or write 100 pages of C++. Perhaps this situation also serves the purpose of understanding more about computer algebra systems: they all have little things here and there that do not flow exactly as it happens in our human brains. Typically it is a small number of things. My experience, without having studied A.I., is that as soon as you get these few things, intuition develops fast and all CAS are easy to use.

In case it is of use for you, my area is theoretical physics, time ago I wrote "Mini-Course: Computer Algebra for Physicists", divided into 10 sections, a course I frequently give in 5 days, and the first five sections are Maple 101, including all the "little things" that (in my view) you need to get familiar with in order to launch. These first five sections certainly cover the question you had about a maple function / procedure, or the like, won't take you more than one afternoon of time and doesn't require writing any program in any language. Maybe looking at those five sections is worth the time for you too - say - before giving up computer algebra systems in general, specially if you work with AI and engineering.

Best

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@awass@Preben Alsholm@tomleslie,

As Preben noted, a project like Maple, mathematical software, is always work in progress, and by several people. I think we all agree that uniformity is desired, it makes the use of software intuitive. And Maplesoft people developing this Maple strives for uniformity - as humans do, with imperfections here and there. The amount of things to be done is always enormous, prioritizing becomes an art, and the project moves forward as some of you have seen along the years. I see all this as rather normal, not wrong or horrifying.

On this particular issue: some years ago someone asked for Matrix input in dsolve (was it you Preben? I can't remember now). It was easy to implement, so I implemented it - then never remember to update the documentation. Changing the output, however, is not a good idea: lots of programs call dsolve and the output is expected to be of a certain form. Introducing a new form can be a problem unless we introduce a keyword to exceptionally ask for that ... maybe, but then how important is that in this moment if compared with the other things being developed? 

Anyway, the fact is that dsolve/numeric and dsolve/series are nowadays handled by other people, who are involved with other things, and found other projects more relevant than accepting Matrix input.

And then, regarding uniformity, you need to have in mind that not all the sectors of the software advance at the same time, and to hold on developments because of that - to me - doesn't sound like a good idea. I prefer to co-exist with this lack of uniformity regarding advanced features. 

By the way that is also the case of PDEtools, the FunctionAdvisor and Physics: all these packages have advanced features that are still not present all around. To mention but one, consider the automatic matching of portions of keywords and making that matching case-insensitive.

So yes, we want uniformity, but in various situations, it won't be there, and all OK with that. I will update dsolve's page to make it clear that it accepts Matrix input, not by accident, but to fulfill a request made here in Mapleprimes time ago, and this feature won't change in future releases.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@utcyp 

As mentioned, this solution involves a symbolic composition of a differential operator (with derivatives with respect to x and y), making its use not straightforward. In practice, unless you find a closed form for this symbolic composition (I couldn't), the only way to use this solution is to truncate the series (from infinite to - say - 10, or whatever number of terms you want). Try for instance simplify(value(subs(infinity = 10, (3)))), then you can evaluate the solution at an arbitrary point (t, x, y).​

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@Carl Love 

Hi Carl, it seems to me you are reading wrong? Replace, in (8), _F1(x,y) by 1, the rhs of the boundary condition, then M by the explicit procedure (7) and you have the solution returned by pdsolve (3). So you do have something of the form M@@n where M is a procedure, not something where M is algebraic and n a procedure. You may prefer to lprint (3)  to read it properly.

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

@John Fredsted 

I see. It is because the priority of the Physics updates for Maple 2017 is higher than the one I set for this patch to the normalizer of PDEtools. I adjusted the priority now, downloaded the Physics updates for 2017, installed both in the same lib directory, and it works fine, as you see below. The download link for the normalizer of PDEtools is updated too. Could you please try again and let me know if it now works for you? 

with(Physics); Coordinates(X); g_[sc]; with(Tetrads); omegaDef := omega[mu, c, d] = Physics:-`*`(Physics:-`^`(2, -1), Physics:-`*`(e_[`~rho`, c], d_[mu](e_[rho, d])-d_[rho](e_[mu, d]))-Physics:-`*`(e_[`~rho`, d], d_[mu](e_[rho, c])-d_[rho](e_[mu, c])))-Physics:-`*`(Physics:-`*`(Physics:-`*`(Physics:-`*`(Physics:-`^`(2, -1), e_[`~a`, mu]), e_[`~rho`, c]), e_[`~sigma`, d]), d_[rho](e_[sigma, a])-d_[sigma](e_[rho, a]))

`Default differentiation variables for d_, D_ and dAlembertian are: `*{X = (x1, x2, x3, x4)}

 

`Systems of spacetime Coordinates are: `*{X = (x1, x2, x3, x4)}

 

{X}

 

`Systems of spacetime Coordinates are: `*{X = (r, theta, phi, t)}

 

`Default differentiation variables for d_, D_ and dAlembertian are: `*{X = (r, theta, phi, t)}

 

`The Schwarzschild metric in coordinates `[r, theta, phi, t]

 

`Parameters: `[m]

 

Physics:-g_[mu, nu] = Matrix(%id = 18446744078354014686)

 

`Setting lowercaselatin_ah letters to represent tetrad indices `

 

0, "%1 is not a command in the %2 package", Tetrads, Physics

 

0, "%1 is not a command in the %2 package", Tetrads, Physics

 

omega[mu, c, d] = (1/2)*Physics:-Tetrads:-e_[c, `~rho`]*(Physics:-d_[mu](Physics:-Tetrads:-e_[d, rho], [X])-Physics:-d_[rho](Physics:-Tetrads:-e_[d, mu], [X]))-(1/2)*Physics:-Tetrads:-e_[d, `~rho`]*(Physics:-d_[mu](Physics:-Tetrads:-e_[c, rho], [X])-Physics:-d_[rho](Physics:-Tetrads:-e_[c, mu], [X]))-(1/2)*Physics:-Tetrads:-e_[`~a`, mu]*Physics:-Tetrads:-e_[c, `~rho`]*Physics:-Tetrads:-e_[d, `~sigma`]*(Physics:-d_[rho](Physics:-Tetrads:-e_[a, sigma], [X])-Physics:-d_[sigma](Physics:-Tetrads:-e_[a, rho], [X]))

(1)

Define(omegaDef)

`Defined objects with tensor properties`

 

{Physics:-D_[mu], Physics:-Dgamma[mu], Physics:-Psigma[mu], Physics:-Ricci[mu, nu], Physics:-Riemann[mu, nu, alpha, beta], Physics:-Weyl[mu, nu, alpha, beta], Physics:-d_[mu], Physics:-Tetrads:-e_[a, mu], Physics:-Tetrads:-eta_[a, b], Physics:-g_[mu, nu], Physics:-Tetrads:-gamma_[a, b, c], Physics:-Tetrads:-l_[mu], Physics:-Tetrads:-lambda_[a, b, c], Physics:-Tetrads:-m_[mu], Physics:-Tetrads:-mb_[mu], Physics:-Tetrads:-n_[mu], omega[mu, c, d], Physics:-Christoffel[mu, nu, alpha], Physics:-Einstein[mu, nu], Physics:-KroneckerDelta[mu, nu], Physics:-LeviCivita[alpha, beta, mu, nu], Physics:-SpaceTimeVector[mu](X)}

(2)

And this is what you expect to see with the patch to the PDEtools normalizer installed:

showstat(`PDEtools/Normal`, 33 .. 35)


`PDEtools/Normal` := proc(ee)
local EE, Num, Den, G, `1/den`, `1/num`, LD, LD2, LN, LN2;
       ...
  33       try
  34           `PDEtools/Normal/division`(G,Den,`1/den`)/`PDEtools/Normal/division`(G,Num,`1/num`)
           catch :
  35           `1/den`/`1/num`
           end
       ...
end

 

For next time, any similar situation, this is how you check the priorities of the libraries in use: launch the Browse libraries applet and, in Library, scroll to choose the library you want to inspect.

LibraryTools:-Browse()


 

Download With_the_normalizer_adjusted.mw

Edgardo S. Cheb-Terrab
Physics, Differential Equations and Mathematical Functions, Maplesoft

First 29 30 31 32 33 34 35 Last Page 31 of 64