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.

If you always want Maple to attempt floating-point evaluation then wrap it in a call to the evalf command. 

Eg,

    Do( %Result = evalf( ln(2)/Do(%Text)  )  );

For your particular example you could also simply replace ln(2) with ln(2.0).

Which of these ways you chose depends on how general you want it.

(There are also some cases --likely rare -- where keeping the ln(2) and using evalf might incur less chance of numeric roundoff error. I doubt it will make much difference to you here.)

Part of your question is about whether fsolve will be able to handle the large expression (so large that it won't prettyprint in full).

Are you trying to compute eigenvalues, by doing numeric rootfinding on the characteristic equation?

If so, then why are you not doing a straight eigenvalue computation using the Eigenvalues command (possibly after applying evalf, if the Matrix has no floats or is not yet of type numeric)?

The active lowercase sum command is outright the wrong command for this example (as given). As given, it can attempt a symbolic summation, which is generally not a good idea in the presence of the floating-point number in the exponent.

It would be relevant to see whether one needs both the floating-point exponent as well as sum (not add), to get the crash.

Using float exponents is actually not a great idea more generally. It certainly shouldn't be used as an easy way to get floating-point evaluation. Better would be use of evalf, or perhaps even a float coefficient.

Of course it is some kind of bug if Maple locks up and crashes on the very same example in 2D Input but not 1D plaintext code.(I will submit a bug report.)

You might also try with the right context-panel closed. It might possibly be related.