proposition.mw

You may be wondering why I did not plot arrows as you requested?
Here is my reply arrows.mw

Unless you make your own arrows by hand (which can be a waste of time), it is likely that neither plots nor plottools will give you satisfactory results (at least they don't for me)

You ask for a "mixture" of gaussian random variables and compute their sum instead, which is COMPLETELY DIFFERENT.

Which is why equation (5) confuses you.
Then @Carl Love probably confused by your relation (4) told you you were computed a sum and Maple  equation (5) was right.

You seemed to agree with  @Carl Love when replying him and said "Mathematica formula for the variance is Var(Z)=w*a^2+(1-w)*b^2": in fact this formula is correct iif the expectations of both random variables are equal. and fron if not.
So it would be a mistake to take ir at face value.

Finally , for some reason I did not investigate deeply enough, the first part of @janhardo worksheet provide a wrong result (curiously identical to the so-called MMA's) while the second part where it defines mixtureDist is therefore incorrect.

A simple reasoning proves the so-called MMA result is wrong in case the tandom variable have different expectations:

Consider 2 gaussian random variables with respective means -A and +A and common standard deviations s << A.
Then a 50% mixture of both of themleads to a meand equal to 0 and a variance of the order than A^2.
As the formula  only accounts on standard deviation and not of expactions it is obviously false

So I'm sorry to say that if you really want to compute mixtures properties, all the answers that have been given here contain, are wrong in a general sense, largely due to the confusion you initiated between the weighted sum and the mixture  of random  variables.

See here the correct answer:

Download Mixture_versus_Sum.mw

The correct mathematical form of an IC at infinity is limit(y(x), x=+oo) = 0 and the fact you can't write the IC this way in Maple does not authorize you to write y(+oo) = 0 instead.

The correct way to proceed is:

Download Limits.mw

Your "However, how I can create a cumulative histogram with corresponding polygon employing this same information?" question is unclear.
What do you mean by cumulative histogram?

Do you mean "an histogram of the cumulated data"... that is a collection of rectangles which would approximate the empirical cumulative distribution function (note I do not use the word "histogram" for this collection is not an histogram)?

If I interpret correctly what you seem to have in mind, here it is.
If I'm wrong, please clarify your question.

Done with Maple 2015 (I verified that Maple 18 contains all the features for file 1 to work with this version).

Cumulative_Histogram_with_Polygon_Line__Way_1.mw

In this Cumulative_Histogram_with_Polygon_Line_Way_2.mw worksheet the histogram is buit bars-by-bars using plottools:-rectangle instead of Statistics:-Histogram.
This avoids constructing the WeightedX list, which might be useful when Dados is a large sample, and offers more flexibility to produce smarter histigrams.

Illustration (note that the tickmarks could hve been displayed this way using the previous wotksheet).

So make your choice.

NOTE: the deprecated stats package (Maple 2015 and beyond) contained a useful feature enabling to draw histograms of weighted: Cumulative_Histogram_with_Polygon_Line__Way_1_stats_pckg.mw

As you use these two terms in the same question I understand you mean "envelope in the signalprocessing sense".

There exists a simple analogic device named Envelope Detector which, I quote Wikipedia,  "takes a (relatively) high-frequency signal as input and outputs the envelope of the original signal".

It is quite easy to draw the differential equation which models the input-output relation for this device (in the attached file R_d represents the resistance named R in the Wiki article, C_d the capacitance named C in this article and r_d is an auxiliary resistance left to the diode and which Wiki does not account for).

This auxiliary edo is added to your eqn1 and eqn2 differential equations.
To manage the two "charge" and discharge" stages of the envelope detector device I use a discrete variable GT(t) whose value +1 corresponds to the charge of the cacitance and value -1 to its discharge.
The values (-1 and +1) are controlled by events in the dsolve function.

Because V₂(t) is rapidly oscillating it is necessary to refine the odeplot outputs, which imposes in return to use the dsolve option range. 

File demodulation_toy_problem.mw shows how the envelope detector works. 
The solution depends on the three parameters R_d , C_d and r_d which have to be adjusted. Each choice gives an envelope but some seem more "reasonable" than others, or at least seem to fit more than others a mind image of what an envelope should be.

File demodulation.mw applies this envelope detector to your problem.

You will likely observe a quite large display time (which goes with a large amount of memory used), but this is the price to pay to a fully resolved solution.
Which explains why I did not go up to t=6*T on my memory limited machine.

__________________________________________________________________________________


In those files the 3-parameter model  is a physical one.
A simpler 2-parameter physical model results in setting r_d to some arbitrary value, for instance r_d = 1 (in true envelope detector one has R_d >> r_d ).
One may also think to a 2-parameter model (no longer that physical) whose parameters would be the two time-constants (one for the forward diode and the other for the reverse diode).

With this latter model the time-constant of the forward diode must be small enough for the envelope to follow faithfully the rise of V₂(t).
If, as it seems it is your case, the successive maxima of V₂(t) have increasing values (for t/T >~  0.9), then the time-constant for the reverse diode should be chosen large enough for  the envelope does not present significant decreasing between two consecutive peaks.

__________________________________________________________________________________


Finally,  demodulation.mw solves a 3-ode system but an alternative which could be interesting is to keep solving your initial 2-ode system first, and next dsolve the Envelope(t) ode alone while telling dsolve that V₂(t) is now a known function (see known option and how to use it in dsolve/numeric help page).
This could mimic the post-processing stuff you mentioned.

Nevertheless not that concise as MMA

Download Maple_vs_MMA.mw

Try for instance

limit__FG1 := limit(FG1, epsilon = 0);

    exp(eta[1]) * exp(eta[2]) + exp(eta[1]) + exp(eta[2]) + 1

and have a look to Limit ( help(Limit) )

@C_R 

I was writting a quite detailed comment to your question but an unexpected box failure made me lost all of it.
So for short, because I'm going to bed right now, I send you a code with several rationl fraction fits of your data.
Jut tell me if you are interested in it and I will develop all of this tomorrow.

RationalFractionFit.mw

... and the answer remains the same: How can expect that solve will find the the solution of a non linear system of 17 equations in 8 unknowns?
Unless the rank of this system is 8 (and there is no guarantee solve will even succeed) his is a dead end.
So you will find in the attached file an alternative method which enables finding a solution "in the least squares sense" (something I already told you about a couple of times several months ago).

test-F-p_sand15.mw

As several members already told you the result is unevaluated in some "ancient" Maple versions.

Nevertheless evaluation can be obtained if you observe that the exponent 

2*sqrt(tau^2-1)/(sqrt(tau-1)*sqrt(tau+1))

is equal to 2 if tau > -1 and -2 otherwise and if you use proper simplification assumptions. 
Evaluation.mw

PS: I suppose someone smarter than me could achieve the same result in a simpler way.

try

Sol := unapply(sol, x):
eval(convert(IC, diff), Sol(x0));

Or in a row

eval(convert(IC, diff), unapply(sol, x)(x0))

Download A_way.mw

By the way, why are you so prudish that you refuse to call  this "other software" MMA ?

The  modulus of solnum is the simplest case to deal with.
Given it's theoritical range of variation [0, +oo) the effective range the grid size "captures" can go from 0 to 10⁴ with a [300, 300] grid.

So it is impossible to get a smart representation of the level curves unless you lessen this range of variation. One simple way to do this is to apply the log function (or some surd function) to the expression to plot.
Using a "compressor"  such as log, for instance, introduces extra issues because the quantity to plot must be strictly positive (whichis why I concentrated on |solnum| ).
Note that a "compressor" is a trick which enables to get a smart plot, but the level curves or the colored region do not give a faithful representation.

The main idea to have a good spacing between level curves is to aggregate pieces of |solnum| contourplorts instead of |solnum| ina row.
Examples are provided in the attached file.

To reduce the size of the grids and still get a nice picture I suggest you to account for the z-periodicity of solnum (see the attached file).

At the end you will be able to get something like this by tuning the regularizer (f), the ranges of |solnum| pieces (r1, r2, r3), the contour lists or the coloring.


The plots are removed in the the attached worksheet (size 66 Mb instead)
plot-help_sand15.mw

This is not because Maple is powerfull that not using what  one does by hand is a useless strategy. Which in your case means that replacing k by a complex expression before trying to simplify this latter is a very bad way to proceed.

BTW: A syntax like  f(x) := something is not accepted in Maple 2015 (the version I use), So I used these f := x -> something notations instead. Feel free to modify them in your own code.

More of this there is no need to define Phi(x, t) the way you did because Phi(x, t) = C*Omega(x, t) where C is some constant

Download pdetest2_sand15.mw

After the M, b := ... line insert these to verify what b is:

b;


# So b[3] is not assigned:

b[3];
Error, Vector index out of range

The error comes from you writting

M, b := GenerateMatrix(eqs, [lambda[1], lambda[2]])

Which redefines b as a zero vector of dimension 2: thus  b = <0 | 0> and the b[3] term in M generates an error.

Cure: write instead

M, B := GenerateMatrix(eqs, [lambda[1], lambda[2]])

to keep b unchanged

S_sand15.mw

@nm 

As far as I can remember, exportplot, called from cmaple, has never worked properly for versions 15 through 2021, whether on Windows or Mac OS.

I always used this kind of workaround:

d := currentdir()

# f := cat(d, "/test.png »);  # doesn't work with maple 2015 (driver unknown)

f := cat(d, "/test.jpeg");

p:=plot(x^3, x = -8 .. 8, color = "blue",axis=[gridlines=[10,color="red"]]):

g := seq(plot(y, x=-8..8, color=red), y=[seq](-500..500, 100)), seq(plot([[x, -500], [x, 500]], color=red), x=[seq](-8..8, 2)):

pg := plots:-display(p, g):    

plottools:-exportplot(f, pg);  

Here is the file exported from Cmaple (Max OSX)

Note that the rendering still remains quite bad.