MORELIE.DOC More instructions/explanations for LIE (c) 1990,2000 A K Head
------------------------------------------------------------------------------
The following paragraph is out of date for recent versions of LIE as the
display of memory space can be now be turned on and off by GCON() and
GCOFF() with the default being OFF.
Those flashing lights
---------------------
LIE has a number of my debugging aids built in so that I
can investigate your complaints using a program identical to yours. One of
these gives the display at top right of screen. At each garbage collection
( which is decided automatically by MUMATH ) two blobs appear. Their distance
apart measures the effective usable free memory space at that moment, at 4k
per dot. There is no easy way to turn these off so you will have to put up
with them. At least they show that the program is running. Or you can watch
with bated breath to see if they come together for then:
Memory Space Exhausted
Abort, DOS?
----------------------
However much memory is available, there will always be
cases that need more. The surprising thing is how much can be done in the 256k
used by MUMATH.
When you get this message, usually in DOLIE but it can be anywhere,
choose D for DOS. If you choose A for Abort then there will be some memory
space, often a lot of memory space, that the garbage collector cannot reach.
So exit to DOS and reload a clean program LIE.
You may be able to do something about it.
If you have simultaneous DEs then number them so that the simplest
lowest order equations have the lower numbers and so are processed first. This
will give the shortcut the best chance to save memory space. Try several
different orderings if simple and lowest order do not coincide.
Consider introducing new dependent variables so as to lower the order of
high order derivatives. Usually the application of the solution of these
extended equations to the original is transparent but read Exercise 2.10 of
Olver's book.
Trig functions. The flag TRGSQ is set to 1 so that COS^2 is
automatically replaced by 1 - SIN^2. If your DEs have more COS than SIN then
try TRGSQ:-1; before RDSing in the data. SIN^2 will then be replaced by 1 -
COS^2 throughout the calculation and perhaps less memory space will be needed.
Op8 extends the Def Eqns by adding their integrability conditions.
As this is a process that can be very time and space consuming, it has the low
priority of 8. But there are cases where DOSOLV cannot solve the Def Eqns but
it could if these integrability conditions were included as the first step in
the solution process. So this is something you can try if the standard use of
DOSOLV fails to solve the Def Eqns. The procedure would be to start again and
generate the Def Eqns by DOLIE(). Then do DOINTCON(). Then do DOSOLV().
An example is SCHWCHLD.DAT, the equations of the Schwarzschild metric.
Compare the complex equations in A# produced by DOLIE with their
simplification after DOINTCON.
Useful Hints
------------
The ESC key interrupts a running MUMATH program. So if output is
scrolling across the screen faster than you can read then press ESC. When
ready choose C to Continue and it will continue from where it was.
It is possible that DOSOLV can go into a loop, repeating the same
Ops on the same equations. If this appears to be happening then press ESC as
described above and choose B for Break. At the prompt, which will be ?1, type
STOP#:TRUE_
followed by and where that last symbol is "underline". In due course
the program will come to a graceful halt at the standard prompt of ? and you
can then investigate say by doing single steps with DOSOLV(0).
Saving output. It has been mentioned that control-P toggles on/off
sending a copy of screen output to a printer. This is a property of the DOS
operating system. But you may want a copy of the screen output to go to a
file. There are a number of public-domain programs, such as PRN2FILE, that
divert printer output to a file. One of these together with control-P will do
what is required.
DOLIE()
-------
This takes whatever differential equations are in DE# and calculates
their prolongations, substitutes as specified by DV# and then splits the
result into Defining Equations. It does these three steps for eqn [1], then
[2] etc. While doing this it outputs three lines of information per equation
as illustrated in LIE.DOC. It does not output the Def Eqns as these can be
very large and it is left to your choice to see them by A#;
Defining Equations
------------------
The Def Eqns are (a) left in A# for use by DOSOLV and (b)
written to disk as the file SAVEA#.LIE for use by DOCHECK.
DOSOLV
------
DOSOLV is heuristic and has a repertoire of 8 operations to try. At
each step the as yet unsolved equations are in A#. The number of equations
goes up as an equation is split into parts or down as equations reduce to zero
and are removed from A#. When it can do no more operations, it outputs what
remains.
In the example of HEAT1.DAT, it will be seen that there is one equation that
remains unsolved. It is a copy of the 1-D heat equation. This is because it is
a linear equation. If your original DEs were non-linear, there should in
general be no equations left unsolved. But there are exceptions, and a well
known example is BURGERS.DAT.
The UUU and XXX are now supposed to be the general solution of the original
Defining Equations but as this program is the product of human frailty, you
would be wise to check. So
DOCHECK
-------
This moves A# to B#, reads the original Defining Equations from the
file SAVEA#.LIE into A#, substitutes into A# the UUU's and XXX's from B#
which are supposed to be a solution and calls DOSOLV in case some more solving
can be done. Then it should be that A#=B#.
Expect the output: Check OK, proceed to DOVEC
If so, then proceed to DOVEC.
The alternative message is: Do DOCHECK again now.
As DOCHECK calls DOSOLV to see if any more solving can be done, regard it as
an iterative procedure and keep doing it a few times when told, to see if it
will converge.
DOVEC()
-------
This takes whatever equations are in A# and calculates the
corresponding vectors. These are output and also left in V# for use by DONZC.
Having been told that a term such as D#(X1) is to be read as partial d/dX1,
the output is obvious. As there can be redundant members of the Def Eqns so
also for the resulting vectors.
DONZC()
-------
This takes the set of vectors left in V# and calculates the non-zero
commutators. These are output and also left in NZC#. In simple cases it can
identify a commutator as a multiple of a vector.
The function BRAK(vec1,vec2) calculates the commutator ( the Lie
bracket ) of two vectors and can be used by itself.
Operation of DOSOLV
-------------------
As the operation of DOSOLV is only heuristic, there may be
cases of Defining Equations that it does not fully solve. When it comes to a
halt there would be some unsolved equations in A# that should have been
solved. As mentioned above there are genuine cases where an equation remains
unsolved such as linear equations and BURGERS.DAT.
So if there are unsolved equations, inspect the equations that remain and
decide if they are ones that should be solved. Perhaps you can complete the
solution by pencil and paper. Or you could do the same thing inside this
program if you know how to use the general algebra facilities of MUMATH,
perhaps doing one vital step and then calling DOSOLV to complete the solution.
DOSOLV is designed for interactive intervention when needed. When called,
DOSOLV just takes whatever equations are in A# and tries to solve them step-
by-step, updating A# as it goes. So at any ? prompt you may intervene and do
things to the contents of A#. What can you do ? Any standard MUMATH operation
( so read the MUMATH manual ). And there are a number of high-level functions
listed at the end of the source code that could be useful.
There are two LIE functions that are useful when intervening.
The first is UNFAC(expression) as in, for example,
? TEMP: A#[3] - 2*A#[1];
? TEMP: UNFAC(TEMP);
? A#[3]:TEMP;
This subtracts twice the first eqn in A# from the third eqn and UNFAC
puts the result in standard form by removing any denominators and common
factors.
The second is EVSA#(expr1,expr2) as in, for example,
? EVSA#( F#(9,X1), X1^2*F#(999,X1) );
This is what you would type if you notice that there is an eqn for F#(9,X1)
in A# that has X1^2 as a particular solution. EVSA# stands for
" EValuate the Substitution throughout A# of expression1 by expression2 "
and is much used in LIE. Here it does what you would do by hand if
a particular solution were found and a call of DOSOLV will probably now
produce further steps towards a complete solution. Notice that a new F#
function is required and its sequence number is chosen far beyond
anything that will be reached by DOSOLV.
In any case the equations you leave in A# must have the following standard
properties:
The Defining Equations have the following properties in general:
(a) They are homogeneous partial differential equations.
(b) They are linear whether the input DEs are linear or not.
(c) They are over-determined and often redundant.
Those produced by DOLIE also have the properties:
(d) They are fully multiplied out and expanded and have no denominators.
(e) This means that each is the sum of terms, each term containing exactly one
F# function, either as such or in a derivative.
(f) The equations are the leading entries in the array A# and are followed by
the UUU and XXX.
(g) Parameter lists are in the order U1,U2,...X1,X2,...
The equations are never inconsistent as zero is always a solution.
DOSOLV takes the current A# and works through all equations trying operation
OP1, then through again trying operation OP2 etc. As of now there are 8 such
operations up to OP8. When it comes to a case where the operation is
applicable to an equation, it does it and then cleans up the equations that
remain so that they have the preceding properties (a)-(g). It then restarts at
OP1 and the first equation. It stops when no operation can be applied to any
equation, this usually meaning that there are no equations left.
OP1: The equation is an explicit "polynomial" in an X or U. Each power must be
zero so split up the equation. Polynomial has an extended meaning to cover
exponential, log, trig and some other functions such as ERF and EI.
OP2: The equation has no derivatives. Solve for the F# with the longest
parameter list and substitute globally.
OP3: An F# in the equation is implicitly a "polynomial". Substitute globally an
appropriate polynomial.
OP4: The equation can be integrated term by term. Do it.
OP5: The equation is effectively a linear differential equation of the second
order with constant coefficients or an Euler equation. Solve it.
OP6: The equation is effectively a linear differential equation of the first
order. Solve it.
OP7: Solve equation for an appropriate F# and substitute globally.
OP8: Include integrability conditions.
There are a number of extended output options in DOSOLV, mainly for debugging.
Four may be of interest.
DOSOLV(0) takes a single step in the solution process. It outputs 3 or 4 lines
of detailed information on the operation performed and the resulting A#.
DONSTEP(7) would do DOSOLV(0) 7 times.
DOSOLV(-8) runs to the end and outputs the 3 or 4 lines of information at each
solution step.
DOSOLV(-99) runs to the end and outputs the 3 or 4 lines of information and
also A# at each solution step.
These lines of information vary depending on which OP is involved. The first
line may be a single variable that is the operative variable for integration or
splitting a polynomial, then the target equation, then the result of the
integration or splitting, or if a substitution then the F# on one line followed
by its value to be substituted on the next line.
You may be interested to follow the solution process through with one of these
options in a simple case like HEAT1.
Integrations in DOSOLV
----------------------
LIE contains an integration package that is based on the
standard MUMATH package but much extended. Nevertheless there are some simple
integrals that it cannot do. If DOSOLV comes to one then it outputs a message
and continues with other operations. Just let it run. It may find a different
solution route and the need for that integral fades away ( eg EX238.DAT ).
POLY
----
If you have an A# that is giving DOSOLV trouble then you might like to
guess that a polynomial solution might be right ( it often is ).
Before doing this remember that the current state of LIE can always be saved by
SAVE(ANYNAME); which writes a diskfile ANYNAME.SYS and you can always come back
to that point by LOAD(ANYNAME); You can then try different guesses.
There are four options:
(1) DOPOLYALL(3);
(2) DOPOLYALL(3,X2);
(3) DOPOLY(F#(5,U1,X2),3);
(4) DOPOLY(F#(5,U1,X2),3,X2);
These are examples for a polynomial of degree 3. The degree is your choice
from zero up. (1) and (2) substitute an appropriate polynomial for every F# in
A#, (3) and (4) just for the specified F#(5,U1,X2). (1) and (3) generate
polynomials in all variables, (2) and (4) just in the variable X2 with
coefficients that are F#( remaining variables ).
Any vectors that come from a guess will belong to the Lie algebra if DOCHECK
is OK but the algebra may not be complete ( and there appears to be no way in
general of detecting if any vectors have been missed ). Option (1) is the most
drastic guess but it is certain that DOSOLV can solve the resulting A#. Option
(4) is the least drastic guess but may or may not be enough to enable DOSOLV
to proceed. The other two are intermediate.
Food for Thought
----------------
The current state of knowledge about solving the Def Eqns appears to be
what I will modestly call
" Head's Three Laws on the Defining Equations
for the Lie symmetries of Differential Equations ".
These have the same status as the Laws of Thermodynamics or
Newton's Laws of Motion. That is they are laws in the sense used in
the physical sciences, a summary of current knowledge and subject
to change or modification as new knowledge is found.
Head's First Law:
There cannot be an algorithm that finds the
general solution of the Defining Equations in all possible cases.
Corollary:
A computer program that tries to find such a general
solution must contain some heuristics.
Corollary:
Any such heuristic program must fail in some cases.
Corollary:
It is desirable that there be a number of such programs,
by different authors and using different heuristics, to increase
the chance that at least one of them will solve your particular
case.
Head's Second Law:
Although it is obviously possible to check if a
purported solution is in fact a solution of the Defining Equations
there cannot be an algorithm that verifies if it is the general
solution in all possible cases.
Corollary:
There cannot be an algorithm that verifies if the
resulting Lie algebra is complete in all possible cases.
Head's Third Law:
There is in general no way that a solving program
can make use of information about known elements of the Lie algebra
without increasing the possibility of missing other elements.
Final Message
-------------
You will have realized that program LIE is not just an automatic
black box. It may need your attention, insight and skill.
I thank Soft Warehouse Inc for permitting the use of a limited
version of MUMATH and all those who have made comments on LIE in particular
P.Clarkson, W. Hereman, G. Prince, D. Saunders and W.Sarlet.
Alan Head