It's clear from your Questions picture, and the attachment's filename, that you are trying to Read an image stored in your Maple workbook.

With a short edit to your this URI the following zipped workbook succeeds for me using Maple 2023.1.

TestTrans_ac.zip

The following is as much as I believe can be recovered here. (Three input equations were corrupted; somewhat near the beginning.)

Hjemmeopgave_7_igen_ac.zip

I suggest that you upgrade to Maple 2023, if available to you. It seems to have fewer incidences of this problem.

You can use your desired ranges for x and t in the calls to contourplot, along with scaling by Mx and N respectively. And you can also use the desired ranges directly in the (density-plot) PLOT call.

I also made a few changes for (IMO) a better look, such as getting rid of the minus sign on "-0.000", increasing the contourplot grid, etc.

Also, one way to get a nicer final export is to increase the plot size, since you can then scale down using a good external image processing program. I also made the contours thinner using subs, since IIRC Maple 2015's contourplot didn't allow that thickness (thinner than thickness=0 !) 

This direct approach can be more efficient than using plottools:-transform to re-scale/shift the original result (after the fact).

I think that it's often easier to manage in the long run if your calls/functions are properly scaled up front, instead of fudging the tickmarks later on. (I choose forced tickmarks only as last resort, usually. It doesn't work with all later transformations, as one reason.)

By the way, I suggest exporting the plot from Maple in .PNG format. Well, almost anything except .JPG, for which the results are generally poor.

If you want advice about exporting the data then you should describe the required format in explicit and adequate detail. Merely mentioning a product's name, like "tecplot", is not adequate.

ps. Quite a bit of this code looks like bits that I'd written. Is that right? I'm curious now; where did you get it from?

Since you gave a followup example (elsewhere),
 

Download jestrup1.mw

This is as much as I could recover. I think it is most of it.

I left all the sections unexpanded.

prac_exam_ece4179_acc.mw

There may be a missing equation just after the line with "evaluate for the given points" in section 1, and another just after "This decision boundary will realize" in section 4.

I notice that you were using Maple 2022.2.  I suggest upgrading to Maple 2023 if available to you; it seems to have fewer occurences of this problem.

Your attempts at forming a Matrix try to use Ans[k], but your loop simply assigns (repeatedly) to just Ans. It looks like you meant to assign to Ans[j] and Ans1[j] in the loop.

In your systems of equations you have terms like Theta(eta,t), but in your attempts at forming a Matrix you have the arguments of Theta reversed, like Theta(0.5,eta). Did you mean Theta(eta,0.5) instead? The same happens for the other functions.

When you write,
   eval(diff(Theta(0.5,eta),eta),Ans[k])(0)
are you wanting instead to take from Ans[k] the derivative of Theta(eta,0.5) w.r.t. eta, and then evaluate that very close to eta=0? If so then this is essentially the same as your query in your previous Question. You are mistakenly using technique appropriate for a result from dsolve(...,numeric) rather than from pdsolve(...,numeric). Have a look at this: error_in_table_value_ac.mw

You could avoid duplication of conputation by computing the Matrix entries (involving the other terms that I omitted) in a loop.

Are you trying to get something like the following?

Download Qop2_ac.mw

Those are actually equations, and you could use or access their lhs and rhs separately.

Note that formation of the string may not be strictly necessary, compared with simply calling the operation on the arguments directly to get the inert expression. (But there seemed to be a few corner cases, where using the inert operators with prefix form helped.) Did you really need the string representation, using infix form, or is the above result from InertForm:-Display enough?

I notice that you had B set up to avoid being A. Is that because you didn't want A-B to produce 0? If so perhaps you'd also want to avoid A+B=0 when B=-A? And perhaps you'd prefer neither A nor B to be -1 or 1 when multiplying?  Qop2_ac2.mw

It sounds as if your preferences were not migrated to your new installation. (There's usually a dialogue that asks about that, during installation.)

You can set the preference by using the main menubar,

   Tools->Options->Display

and then set the drop-menu box "Input display" to "Maple Notation".  Then press the "Apply Globally" button to set it as default.

@zenterix You could use the terser,

   m::{Matrix,list(Matrix)}

instead of using `Or` in the type specification.

The LinearSolve command in the LinearAlgebra package can handle this.

Let's write out the coefficients (of x) for your polynomials, as column Vectors. Form a Matrix of the ones from S.

Then call LinearSolve.

Download LS_ex2.mw

note: You wrote, "corresponding linear system", which indicates that you recognize that this problem can be expressed as a linear system. Using LinearSolve might then not be unexpected. Reformulating the polynomial relationships as a linear system, programmatically, might then be useful for you.

Notice that you were using the %d format code for this item, in printf. That's for integers. But you mentioned wanting them as 1.0,1.2,...2.0, which are floats. So you could use the %2.1f format, in printf.

Now, you already have the float values you mentioned wanting, available directly via t[i] .

If you didn't already have them using t[i] then you could also get n values evenly spaced between a and b by using the formula,
   a + (b-a)*(i-1)/(n-1)
which for this example would be,
   1 + (2-1)*(i-1)/(n-1)
which can be shortened to,
   1 + (i-1)/(n-1)

Download frm.mw

For future programming, you might also care to think about how the following work. These kinds of construction occur pretty often in programming. It can be a useful thing to get familiar with.

<seq(1.0..2.0,0.2)>;
n:=6:
<seq(1.0..2.0,numelems=n)>;
<seq(1.0..2.0,(2-1)/(n-1))>;
<seq(1.0+(i-1)/(n-1),i=1..n)>;
Vector(n,i->1.0+(i-1)/(n-1));

You are using module locals like Chevron2A as the keys of some of your tables.

That will prevent you from accessing table entries if you subsequently try and use (say) the global names like Chevron2A as the key, trying that access outside the module.

You could, instead, use global name :-Chevron2A as the table key when creating the entry. Then you can use that as key, for access elsewhere. [edit] I would prefer this, over a module export. Using strings is also a good possibility, as Carl has mentioned after I posted this Answer. If you use the global name as key then you ought to quote it (and protect from evaluation), in case it is also assigned some value, eg. ':-Chevon2A'.

Or you could instead declare Chevron2A as an export of the module. Then, later, you could use it as key in its long-form (fully qualified name),  calculateblahcubitblah:-Chevron2A. Or you could make the module a package, so after doing with(calculateblahcubitblah) its exports become the new bindings for reference via the short-form Chevron2A. [edit] This is not my favorite choice, and I can only think of convoluted scenarios in which it'd provide extra contextual usefulness.

The code snippets that you showed above indicate that this problem that I've described occurs in your code. I cannot tell whether you also have other issues, eg. last-name-eval of tables assigned to names. I suggest using eval(nameoftable) when putting into lists or if returning them straight from procedures.

Some of your procedures will throw an error for certains ranges of inputs alpha and delta.

The plots:-inequal command appears to get slightly confused by that situation, and in consequence can misrepresent the feasible region..

Below and use short wrappers for those three procedures, so that when failing to produce a result (throwing an error) they instead return either a large positive or large negative value. Those can be used appropriately for the inequality tests, so that a more clear/robust representation of the feasible region is attained.

Double check, for correctness.

Download ConflcitInequal_acc.mw

These results for n=2..15 are computed exactly.

Download hg_ex.mw

@RaySierra 

Your worksheet's code is missing `+` as the first argument passed to Continue.

If I simply add that missing argument then your worksheet runs ok in my Maple 2019.2.