@FDS 

Hi,

• How can you write normalisatie in one line:

  normalisatie := C__i /~ C__0):
  

  The "~" operator makes the prefixed operator to act element per element (type help(operators,elementwise (~)); here all the elements of C__i are divided by the same constant C__0
   
• Why do you have to use 'copy'?
  I wrote it as a reminder, more to remind myself that there was a problem here that needed to be addressed eventually than from real necessity.
  But writting local gamma__i_min :=Gamma__i_min will do the same thing. So you can indeed remove the 'copy'.

@dharr 

Not my day!

First I didn't read the entire question, which is a bad start.
Next I had written a first reply saying that you were right: there is no documentation about `<,>` nor `<|>` (completing this while saying that `[ ]`and `{ }` seem undocumented too).
And finally I deleted this reply to write this stupid answer.

Time to go bed

@dharr 

Thank you Dharr for having corrected me.

You are right, I should have say "confusing" instead of "conflictual" about the procedure integraal.

You are right too about the loop: in fact I don't like this notation where the initial value of the counter is ommited (I never use it) and I didn't check what it was doing before writting i:=0.

In the for help page there is this example

tot := 0:
for i from 11 by 2 while i < 100 do
   tot := tot + i
end do:
tot;

which I would have written in a more "natural" way 

tot := 0:
for i from 11 to 100 by 2 do
   tot := tot + i
end do:
tot;

I was learnt about for.. do, while..do and repeat..until structures, and in my mind they are distinct structures not to be mixed...but I guess I'm from the old school.

To find it I went to the Maple 2023 programming guide

https://www.maplesoft.com/documentation_center/Maple2023/ProgrammingGuide.pdf,

at page 30:   So simply go to the help page 

help(LinearAlgebra,General,MVshortcut (MVshortcut)); #all but obvious

​​

@C_R 

Thanks C_R, I was petty sure I had seen it before

@Carl Love 

Great!

(I think I've seen this before on this site, but my memory sometimes plays tricks at me).

@maple 

Sorry I messed up, my answer is updated now

@Carl Love 

Thanks Carl for having corrected me.
I edited my answer meanwhile.

@dharr  @acer

Great thanks to both of you for these extremely nice solutions!

I vote up for each of you, of course,  but I'm very embarrassed to choose the best answer.
On one side I prefer the "@acer's catch the limit", which seems more generic to me, while on the other side I find very clever @dharr's earlier nice (as @acer himself says) solution.

@delvin 

Thanks

@delvin 

I was kidding, don't take it at face value.

What I wanted to say is that as soon as you have more equations than unknowns the existence of a solution is hazardous, unless those equations are linked in some way such that their number reduces after simple algebraic transformations.

In the three attach files you will find:

• a simple proof that T1 has solutions and that your original system can be reduced to a system of 2 equations in 2 unknowns (file T1_details.mw , file  T1_details_2.mw proves there exist 4 solutions one can easily obtain by hand)
• a simple proof that T2 doesn't have any solution even if you add d as an unknown.

T1_details.mw  and  T1_details_2.mw

T2_details.mw

I recognize in your question a divided difference approximation of a diffusion equation with diffusion coefficient 1+a*gamma*alpha(x).
Am I right?

If it is so, then your discrete approximation of the diffusion scheme is not consistent

This can easily seen by putting alpha(x) = Constant.
The proof is given at the end of the attached file whose first part is dedicated to the construction of a consistent approximation of the diffusion term

diff(alpha(x)*diff(u(x, t), x), x)

Download Unconsistent_scheme.mw

The discretization of the term diff(u(x, t), t) is not consistent neither: a term of the form u(x[i], t[n+p]), with p=+1 (explicit scheme), p=-1 (fully implicit scheme), or any other value of p, is missing.

Before thinking to build the matrices and vectors you have in mind, I advice you to verify your discretization scheme.

As I can only use Maple 2015 at the moment and many improvements have since been made to pdsolve, I can just give you a simple advice: browse this site https://www.12000.org/my_notes/pde_in_CAS/pde_in_cas.htm to find if Maple (site edited up to Maple 2021) is capable to handle your problem.

I wasn't capable to find a test case corresponding to your problem but, on the other side, I'm not sure this problem is well posed (I have to get back to my old notes to check that).
I seem to remember that the boundary conditions have to be set at both ends of the bar and, even in this case, you do not necesseraly have a well-posed problem.

@delvin 

I use to use only worksheet mode with 1D inputs.
Here is the file written with Maple 2015
Balance_2015.mw

Strangely your reply is not correctly displayed with Safari (see below) as it is with Firefox.
I believe this is the first time I notice this.

The first one is a classical advice to all newbye: download your Maple worksheet by using the green up-arrow in the menu bar.

Given the complexity of your pdes there is no chance at all that you can get a formal solution.
To expect a numerical approximation of the solution you will have to give numerical values to all the sonstants and provide initial and boundary conditions.
Actually, I'm not even sure that Maple can solve numerically this system.

The last advidce: write command lines in separate blocks to understand where the error come from.
If you write the commands in a single block all the errors are displayed stacked at the end of the block.

Take inspiration from this

Download Corrections.mw