If you call the parse command with no options then it does not evaluate its result. And inside your procedure the local ode gets only 1-level evaluation.

You can wrap parse with a call to eval, or you can supply the option statement.

Download parse_example.mw

If that is assigned to the name M then try accessing the entry by indexing, eg.   M[1,1]

Upload and attach your worksheet, if you want to help us to help you.

I got this:

restart;
Digits:=16:
P:=...your long expression... :
newP:=eval(P,[k=0.1,beta=0.2]):
plot(newP,lambda=0.4..0.85);

fsolve(newP,lambda=0.4..0.85,maxsols=4);

   0.4632186949799427, 0.5169368305419582, 0.7781636733300423, 0.8094962147692479

help_rf_ac.mw

Are you saying the your fsolve call already works, and produces results like, say, this:

   SOL1 := fsolve({ODE11, ODE12}, {N, t__2});
                 SOL1 := {N=3, t__2=5.6666}

In that case you can do the following to access the values:

   eval(N, SOL1);
                               3
   eval(t__2,SOL1);
                          5.6666

And you can use those wherever you need the values, or you can assign each to temporary variables, etc.

If your situation is different then please explain in more detail what you need.

Download EXAMPLES_ac.mw

If I understand you, here is one way to contruct it. (I expect that there are slicker ways.)

Download mattrav.mw

Here is one way to treat your example symbolically (exactly).

Download maximize_exact.mw

Is this the kind of thing that you had in mind?

The grey region denotes eq1<eq2, and the red curve denotes eq1=0 and the blue curve denotes eq2=0.

So their linestyle depends on whether the portion lie within the grey region, or not.

You may wish to adjust, as I used strict inequalities (which are also subject to roundoff). So results may vary if where the curves lie right along the border of the grey region. (But it may be "OK", with the curve dashed along the edge of the grey region which is also dashed -- ie. the strict inequality may not hold there.)

I did not both to figure out what value of working precision (Digits) would be fastest while accurate, and so on.

Download eq1eq2.mw

Here's an explanation of what's going wrong. 

The MQ procedure (in source local Studienblatt_1_8) calls UseUnit several time, every time it is called. For example, it calls UseUnit('m') each time it is used. This gets into trouble when a call to a command such as Units:-Simple:-`*` produces a result with a new local name m upon each invocation. (I am going to submit a bug report with the details.)

Your GeneralStartup source attachment calls with(Units), which has the effect of rebinding UseUnit so that its calls in the read source will resolve to Units:-UseUnit. It also has the effect of loading the Units:-Simple package, so that calls to `*` in the parsed (read) MQ source resolve to Units:-Simple:-`*`, etc.

I expect that you want the Units:-Simple effects of combining units. (I suggest utilizing uses Units:-Simple in the procedures like MQ rather than the utilizing with, but the problem would occur either way.)

The easiest and probably best fix would be to only call UseUnit with the same input name once per restart. I'll leave it to you to decide where you'd like to place it, say at the top-level in your Studienblatt_1_8 source, say.

An alternative but crude workaround might be for computation routines (such as your seqMQ, say) to execute combine(...,units) or simplify. I am not sure that would always suffice easily.

Download UseUnit_Simple_oddness.mw

(I'm still looking at revising the procedures to utilize uses instead of relying on the top-level with calls, and to use a parant module locals instead of the declared globals in the procedures.)

Here is the simple move of the three calls to UseUnit outside of the MQ procedure -- now at the top level, inside the Studientblatt_1_8 source.
Koyaanisqatsi_acc.zip

There are other things you could do with this.

Since the height simplifies to just 1 for your example, and 2D densityplot might be another reasonable choice.

(I don't know whether this is your actual problem, or just a toy example to illustrate. If you have a more complicated example then it might be useful to show it.)

Download plot_cmplx.mw

A 1-dimensional Array has no orientation. It is not a row Array. It pretty-prints in a row for convenience, as do lists and a few other structures.

If you want to make it pretty-print vertically then you could cast it to a Vector[column]., or you could extract it with 2 dimensions as,  b[1 .. 2, 1 .. 1].

You could utilize some variant on the following:

try
  a:=ModularSquareRoot(10,11);
  b:=b+1;
catch "":
  c:=c+1;
end try;

A (deprecated), older mechanism is something like this:

a:=traperror(ModularSquareRoot(10,11));
if a<>lasterror then b:=b+1 else c:=c+1 end if;

Here is one way to plot your data.

I am presuming that you know whether your numerical method (which produces the data) makes sense and is accurate in some sense that is acceptable to you.

(I don't know why portions of your worksheet don't inline well on this forum. It looks better in the actual GUI. I used Maple 18 to match the version in which your attachment was last saved.)

Download x_phi_ac.mw

You should use the Grid package to parallelize a long sequence of integration or differential equations computations.

Threads:-Seq requires the computations to be thread-safe, and that is not true for computations that leverage int, limit, dsolve.

But the Grid package will allow each computation to run in wholly separate kernels. (Since many such computations are not "small" or very, very quick then the coarse granularity is less of an overhead penalty.)

If you don't want a floating-point number then don't use evalf here.

But keep in mind that applying the exp command an integer won't result in a "whole number". So for general (eg. exact rational) inputs you might find yourself in the position of your previous Question. Ie. you may have to choose between receiving a single float result or receiving an exp call as answer.

Of course we do not yet know what kinds of input you intend on passing (via the text entry), because you haven't told us.

If your issue is that you would prefer another notation for the floating-point result (eg. 4560.0 instead of .456e4 , etc) then please say so. Or even if you would like the closest (rounded) integer, etc. Please explain precisely what kinds of input and output you want.

This is so similar to your previous question that it is unhelpful and unproductive to post as two separate Question threads,  since it splits the detsils and the answer content. In future please add such close followup examples as Reply/Comment on the original, instead.