@teh_allchemist The command to query for curent memory allocation by the OS to the running kernel is kernelopts(bytesalloc) and not kernelopts(bytesused).

The former reports on allocated memory. The latter reports on how much was "processed" by the memory management system, and generally shows a much larger value that is not at all an indication of the current memory allocated. It sounds like you want the former, for your measurement.

Also, passing out a huge collection of lists to Matlab, and then invoking operations in Matlab to extract the numeric array values, line by line and entry by entry or even column by column, doesn't sound like an approach for any kind of decent performance.

Instead, why not convert the huge list of equations to a Matrix or Vector of just the numeric values, in Maple itself, and pass that to Matlab instead. You could even store it to a file. You could store a Vector of the column header names separately from the numeric data. You could store the purely float data in a Matrix or Vector in Maple with datatype=float[8] as itsme suggested. You could export that to text file, or even to a Matlab format binary format file. I would be surprised if this couldn't all be done very efficiently.

I suggest processing the symbolic equations in Maple, first, and then exporting the resulting compact numeric Matrix and a small Vector of just the column header names. That's what itsme's code does, I believe.

Even if you are sitting with control currently in Matlab and have produce the large symbolic list structure in a running (associated) Maple session, then it'd likely still be much better to make a single `maple` call-out, to convert the rhs's of the symbol equations to a Maple datatype=float[8]  Matrix in one fell swoop. Even if you had to make another `maple` call-out from Matlab to Maple, in order to get Maple to export that to a compact Matlab binary format file. 

Perhaps I don't properly understand which program you are running in to execute commands. It sounds to me as if you are running in Matlab, and calling out to Maple to run simulations and generate results (which you then want to import into your running Matlab). Is that near right?

@mapleq2013 The compile option translates the Maple code in the DE system to C, compiles that, and uses it for the many evaluations (think of the rhs driving terms in an explicit system, to get just the gist). All these stages are done internally, out of view.

There is a bit of overhead cost in such treatment (esp. the first invocation of the internal compiling mechanisms) but for non-small systems like yours the resulting faster evaluation code may bring a performance benefit that outweighs such overhead. 

@mapleq2013 I believe you'll find that the `parameters` options works in that uploaded sheet even without the `compile` option accompanying it. You may have either been using invalid syntax for the `parameters` option, or (by the sound of that emitted message) trying to implicly use a "parameter" by just having an unassigned name in the DE yet not explicitly specifying it with the `parameters` option.

To reiterate, the Standard Java GUI is a separate process from the running kernel. On Windows the kernel is `mserver.exe` and the GUI is `maple.exe` (or `maple.exe *32`) in the Task Manager. On Linux the kernel is `mserver` and the Standard GUI is just "java" as seen under the `top` task manager utility.

Using dsolve/numeric's `parameters option helps on your example with kernel memory and execution time. Switching that long single 2D Math expression for the DE system to 1D Maple Notation (red code) helped with the GUI responsiveness and memory use.

On Linux 64bit with Maple 18.00 and using your original Document I saw sluggish response while editing, and even crashed the GUI a few times while trying to edit the 2D Math. On my console I got repeated java messages about the jvm running out of heap space and its GC failing.

@Carl Love There are two processes consuming memory -- kernel (mserver) and GUI (java).

The kernel takes a few hundred MB, and that might be reduced by using the parameters[omega] option of dsolve/numeric. (I am not sure how easy it might be to also try and replace some of those piecewises with events...)

I am also seeing the GUI java process taking 550 MB or resident memory (on 64bit Linux). The resident memory goes up further if I Close and re-Open the Document in the same GUI session. It got sluggish just editing the 2D Math of the DE system. It may be that moving that to a Code Edit region could help there.

If the problem occurs even when you suppress all output then it might not be an issue with the interface.

How about uploading a worksheet that demonstrates the problem?

acer

@Andriy Another way to explain the difference is that for f:=k->k^2 the call f(k) will return an expression. In the case of f:=k->fsolve(x^2+k*x-1=0,x)[1] it so happens that f(k) generates an error. But in other examples f(k) could well return something unintended for unassigned symbolic argument k.

This is a FAQ. Since plot has Maple's usual evaluation rules the call plot(f(k),k=0..1) will evaluate its first argument f(k) and pass the result along to the plot procedure. In situations like you had, where f is not well prepared to handle an unassigned symbolic argument like k it is necessary to avoid this so-called premature evaluation.

One way to handle it is to delay the evaluation of f(k) as first argument to plot, as mentioned earlier.

plot( 'f'(k), k=0..1 );

# or plot( 'f(k)', k=0..1 ) if k is itself some function call you don't want evaluated

Another way is to use the operator form calling-sequence of plot, as mentioned earlier.

plot( f, 0..1 );

Yet another way is to construct f instead as a procedure which returns unevaluated for nonnumeric argument.

f := proc(k)
  if not type(k, numeric) then
    return 'procname'(args);
  end if;
  fsolve(x^2 + k*x = 0, x)[1];
end proc:

f(k);  # note f now returns unevaluated for nonnumeric argument

                                     f(k)

plot( f(k), k=0..1 );

This issue is not restricted to just plot. There is also an error guide page about it (keyed upon another common error message from such situations.

It is also possible to use unapply to turn an expression into a procedure that returns unevaluated for nonumeric argument(s). Eg,

f := unapply( 'fsolve(x^2 + k*x = 0, x)[1]', k, numeric ):

f(k);                                               
                                     f(k)

f(1.5);                                             
                                 -1.500000000

plot( f(k), k=0..1 );

It may be of interest to some that Mathematica users often encounter the issue. One can do a web search for Mathematica and NumericQ to get a feel for that.

@mapleq2013 Carl's responses above are good advice. I would agree that assigning procedures (or operators) to names with the syntax (allowed in 2D Math) of,

source(t):=sin(0.1* t) 

is the wrong road to take.

I would also say that trying,

plot(f(t), a..b);

is just plain wrong here. For an operator/procedure f then (even if f(t) does return unevaluated for symbolic t) the thing f(t) is a function call. So that unfortunate and invalid plotting attempt is classic syntactic mismatch, halfway between the expression calling sequence and the operator calling sequence. It should instead be either plot(f(t), t=a..b) or plot(f, a..b).

As far as differentiating your resulting procedure f1 you have a few choices. Since f1 is a procedure you can use the functional differentiation D(f1). Of course you won't get an exact symbolic formula from that, because f1 is purely numeric and there is no symbolic formula around to differentiate. But you can get Maple to do numeric differentation at a numeric input point, eg. evalf(D(f1)(4)) which will internally compute using fdiff a numeric finite differencing mechanism. So you don't have to reinvent that particular wheel.

If you use the search tools for this site then you should be able to find several old threads about higher derivatives and integrals of the solution procedures coming out of dsolve/numeric. In essence, apart from using evalf(Int(...)) or evalf(D(..)(..)) you can augment your original DE system with extra dependent variables and/or higher derivative terms. The leads to dsolve/numeric returning extra procedures which compute just what you want. Of course the numeric solving depends on the solving of the other dependent variables/quantities, sure.

In a somewhat related way, you can also use dsolve/numeric and its events options rather than do rootfinding with, say fsolve in order to compute the particular numeric value of independent variable t so as to match some specific value. This is a bit more effort to set up.

@eclark 

I think that it would be useful if Style sheets could also handle (save & re-use) the Markers shown in View->Show/Hide Contents drop-menu, as well as custom Header and Footer details.

@Carl Love member is a static export of a Group object G, which gets used instead of :-member when one calls member(g,G), etc.

with(GroupTheory):

G:=DihedralGroup(20);

                                 G := D[20]
exports(G,static);

     Degree, Supergroup, Labels, IsFinite, PermutationRepresentation, IsRegular, 
     numelems, Subgroup, Operations, member, `in`, GroupModule, HasProperty, 
     GetProperty, SetProperty

G:-member;

                   PermutationGroupImplementation:-member

eval(G:-member);

     proc(expr, self)
     local pg;
       if expr = [] then
         undefined
       elif type(expr, {'Perm', 'permlist'}) then
         thisproc(convert(expr, 'disjcyc'), self)
       elif type(expr, 'list'('list'('posint'))) then
         pg := :-permgroup(:-Degree(self), 
         map(convert, {op}(:-Generators(self)), ':-disjcyc'));
         if :-group:-groupmember(expr, pg) then undefined else 0 end if;
       else
         0
       end if;
     end proc;

@Carl Love What about `equals` in the custom group definition?  (...as it was on math.stackexchange.com)

restart:

with(GroupTheory):

G:=DihedralGroup(20):

H:=Group({[[1,6,11,16],[2,7,12,17],[3,8,13,18],
           [4,9,14,19],[5,10,15,20]]}):

IsSubgroup(H,G);

                              true

FactorGroup:= proc(G::GroupTheory:-Group,
                   N::satisfies(N-> GroupTheory:-IsNormal(N,G)))
# Returns the group G/N.
uses GT= GroupTheory;
   GT:-CustomGroup(
      GT:-LeftCosets(N,G),
      multiply = ((g1,g2)->
                  GT:-LeftCoset(Representative(g1)
                                . Representative(g2), N)),
      inverse = (g->
                 GT:-LeftCoset(Representative(g)^(-1), N)),
      equals = ((g1,g2) ->
                member( Representative(g1)
                        . Representative(g2)^(-1), N))
                  )
end proc:

F := FactorGroup(G,H):

GroupOrder(F);

                               10

@misvanrooij You could convert each Vector to list, and then form a list of lists as Markiyan has shown.

But you could also create an m-by-3 Matrix, where each Vector forms a row. Ie, (using a part of Carl's code)

plots:-surfdata(`<|>`(v||(1..6), w||(1..3), x1, x2, y1)^%T,
                labels = ["L/h", "n", "kg/m"],axes=normal);

or,

plots:-surfdata(<v1|v2|v3|v4|v5|v6|w1|w2|w3|x1|x2|y1>^%T,
                labels = ["L/h", "n", "kg/m"],axes=normal);

(You may already know that you could supply style=patchnogrid as an additonal plot3d option.)

Have you tried it with HTTPS using the URL package of Maple 18?

acer

This might of interest (esp. if you like to watch your machine grind), even with limited scope.

acer

Are you sure about eq2?

acer

Alec's code appeared earlier in a worksheet by John Oprea (appeared in the Application Center in 2001, but may date from around 1996 and appears to have been created in MapleV R4). They both used a wrapping call to evalf when initializing local `c` in the scalar iterating procedure. Alec used plots[densityplot] (more attractive) while John used plot3d (faster).

And John's code is very close to that which appeared in the Maple V -- Programming Guide (p.231 of my 1996 edition). That manual's example used exponent 4 rather than 2, producing a kind of "Mandelbroid" if I may use the term. Alexander Walz cites [1, 2] John's revision as early as 1996.

One drawback to using hue is that its shading cycles back, with both lower and upper extremes shaded red. But with a high maximal iteration limit most inputs end up relatively near the extremes. So a lot of the plot is red, and it's difficult to distinguish visually which points escaped early and which did not escape at all.

The code variants mentioned use different accounting schemes for escape, in terms of initial and maximal attained iteration counts. I actually like a scheme where the count starts at 1 but for which unattained escape is recorded as value 0, since that information can be used to say mask out pixel intensity.

It's interesting to me that when using (plot3d or) plots[densityplot] and its restricttoranges=true option the purely real axis is more closely utilized if the grid has an odd number of points in the imaginary (y) direction. This effect can show more clearly if the maximal iteration limit is not high (30, say).

The output=layer1 option to Maple 18's Fractals:-EscapeTime:-Mandelbrot produces output where nonescape is recorded as value 0. This leads to a similar hue shading as where nonescape is recorded using the maximal iteration value (or 1 higher), because of the mentioned hue shading wrap-around with both extremes showing as red.

There is a mistake in that Library routine, where module local procedure Fractals:-EscapeTime:-sourceMandelbrot fails to check and record a possibly early escape at iteration 1. It starts checking at 2.

One thing that routine does have is additional easy checks against the input point being in either the largest or secondary bulbs of nonescaping points. So here is a density plot variant that does those checks and runs a bit faster for the interesting ranges like in the discussed code variants. I haven't tried to optimize the code's subexpressions, but for this code below on my machine the cross-over for speed is about 75 as the maximal iteration limit. More iterations than that and the easy checks pay off, while for fewer iterations their overhead is a penalty.

restart:

Mandelfun2 := proc(a, b, N)
local z1, z2, z1s, z2s, i, t, temp;
 z1 := a; z2 := b;
 z1s := z1^2; z2s := z2^2;
 if (z1+1.0)^2+z2s < .625e-1 then
    return N+1;
 end if;
 t := (z1-.25)^2+z2s;
 if (t+z1-.25)*t < .25*z2s then
    return N+1;
 end if;
 for i to N while z1s+z2s < 4 do
   temp := z1s - z2s + a;
   z2 := 2*z1*z2 + b; z1 := temp;
   z1s := z1^2; z2s := z2^2;
 end do;
 i;
end proc:

Mandelfun := proc(x,y,N)
local n,c,z;
     c:= x+I*y;
     z:= 0;
     for n to N while abs(z) < 2 do
          z:= z^2+c
     end do;
     n
end proc:

n := 250:

CodeTools:-Usage(
   plots:-densityplot(
        'Mandelfun2'(x,y,75), x=-2.0..0.7, y=-1.35..1.35, grid=[n,n+1],
        colorstyle= HUE, restricttoranges=true,
        axes= boxed, scaling= constrained, 
        style= patchnogrid,
        labels= [Re,Im]) ):
memory used=1.39MiB, alloc change=0 bytes, cpu time=499.00ms, real time=497.00ms, gc time=0ns

CodeTools:-Usage(
   plots:-densityplot(
        'Mandelfun'(x,y,75), x=-2.0..0.7, y=-1.35..1.35, grid=[n,n+1],
        colorstyle= HUE, restricttoranges=true,
        axes= boxed, scaling= constrained, 
        style= patchnogrid,
        labels= [Re,Im]) ):
memory used=1.02MiB, alloc change=0 bytes, cpu time=500.00ms, real time=499.00ms, gc time=0ns

In Maple 18 the revised plots:-surfdata command can be used to easily turn a single layer black & white image Array into a hue shaded density plot. Here's a simple procedure that calls the Fractals:-EscapeTime:-Mandelbrot command as then follows that up with such a conversion. The timings seemed to improve in subsequent runs in the same GUI session, even after restart.

restart:

# Initialize the Compiler and ModuleLoad,
# incurring a one-time hit after each restart which
# may reasonably be excluded from timing results
# if we expect to convert more than once.
with(Fractals:-EscapeTime):

MandelDens:=proc(N::posint,
                 cll::complex(numeric),
                 cur::complex(numeric),
                 {cutoff::posint:=4,
                  iterationlimit::posint:=100})
   local M;
   M := Fractals:-EscapeTime:-Mandelbrot(
          N, cll, cur,
          ':-cutoff'=cutoff,
          ':-iterationlimit'=iterationlimit,
          ':-output'=':-layer1');
   rtable_options(M,':-subtype'=Matrix);
   LinearAlgebra:-Transpose(M,':-inplace');
   rtable_options(M,':-subtype'=Array);
   plots:-surfdata(':-color'=':-COLOR'(':-HUE',M),
                   Re(cll)..Re(cur),Im(cll)..Im(cur),
                   ':-dimension'=2,
                   ':-style'=':-patchnogrid',
                   ':-scaling'=':-constrained',
                   ':-axes'=':-box', _rest);
end proc:

n := 251:

CodeTools:-Usage(
  MandelDens(n, -2.0-1.35*I, 0.7+1.35*I,
             iterationlimit=75, labels=[Re,Im]) ):
memory used=3.24MiB, alloc change=17.73MiB, cpu time=63.00ms, real time=30.00ms, gc time=0ns

A more general purpose image to densityplot conversion utility would be useful. It might handle HUE, HSV, or RGB shadings. I'm thinking of Classic GUI users who cannot use ImageTools:-Embed, and for whom densityplots behave better. And another utility for densityplot to image conversion would also be useful. There I'm thinking of Standard GUI users, where images may stress the interface less. Perhaps more on that later.