@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)));

I removed my Answer because I hadn't understood from the OP's initial wording that he wanted a periodic result.

Up vote for Tom.

@mmcdara What you have done is actually no different.

You are simply illustrating that in your Maple 2015 the act of printing Vector A causes a full evaluation of the entries.

Your "trick" to utilize names v||i instead of v[i] does not solve his goal in such later versions. The names in the entries are slightly different, but the behavior in question is the same.

The actual entry stored in A is still the same name.

Download trick_not_2015.mw

In more recent versions of Maple (2018.2 and onwards, say) the printing behaviour changed, and merely printing Vector A still shows the (whichever) unevaluated name.

@Carl Love I was thinking the same, but trying to not be pushy about it.

@Kitonum I have two queries about your Answer:

 -- Do you have suggestions about computing the full range the OP requested, t=0..2*Pi ?

 -- Are you sure about the integrand you used?

@CygnusX1 Did you see the transformer_with_short_CacDS.mw file earlier, in which the running best results can get printed, as DirectSearch runs? It also shows that you force-stopping the computation and still gettting access to the best result's parameter values.

The DirectSearch:-GlobalSearch command has a help page that shows some options for the command. Global optimization is often not easy, especially in the case of several variables (and possible nonlinear objective), and more so if you really need the very best result and not just the best possible within a given number of objective evaluations or time limit.

You could also try rewriting the inner maximization problem to also utilize DirectSearch (instead of the Optimization package and workarounds for it that may slow the objective or prevent it from being evalhf'able). You might be able to get by with your original expression (no frills, even with that abs call). I didn't optimize the inner problem for speed because I didn't know originally that you would be doing that later attempt of global optimization with more variables.

You might also be able add options to DirectSearch so that it did not try to polish results to high accuracy, focusing on attaining coarser results more quickly.