Laplace transform in 14M030

[JohnArcher]

John R Archer

I need some help to understand what is happening.
This simple file produces an out of memory error in 14M030 using WinXP,SP3 with plenty of ram.

[ViktorKorobov]

On 12/20/2009 12:52:30 PM, JRARCHER wrote:
>
>John R Archer
>
>I need some help to understand
>what is happening.
>This simple file produces an
>out of memory error in 14M030
>using WinXP,SP3 with plenty of
>ram.

...


Viktor

[PhilipOakley]

Mine works. It produces two answers which allow for
fully complex values of s. {It takes quite a few
seconds)

That extra 'assume, t>0' does seem to be required
before the Laplace to get the single answer shown by
vikkor.
I wonder why? aren't Laplace transforms taken from 0
(zero) anyway? Another one of those common
assumptions problems!

Philip Oakley

[PhilipOakley]

Also it looks like V11 and V14 get different
results!

If I remember there is a sign convention difference
between Mupad and Maple engines in the exp(+/- i
theta) area.

Note the 1/2 factor in front of one

Mainly note that one has 3 terms on the top line and
the other 4 terms...

Philip Oakley

[AlvaroDíaz]

On 12/20/2009 6:29:15 PM, philipoakley wrote:

>If I remember there is a sign
>convention difference
>between Mupad and Maple
>engines in the exp(+/- i
>theta) area.

But is about float point numbers in ilaplace, the workaround is



>Note the 1/2 factor in front
>of one

I don't have this from mcad11. F3 is the answer from mcad11 in the attached file.

About the memory lack, I can think only in two possibilities: 1. Not enough swap file, 2. Some issue naming the laplace transform function as the original function (Rarc).

Regards. Alvaro.

[TomGutman]

The sign convention difference is for Fourier transforms, not Laplace transforms. The posted use of -s with a replacement of s with -s is essentially meaningless. There are (in some MC14 versions) bugs in the invlaplace calculations, and such a procedure may result in changing the form of the operand just enough to avoid those bugs in particular contexts.
__________________
� � � � Tom Gutman

[AlvaroDíaz]

On 12/20/2009 11:05:57 PM, Tom_Gutman wrote:
>... The posted use of -s with a replacement of s with -s is essentially meaningless.

It is for workaround not a sign bug but a decimal point bug, without rewriting the expression.

Regards. Alvaro.

[JohnArcher]

On 12/20/2009 12:52:30 PM, JRARCHER wrote:
>
>John R Archer
>
>I need some help to understand
>what is happening.
>This simple file produces an
>out of memory error in 14M030
>using WinXP,SP3 with plenty of
>ram.



John R Archer

Thankyou all for replying. The "assume t>=0" works, but I do not know why. 11.2a is much faster for Laplace and confrac.

Phil, I saw that the release notes mention the Laplace sign change but the 11.2a format works just fine.

Val, thankyou for your collection of previously unsupported keywords. Using Confrac in 11.2a is great for avoiding series solutions involving denominators that do not factor;it makes short work of some very ugly expressions, allowing easy contour integration solution after removing RHP roots.

This work is part of the back-up math behind my patent concerning arc fault detection in electrical wiring(Raytheon/Navy).
Arc faults in aircraft wiring are still of interest to me even though I am 74 and retired. I am currently,

Chair, Technical Committee 4
IEEE EMC Society.
archerj@ieee.org

[JohnArcher]

John R Archer

I apologise to Viktor for typing Val.

[ptc-1368288]

"I saw that the release notes mention the Laplace sign change".

About the change of sign, my qualification is " a glorified idiotic from non user". The same I have replied and exemplified about Fourier transform and the change of sign. For those who prefer not mistake and get no more confused, just plug the project Laplace domain instead of plugging a function of the inverse domain as in fact, F(-s) is redundant of telling the symbolic to invlaplace. Interested collabs can check deeper by revisiting my Mathcad 11.2a Laplace DE solvers [1rst & 2nd order]. Another good test is the "TurboGen" work sheet.

jmG

[ptc-1368288]

On 12/20/2009 8:11:16 PM, JRARCHER wrote:
>On 12/20/2009 12:52:30 PM, JRARCHER
...
> but I do not know why.
>11.2a is much faster for Laplace and
>confrac.

==> For the Laplace, 11.2a is the Maple, that explain all whereas Maple has its own pattern recognition ! For the confrac, also Maple deeply embedded from the old DOS algo.

>Phil, I saw that the release notes
>mention the Laplace sign change but the
>11.2a format works just fine.
>
>Val, thankyou for your collection of
>previously unsupported keywords. Using
>Confrac in 11.2a is great for avoiding
>series solutions involving denominators
>that do not factor;it makes short work
>of some very ugly expressions, allowing
>easy contour integration solution after
>removing RHP roots.
>
>This work is part of the back-up math
>behind my patent concerning arc fault
>detection in electrical
>wiring(Raytheon/Navy).
>Arc faults in aircraft wiring are still
>of interest to me even though I am 74
>and retired. I am currently,
>
>Chair, Technical Committee 4
>IEEE EMC Society.
>archerj@ieee.org
______________________________

About
"Using Confrac in 11.2a is great for avoiding series solutions involving denominators that do not factor;it makes short work of some very ugly expressions"

There is continued fraction and continued fraction but not the same. A "continued fraction " is the Thiele continued fraction, which as such I don't know if Maple has that construct but in Mathcad 11.2a, I have made the construct, i.e: the long form. Also in Mathcad 11.2a DAEP, the same long form is presented but directly converted in the rational form. The rational form can be converted in the other form of continued fraction by the Maple "confrac", which "confrac" produces the same result but with an econmy of operations. By luck you may find the voluminous amount of work posted in the collab ... the keyword is Thiele.

jmG

[ptc-1368288]

On 12/22/2009 4:20:20 PM, jmG wrote:
>On 12/20/2009 8:11:16 PM, JRARCHER
>wrote:
___________________________

JOHN,

You may find something about "confrac" in there:

http://collab.mathsoft.com/read?80981,11e#80981

I don't understand why you need Laplace ?
If a model is constructed in the Laplace domain or if a DE is solvable by the Laplace DE solver[1rst & 2nd order] OK, then invlaplace solves in the 't' domain. Reading Viktor and your "confrac", if you want to approximate by a continued fraction, no problem using Thiele and some points and re-expressing by a "confrac". You will just have to check for eventual glitches. If you need more help, repost sometimes by mid of january 2010.

jmG

[JohnArcher]

John R Archer

Jean, the attached file shows why I love "confrac".

[PhilipOakley]

On 12/27/2009 1:21:39 PM, JRARCHER wrote:
>
>John R Archer
>
>Jean, the attached file shows
>why I love "confrac".

John,

Could you repost the attachment. It doesn't appear
to download.

Not sure if that is because of the double period
".." in the file name.

Philip Oakley

[JohnArcher]

John R Archer

I will use a little English this time!

[ptc-1368288]

On 12/27/2009 1:21:39 PM, JRARCHER wrote:
>
>John R Archer
>
>Jean, the attached file shows
>why I love "confrac".

John,
_______________________________

Will read you again next year.
Sounds very interesting !

Jean

[ptc-1368288]

On 12/27/2009 1:21:39 PM, JRARCHER wrote:
>
>John R Archer
>
>Jean, the attached file shows
>why I love "confrac".
______________________________

The file does not download, you have double ".."
Please try again.
Not sure what you are attempting with the Laplace of Rarc(t) ???

Jean

[JohnArcher]

Mea culpa, Jean. I reposted and Philip was able to open it.
I was 74 on the 11th and have not been found to be dotty for some time!

The puse waveform produces "out of memory" errors in 14M030 and was =logged as a bug by Mona.

I play around with Laplace pulses like this to,
1. Model a disturbance closer to the real thing.
2. Avoid the use of step functions which can produce non-integral =indices. I can handle these but they cause a lot of extra work.

[JohnArcher]

John R Archer

It looks as if the file did not post.

[ptc-1368288]

On 1/15/2010 12:38:25 AM, JRARCHER wrote:
>
>John R Archer
>
>It looks as if the file did
>not post.
____________________________

It never posted !
You should minimize the steps of transformation.
I wouldn't dare certifying any of "Now I can solve".

Continued fractions of your kind depend upon the NUMERICAL derivative, which numderiv aren't more accurate than from very low (even fail) to better. That is my point, maybe a very crucifying point but you can take it between us, can you John ? It stops at 17 !!! Did you want to solve anything in I(x) ?

Jean

[ptc-1368288]

John,





DELETED MESSSAGE


Jean

[ptc-1368288]

John,

Here is the final work, directly from the quick plot of your input I(x), after digitizing. Nothing refined as it seems useless from the residual plot. There may be a simple homographic function, but not tried unless you specify some interest in it.

Enjoy and decide what to do in your words "solve".

Jean

[ptc-1368288]

On 1/15/2010 3:45:39 PM, JRARCHER wrote:
>Jean, this was just a demo to
>show a denominator that would
>not "solve".
>There are a lot of right half
>plane poles to be removed; no
>circuit feedback
>is involved. I have sent you a
>private email.
_______________________________

Poles & zeroes happen from a resulting physical model but not necessarily from the same modified model or otherwise "fabricated". My point is that the approach you have use in your demo is totally inadequate, i.e: you were trying (or theoretically trying) to solve for the denom of a wrongly converted initial equation. You can see what I'm saying in yellow, right from the I(u) and the last two plots.
The confrac conversion is mathematically correct but numerically incorrect. In the conversion, it is obvious that Maple does not take the symbolic derivative of the terms involved, but only the numerical derivatives and with such an immense amount of terms in the equation, the error propagation is the problem on the top that numerical derivatives aren't very accurate and maybe very poor or simply fail... therefore the confrac fails, simply ! I bet that the Z(s) model with only few terms would succeed.

Hopefully some collabs got interested and read more about the culprit.

Jean

[ptc-1368288]

... here is the homographic fit.
This function is very "reflexive" like the exponential and will fit with an infinite set of coefficients. In terms of a physical real model, it means that if some parameters cost $ an optimum cost for the same fit can be exploited for the same fit. Quite a transcendental notion, as the exponential is a transcendental function. With all my respect and if you have no more question concerning the work sheet you have passed, I will leave this thread. Note that the digitization from a plot can't produce a clean data set. One way or another the original plot and the digitizer have to select pixel location left/right ... etc.




Jean

[JohnArcher]

John R Archer

Here is part of the plug and chug worksheet that produces real msnufacturable designs.

Mathcad 11.2a with Image processing, Solving and Optimisation, Signal Processing packs.
WinXp Pro,SP3.

To make it play on 14M030, the Rarc(s) equations must be typed in, and Convert changed appropriately.

[ptc-1368288]

On 1/16/2010 3:47:02 PM, JRARCHER wrote:
>
>John R Archer
>
>Here is part of the plug and
>chug worksheet that produces
>real msnufacturable designs.
>
>Mathcad 11.2a with Image
>processing, Solving and
>Optimisation, Signal
>Processing packs.
>WinXp Pro,SP3.
>
>To make it play on 14M030, the
>Rarc(s) equations must be
>typed in, and Convert changed
>appropriately.
_______________________________

John,

I just read your e-mail
Answer: YES, you can in full confidentiality.
My e-mail didn't send .

I have started reading these one.

Jean

[ptc-1368288]

On 1/18/2010 1:09:39 PM, jmG wrote:
>On 1/16/2010 3:47:02 PM, JRARCHER wrote:
___________________________

I'm catching up in that work sheet

"The problem.

The denominator does not solve.

It is a transmission line problem; we expect right half plane components in the solution. These poles must be avoided to get a causal result.

If a series solution is used, how many terms must be used to include the high bandwidth arcing event?
Is a continued fraction better?
Does a real continued fraction improve in accuracy with more terms?

If the arc is modelled as a step function, then fractional powers of "s" will involve a lot more work. This is part of a plug and chug worksheet, written for others to use following my retirement."

...

==> The denominator does not solve because the function (looks like a straight line) just crosses the system at 0.

==> "we expect right half plane components in the solution"... Plot I(u) not I(s) and see an hyperbolic arc not crossing the X axis. Then, if there is a solution related to that arc, it will be only a point solution. Maybe you mean something much different by "SOLUTION". Maybe you mean an "InverseFunction". For I(u) the inverse function is the function itself. If another function would intersect I(u), then there would be one or more solutions or none.

For the other questions, they have all been replied before. Expanding I(u) in continued fraction is invalid, no matter the number of terms. Expasion in series is not valid either. Therefore there is/are no poles involved. The approximation of this function is about the same as done via digitizing directly.

I don't understand is what is Laplace doing there ? The Rarc(t) is already in the time domain, i.e: solvable. Laplace has nothing to do in there unless you say otherwise that Rarc is in the Laplace algebra and want it back in the time domain.

For worth it's worth attached.

Jean

[mzeftel]

John,

I also get an out of memory error in Mathcad 14 m030, so I'll log it.

Does it work for anyone in other versions of Mathcad 14? m10 or m20?

Mona

[ELSID]

Memory fail on M020 Standalone and M035 on enterprise license