This graph seems generic enough that it's worth generalizing to any size. Thus:

Truss:= proc(n::And(posint, even))
uses GT= GraphTheory;
local
   k, p, 
   B:= k-> seq(k+~p, p= ({-1,0}, {-1,1}, {0,1}, {0,2})),
   T:= GT:-Graph({seq(B(k), k= 2..n-2, 2), n-~{1,0}})
; 
   GT:-SetVertexPositions(T, [seq([[k,1],[k,0]][], k= 1..n/2)]); 
   T
end proc
:   

GraphTheory:-DrawGraph(Truss(8));

Your C program is a top-level 'main' program which interacts directly with the user and doesn't explicitly return any nontrivial value. You need to change that to a function which takes arguments (specifically, at least one Matrix argument) and returns a value (a Matrix) and does NOT interact with the user^[*1]. See the help page ?external_calling. The example mat_mult given on that page is very close to what you need.

[*1] Possibly there is some way that I'm not aware of that the external program can interact with the user while running in Maple, but this would be some unusual and advanced case.

Any rtable (which includes Vectors, Matrices, and Arrays) V can be converted to a sequence simply with seq(V). I think that you're having some confusion about the distinction between sequences and lists (which is, admittedly, a minor and idiosyncratic distinction). If I say

S:= 1, 2, 3;

then S is a sequence with three entries. If I say 

L:= [1, 2, 3];

or

L:= [S];

then L is a list with three entries. The most-important difference (and it may be the only significant difference) between a sequence and a list is that a sequence cannot ordinarily be passed as a single argument to a single procedure parameter (there are a few tricks to get around even this).

So, your n__a is a sequence of Vectors. It can be converted to a list of lists by

[seq]~([n__a]);

As Tom Leslie has pointed out, there is no way to specify the order of set elements. They are stored in a specific (and predictable) order that is convenient for Maple. Thus, it seems that sets aren't at all suitable for your purpose, so I won't discuss them further in this Answer.

Anything that you can do to narrow the search space will help fsolve (this does not apply to solve). In this case, a little bit of plotting should convince you that there is a negative solution. Simply providing that information to fsolve is enough:

params:= {
    k = 1.3806e-23,
    T = 300,
    h__bar = 1.05456e-34,
    L__z = 6e-9,
    m__hhw = 3.862216e-31,
    E__hh0 = 3.012136e-21,
    E__hh1 = 1.185628e-20
}:
p:= k*T*m__hhw*(ln(1+exp(E__fv-E__hh0)/(k*T))+
  ln(1+exp(E__fv-E__hh1)/(k*T)))/(Pi*h__bar^2*L__z) = 0.3e25;

fsolve(eval(p, params), E__fv= -infinity..0);
                          -48.46001884
 

@mehdi jafari There are two completely separate issues involved in the cases that you show where simplify(...) assuming real doesn't return what you think it should. In the first case, you use

simplify(..., sqrt) assuming real

In this case it's the sqrt that's preventing the simplication that you want, and this would still be true even if the the input were a single algebraic expression rather than a Matrix. Instead, change your command to

simplify(...) assuming real

I don't consider the above to be a bug, or even a weakness.

In your second case, you use

simplify(S_NEW(2,2)) assuming real

where S_NEW is a Matrix. Here, you are using the so-called programmer indexing, i.e., you put the indices (2,2) in parentheses rather than square brackets, [2,2]. This case does seem to be a weakness of assuming (it's not a weakness of simplify); however, I recommend that you always index with square brackets unless you specifically know that programmer indexing is required for your operation (such a situation is rare). So, if you change the above to

simplify(S_NEW[2,2]) assuming real

then it'll work.

The command that you're thinking of is IterativeMaps:-Bifurcation. See its help page. However, I am confused by your usage of an equation rather than an expression.

When a worksheet (or document) is viewed as a slideshow (via menu View => Slideshow), its sections become the slides. This means that you need to make each section small enough that it fits on one screen. So, if you need to present a slideshow, it'd be wise to first perfect your edit of the flat (un-sectioned) worksheet, then divide it into sections. Also, the presentation is fixed slides rather than executable code. Generally, when I give a presentation, I prefer to execute key parts of the code directly for my audience. That helps maintain their attention.

This seems to me to be a very weak feature of Maple.

In the following line, you've misspelled indkomst as indomst:

elif 44000 < 0.92*indkomst and indomst <= 44000+fradrag then

Your worksheet begins with the line

restart; ... several with commands ....

But, the restart command should always stand alone in its own execution group. Failure to do so can cause intermittent and irreproducible errors related to the other commands on the same line not being executed.

I cannot test this solution for you because the error is, of course, irreproducible for me.

And, personally, I never rely on the with command to find procedures for me. This is not because I think that there's some bug in with; rather it's because I think that it leads to less-readable code.

Change the line

A:= seq(...)

to

A:= < seq(...) >

This will make A a Vector rather than a sequence. The Export command (like almost all commands) cannot except a sequence as an argument.

Here's an example. Here's two 2x3 matrices:

A:= <1, 2, 3; 4, 5, 6>; 
B:= <a, b, c; d, e, f>;

This command will take the 2nd row of each and combine them into a new 2x3 matrix:

C1:= <A[2,..], B[2,..]>;

This command will take the 2nd row of each and adjoin them side-by-side:

C2:= <A[2,..] | B[2,..]>;

For the first of these combinations it's of course required that the number of columns be the same in A and B. For the second, that's not required.

Regarding your first question---selecting the 3^rd element from each sublist of a list of lists L1---here are three more ways to do it. I find these more intuitive, although there's hardly any difference in efficiency compared to the other Answers.

L1[..,3];
index~(L1, 3);
op~(3, L1);

Experienced Maple users may be surprised that the first of these--which uses Matrix-style indexing--works even if the sublists have different lengths, that is, if L1 cannot be interpreted as a Matrix.

Regarding your third question---sorting a list of lists L3 based on the 3^rd elements---here is a better way, both more intuitive and (slightly) more efficient:

sort(L3, 'key'= (L-> L[3]));

For a very long list, a key sort is more efficient than a sort that uses a comparison function because the key of each entry only needs to be extracted once.

Inside procedure U, you've used the names `U__&eta` and `U__&theta`. But in procedure plug, you've used U__eta and U__theta. These are completely different names to Maple even though they appear the same when prettyprinted.

Have you checked the help page ?index,threadsafe to check whether your code is threadsafe? What you described is common if you try to use procedures that aren't threadsafe with Threads.

Usually it is not necessary to quit Maple entirely, despite what the "lost kernel connection" message on your screen might say. Usually you just need to kill the errant kernel process and close and re-open its assocciated worksheet. If you have multiple worksheets open, doing it this way is much less grief.

By hand (actually, in my head), I isolate the relevant derivative: 

ode:= diff(x(y),y) = a*y^(-6*b-1) - 4*x(y)/y;

Then use dsolve:

dsolve(ode);