@Lennaert van Veen Is there a reason to not make the (free) upgrade to the point-release 2021.2?

Does the problem persist if you close both the left panel (palettes), and the right panel (context-actions)?

Are you using Maple version 2021.0 or the (free upgrades to) versions 2021.1, or 2021.2?

It's good that the errant setting of that environment variable has been identified.

It might even be appropriate if the shell script that launches Maple were itself to set,
    export MKL_INTERFACE_LAYER=LP64
or similar. I'm not sure. I will submit a query. (I don't recommend it, as yet.)

But it's still a mystery why the error message you received indicates the presence of that shared library in your Maple installation's subdirectory. You showed the error message as,

   INTEL MKL ERROR: /home/jet08013/maple2022/bin.X86_64_LINUX/libmkl_gf_lp64.so: undefined symbol: mkl_blas_cdgmm_batch_strided.

But if that shared library isn't actually present in that directory then the message could be expected as,

   INTEL MKL ERROR: /home/jet08013/maple2022/bin.X86_64_LINUX/libmkl_gf_lp64.so: cannot open shared object file: No such file or directory.

Is that shared object library actually present in your Maple's bin.X86_64_LINUX subdirectory? If so, then I wonder how it got there. (I don't think that any of the new Maple 2022 python/jupyter setup adds that on purpose.)

@Iza If the color or align options appear outside of any list of the items then it acts like a default for that call to textplot. But each sublist item can have its own instance of those options.

This explained (briefly, without a later, accompanying example AFAICS) in the following bullet point in the Description section of the Help page for the textplot command:

   The align, color, font and rotation options may be included
   within a text point list, in which case they apply only to that
   particular point.

That makes it act a little differently from some other plotting commands, where multiple items get handled by allowing each option to be given in the form optionname=list.

For example,

Download textplot_ex.mw

@Iza With a correction to the second example, the two end-effects are visually similar.

In the second example you don't need to invoke
  display(plot1);
because plot1 is already the animation. You can show it simply by typing,
  plot1;
or even,
  print(plot1);
The plots:-display command is for merging plots and adding effects. You don't need to invoke it simply to get the result shown. In fact your second example's last line is not correct; if plot1 is already an animation (and, it is) then you'd want to invoke that last line instead as,
  display(plot1, 'insequence');
Otherwise you'll get all the frames shown individually in a GUI Table. But, as mentioned, you don't even need to call display in that last line.

All else being equal, and if the individual animations are not needed separately, then I prefer the second example. Merging separate animations (like the first example) works but sometimes there are "gotchas" and quirks. There's no reason for doing it that way, and I think it is kludgy.

Done right, the two approaches can produce similar visual results. The resulting two final animation structures are not identical. Your first example's final result takes a bit more memory to store. And, as written, your first example consumes more memory since it also has both individual animations stored separately.

@Iza Please see my previous comment's attachment. I think that it demonstrates a basic approach.

I think that trying to use the animate command directly with its animating parameter being the same `a` as in your expressons will be less basic, and considerably more complicated, for you. That is due to using compound plots (ie. plots:-display of curves, text, pointplots, etc). Evaluation rules will require you to utilize right-tick unevaluation quotes (even doubles of those, if you proceed as in another recent Question thread of yours). That is far more tricky and complicated for a newer user than is my approach of using a simple procedure as I did here.

By using a procedure I got rid of all need to protect (by quoting) against premature evaluation. I also got to compute the heights y1,y2 just once, and then reuse them as need in several kinds of plot parts -- that adds legibility/simplicity as well as some minor efficiency.

In contrast to the procedure approach in my answer, the following involves a more complicated and tricky call to the animate command, as well as even more uneval-quoting -- which is error-prone for the newer user. And it also lacks the convenient means of testing just a single frame.

restart;
with(plots):
f1 := x->a*x^2:
f2 := x->a*x^2 + 0.3:
x1,x2 := 1.0, a/2;
y1 := eval(f1(x),[x=x1]);
y2 := eval(f2(x),[x=x2]);

animate(display,
        ['plot'([f1(x),f2(x)], x = -1 .. 1,
                'color' = ["Green","Red"], 'thickness' = 3),
         'pointplot'([[x1,y1],[x2,y2]],
                     'symbolsize'=15, 'color' = ["Green","Red"]),
         'textplot'([[x1, y1, 'sprintf'("f1(1.0)=%.4f",y1)],
                     [x2, y2, 'sprintf'("f2(a/2)=%.4f",y2)]],
                    'align'=[':-below',':-right'])],
        a = 0.2 .. 1.2);

I'll mention another convenience of the procedural approach in my Answer: it makes it very easy to work with Explore as well as plots:-animate. You only have to change,
   plots:-animate(F, [a], a = 0.2 .. 1.2);
to,
   Explore(F(a), a = 0.2 .. 1.2);

But without that procedure F, the followup code (in this very response) needs various edits to change bracketing and remove some quotes, in order to be passed into Explore. Those edits are not so easy for every new user.

@Iza Here is a single frame, without a procedure, using a fixed value A:=0.5 . You can change that value, and get a different frame.

plotting_param_textplot.mw

My point is that using A (in this manner) makes it more organized and thus easer to put into a procedure, and thus more straightforward to animate.

The parameter named A is distinct from the name `a` in your expressions so that it can all be put directly into a procedure.

You are not forced to accept my point of view. To me, your stated task is quite simple; but of course I understand that it might not be simple for everyone. That's fine. And that's why I've tried to make it more organized in terms of how it uses a parameter by which it could be animated. If something isn't easy for you, then more organization can help.

How do you want them "printed"?

Do you want them as legend entries, or in a caption, or in textplots (positioned near x=1?), or...?

Do you want the values only, or like something=value, or...?

Could you please mention all your requirements when you first submit a Question?

@Axel Vogt Very nice.

I am not sure which version would convert the original directly to that MeijerG, but in several versions it suffices to go through GAMMA as an intermediate step.

Download ax_ex.mw

@Iza Your added requirement can be handled similarly to what I showed before.

For example,

f1:=x->a*x^2:
f2:=x->a*x^2+1:

Explore(plot([[eval(f1(x),a=A),x,x=-A .. A],
              [eval(f2(x),a=A),x,x=-A .. A]],
             color=["Red","Green"]),
        parameters = [[A = 0.5 .. 2.0, label=a]]);

If your f1 and f2 are actually as you've given them  then you might just as well assign the expression results of f1(x) and f2(x) to other names and the use those directly with parametric calling sequence of the plot command. This is more efficient because it invokes f1(x) and f2(x) just once, up front, instead of having those same calls be made for each value of the parameter under Explore. Eg,

f1:=x->a*x^2:
f2:=x->a*x^2+1:

expr1:=f1(x):
expr2:=f2(x):

Explore(plot([[expr1,x,x=-a .. a],
              [expr2,x,x=-a .. a]],
             color=["Red","Green"]),
        parameters = [[a = 0.5 .. 2.0]]);

Here is an alternative. It is not necessary for the f1,f2 procedures you gave. But perhaps you actually intend to use some different f1 and f2. In some situations a procedure might not sucessfully accept a mere name like x as its argument. That is, invoking f1(x) might produce an error if x is an unassigned name and not yet an actual numeric value. This alternative can handle such cases, but is slightly less efficient:

f1:=x->a*x^2:
f2:=x->a*x^2+1:

Explore(plot([[subs(a=A,eval(f1)),x->x,-A .. A],
              [subs(a=A,eval(f2)),x->x,-A .. A]],
             color=["Red","Green"]),
        parameters = [[A = 0.5 .. 2.0, label=a]]);

Using those assignments of doubly uneval-quoted plot calls -- like in your ealier attempts -- looks unnecessarily complicated and non-robust, even if it were made to work. I suggest not coding it like that.

In future, could you please mention all your requirements when you first submit a Question?

@Ahmed111 

As you've noticed, removing the assumption that lambda is also purely real seems to require additional adjustments -- in order to get Carl's suggestion of using evalc to produce as nice a result. I don't understand why you are only considering at Carl's Answer.

In my Answer I suggested using expand instead of evalc (under appropriate assumptions. I think that it is an easier way to get some of the cancellations -- including those you seem now to be mentioning. You could thus try working with the following (or adjusting it further, if you can):
  simplification_ac_L.mw

The final result in that worksheet almost looks like it might have an even simpler trigh form -- but perhaps it's a mirage.

I did not load the LinearAlgebra or PDEtools packages because they have nothing to do with this question. Loading packages that you don't need seems like a very poor methodology to me.

I suggest that the next time you ask a question about a simplification you let us know up front which (if any) of the variables have known qualities that might be used as assumptions (eg, x::real, t::real).

@Carl Love Yes, certainly sometimes evalc is worth it, and it can get some nice simplifications. Though, sometimes evalc can incur significant additional cost, and sometimes it can significantly increase the size of the expression. In my experience I find that both scenarios are common.

For the example at hand, posted by the OP, calling just the expand command with the mentioned assumptions makes all the exp calls cancel arithmetically and disappear. That's lightweight, for this example.

Naturally, one can always find examples where one command is more effective, and other examples showing the opposite. As we know, universal rules are scarce. This one example doesn't demonstrate superiority of any approach in general.

ps. I found a concoction for this example where the simplification produced what might be an invalid result. I suspect the culprit might be use of combine.

pps. I sometimes wonder if some people (not you, not Kitonum, etc) utilize evalc as a means of converting exp to trig, but without realizing the implications of the ensuing real assumptions. So I'll mention an alternative for that specific subtask:

evalc(exp(I*x));

         cos(x) + sin(x) I

convert(exp(I*x),trig);

         cos(x) + sin(x) I

@Carl Love Yes, thanks, although I already know that.

I had already edited my Answer's commentary, to state more specifically that calling evalc alone (without additional assumptions) can be incorrect here if the other variables (epsilon1, epsilon2, lambda1) are not purely real-valued.

It is quite possible that Kitonum's result is incorrect, in light of this. That's why I mentioned all this. We don't know if the OP's original input called conjugate on epsilon1, epsilon2, lambda1 because he consider them as complex-valued or because he copy&pasted from some earlier result of his own.

@Carl Love The OP has Maple 18, and the command you show will not do as well as it could (as as well as I suspect you are thinking) for a few reasons:

  - In that version Maple 18 calling simplify doesn't automatically follow up with simplify(...,size).
  - Calling simplify without options turns some terms with conjugate into abs, which then gets in the way of it finding the nicest factoring in that version Maple 18.

In Maple 18, if expr is assigned the result of the subs(...) call, then these produce the result(s) I suspect you have in mind:

simplify(simplify(evalc(expr),trig),size)
  assuming epsilon1::complex, epsilon2::complex, lambda1::complex;

map(simplify,simplify(simplify(evalc(expr),trig),size))
  assuming epsilon1::complex, epsilon2::complex, lambda1::complex;

simplificationCL18mod.mw

It seems quite a bit simpler to just make real assumptions on t,x,lambda (and proceed with the terse code I had shown in my Answer) than it does to call evalc and make complex assumptions on epsilon1,epsilon2, lambda1 and then apply these variants. The Answer I had given gets the same result as these above, with those real assumptions.

@Kitonum He has Maple 18, in which the final result of your worksheet would not be as your Answer shows, inlined.

In that version either of the following edited adjustments of your last command will produce the result you showed.

   simplify(simplify(evalc(A1)), size)

   factor(simplify(evalc(A1)));