@greenloafer Ahh... the plot thickens, so to speak.
It appears that the amer_approx code calls functions out of the bs program. The way to do this properly in Maple would be by wrapping up all the functions from bs (after conversion to proper Maple syntax) in a module, or even better a package (which is a module with option package specified) and export each function (which we then should call a method). So
bs:=module() option package
export N,phi,... ; # sequence of all the function names in bs
<here come all your functions, one after the other in arbitrary order, just following the template I gave earlier>
Since you are not familiar with Maple I suggest you pre-pend this whole module to your converted amer_approx code and call (execute) bs on the first line. After that you can use all the functions just like having written them without the module construct. The (better) alternative would be to save this as a .mla file and put it into a library and loading it using with(bs); but that involves some trickyness in getting Maple to do this and later find it & I do not recommend this until you have gotten your feet wet in Maple and also debugged the routines. If you expect to use these more often, however, that is what you will eventually want to do.
Just for completeness, there is a more pedestrian alternative: you can put the Maple code into a text file, save it with extension .mpl and then code
This will read and execute the code and thereby define all the functions. Here /path/ is the directory path to the file (in Windows it would be something like C:\...\). You can still make a module and may have to execute that.
Presumably the thesis referenced in the header of amer_approx.txt has explanations how this model works and maybe even test cases.