I found the answer:

export exportCsvMatrix := proc(m:: Or(Matrix, list(Matrix)), fileName:: string)

ExportMatrix(fileName, m, target=csv):

end:

The documentation for this is here.

Honestly, I found it confusing because it appears that I could also use [Matrix] instead of list(Matrix) from that documentation but it doesn't work.

@Carl Love 

Interesting, if using strings is better then I will use them from now on.

You are right, there is no need to export these variables. In fact, the only reason they were declared as local variables is because the procedure that I showed is one that I refactored. That is I didn't write it from scratch. I erased the use of the variables, but forgot to remove the declarations.

@acer 

acer to the rescue. You solved it. That was the problem.

Finally, let me just say that everything I am trying to do with tables above I can do with lists and it works. That is, instead of having tables firstChevrons and chevrons that have as keys the nicely readable chevron2A, chevron2B, ... and as values Arrays of size 50 x 3, I can just use lists of these Arrays.

I just find it less readable and maintainable for the future.

So, the algorithm I am using above is correct. This is all a question of Maple's table.

Here is yet another perspective on what is happening.

print(chevrons[1]) gives

Now I would like to access the value at key chevron2A.

print(chevrons[1][chevron2A]) gives

I've tried countless times to access the 50 x 3 Array that this is supposed to be but I always get this name with subscript.

Note that

@Carl Love @acer

Now, I've decided to write this second reply to show what my procedure actually does. In the explanation I gave above, I simply returned [chevrons, firstChevrons]. What I actually do is as follows

Again, I assign to a variable chevrons the result of calling Grid:-Map on computeChevrons. Thus, I get a list of tables, each table with keys like chevron2A, chevron2B, etc.

At this point, I run a third parallelization.

Let me try to explain what each run of this parallelization does. One single run is for, say, chevron2A, and we have

firstChevrons[chevron2A] is a 50 x 3 Array.

chevrons[1][chevron2A] is a 50 x 3 Array.

chevrons[2][chevron2A] is a 50 x 3 Array.

chevrons[3][chevron2A] is a 50 x 3 Array.

(...)

chevrons[5][chevron2A] is a 50 x 3 Array.

The procedure computeConcatenatedChevron should simply take each one of these and stack them on top of each other to form a huge array of size 300 x 3.

Each run of the parallelization is one call to this procedure. (Thus it is called with chevron2A, then chevron2B, and so on. 

The result of the call to Grid:-Map on line 175 is thus a list containing eight Arrays of 300 x 3.

However, the code above fails on any single run and the problem is that there is an error on line 169.

Here is the output of the procedure

As you can see the print statements on lines 162 and 166 do not work as I would expect.

I would expect them to produce 50 x 3 Arrays but all I see are names.

Note that I am trying to print out pieces of chevrons and firstChevrons. In the first post above, where I simply returned these two things in a list and tried to access them in a worksheet I had issues accessing firstChevrons.

Now, I am trying to access them inside of a procedure that is inside my original procedure, and the issue I have is the opposite: I can't seem to access chevrons.

Here are a few snippets from the commented out DEBUG line when I uncomment it

What does Array(1..2, [1,5]) mean?

And here is what happens if I put a debug statement inside of computeConcatenaedChevron

In the debugging session above, I am reproducing the error seen in the pink text further up in this post by trying to concatenate firstChevrons[chevron2A] and chevrons[1][chevron2B]. 

Each of these should be 50 x 3, however, the operation is not working because chevrons[1][chevron2B] is not returning an Array, it is returning an indexed type, which I am unfamiliar with and not sure why arises.

@acer 

I tried last night to create a small example file that reproduces my issue. I was not able to.

I am going to try to convey what my .mpl file does with screenshots of the code.

I have a procedure that takes lots of parameters and declares many local variables

As you can see in the next screenshot, the first thing that happens is calling a procedure called solveExchangeIso2Rabi1PhaseDrive which essentially solves a system of differential equations, does a few extra computations, and returns a list of lists that gets assigned to rabi1.

Then, firstChevrons gets assigned an empty table that is populated by eight different keys each with an Array as a value. The Arrays are constructed based on rabi1 and have size 50 x 3.

firstChevrons will later be returned from this procedure in a list and the problem is how to access the data in it. For now, this is all that this table is.

The next thing is analogous to the first part.

I create a table T1 with keys from 1 to Nwd = 5.

The values are sequences of expressions. Each such sequence is an argument list for another call to solveExchangeIso2Rabi1PhaseDrive.

The calls to this procedure are made using parallelization with Maple's Grid:-Map. There are a total of Nwd=5 parallel runs (in the real use case, the number of runs is much larger), and again, the arguments for each run are provided to Grid:-Map via the table T1.

The return value of the call to Grid:-Map is assigned to rabi2 which is thus a list of lists.

In particular, it is a list with 5 items in it, and each item is the return of solveExchangeIso2Rabi1PhaseDrive (ie another list of lists).

Now we get to the part that is causing issues.

I use Grid:-Map one more time. On line 158, I run the procedure computeChevron a total of Nwd=5 times.

computeChevron should return a table that has exactly the same structure as the table firstChevrons, which if you recall was created way back at the beginning of the procedure and has keys like chevron2A, chevron2B,... and the values are Arrays, as you can see below. In fact, just as firstChevrons created for each of its keys a 50 x 3 Array, so will computeChevron.

Each parallel call to computeChevron depends on the list rabi2 (previously computed) and so I use Grid:-Set to make this list available to each of the parallel nodes (line 156).

This is the first time in this procedure that I have a procedure that is returning a table, and I am using eval.

Thus, the variable chevrons which gets the return of the call to Grid:-Map is a list of tables (each table has eight keys such as chevron2A, chevron2B,..., etc and as values for each is a 50 x 3 Array).

For the purposes of this question, I've decided to simply return at this point the list [firstChevrons, chevrons], as you can see below on line 162. (The actual procedure does one extra thing after this, which I explain in my next post, but let me go in steps here to not overcomplicate).

Note that I've also tried returning [chevrons, eval(firstChevrons)] and the result is the same (as will be shown further below).

When I execute this code in a worksheet, I would expect to have a list with two items in it, where the first element is a list of tables (chevrons) and the second element is a table (firstChevrons).

Each table (whether in the list of tables that is the first element, or the table that is the secod element) has keys like chevron2A, chevron2B, etc and as values has Arrays.

Here is an example call of the procedure:

Consider the results below

when I try to access r[2] all I get is the name firstChevrons. I expected to have a table. Indeed, it does seem to be a table, using whattype. But then why can't I access r[2][chevron2A], and why is the type of this indexed instead of Array?

When I access r[1], I get the expected result: a list (of tables).

When I access r[1][1] I get a table (namely, the result of one call to computeChevron).

And when I access r[1][1][chevron2A] I get an Array, as expected.

So the first issue is: why can't I access the data in firstChevrons, ie r[2]?

@acer I will read about this inert operator. I noticed that if we try to solve for R instead of T, ie solve(expr, R), we get no result.

@Joe Riel omg ok I should probably stop studying it's been too many hours.

@dharr This is a useful command, just not for the issue being asked about. 

To repeat the issue: you create an .mpl file and save it and in the code in this file you want to be able to access the absolute location of the file itself (no matter where the file is run from, whether in a saved worksheet, a non-saved worksheet, or Maple command line mode where there isn't a worksheet).

This means that you can open a new worksheet in Maple (not even save it), and from that worksheet you can run the .mpl file and the file will be able to access its own absolute path.

It also means you can just read the .mpl file from Maple command line mode and the file will be able to access its own absolute path.

@PeterTang This was a while ago so I don't remember very precisely but I don't think I found the optimal solution to this problem.

Luckily, I was working with only one other person, so I used absolute paths based on the particular user of the file I was running. Not ideal at all, but it worked.

And to repeat the issue: you create an .mpl file and in this file you want to be able to access the absolute location of the file itself. This means that you can open a new worksheet in Maple (not even save it), and from that worksheet you can run the .mpl file and the file will be able to access its own absolute path.

@acer Using the "grid" option (for example, grid=[1000,1000]) does not produce a vastly superior result and manipulating the plot becomes super slow on my computer.

The plot you generated looks good, but the required command to achieve this is not user friendly. 

Do any of the alternative ways involve a more automated process of achieving a plot similar to the one you generated above with the laborious process of splitting up the surface?

We know about the ridge because of manual calculations. What if we did not do any calculations and wished to see an accurate depiction of the graph of a function?

Ie, is the blue output some kind of default output?

@Carl Love 

libname returns the correct result, as does with(MyPackage).

Things seem to work now. One source if initial confusion was the following:

- the prompt is ">"

- if you type in a command and don't put a semicolon, all you get is another prompt below but no indication that Maple is waiting for you to complete the command with a semicolon.

- thus, if in the new prompt you think "what happened?" and try to type in a new command you will get an error, and it will snowball from there.

One question I have about using the console is that it prints out memory used, alloc, and time.

Where can I find more information about what this information is telling me exactly?

When I search the help files for "command line mode" I don't see a dedicated page for that mode (I'd like to know, for example, how to abort a running command)

@nm I save data to files when I have results that I know will be useful later.

Sometimes I am working on something, and would like to make some small change to a procedure. I have a big matrix I would like this procedure to operate on after changing the procedure.

Yes I could save the matrix and read it.

But I imagine there is a way to forget what was imported so I can import it again.