@waseem Waseem,

Is the Galerkin FEM the same thing as the variational FEM discussed in the papers by Gupta, et al, that we were discussing in another recent thread? And, if so, was the Matlab code being discussed here provided by them?

To begin with, you have too many initial and boundary conditions. There should be 8, and you have 12. There are several other issues, but I can't even begin to address them until you correct that.

@sand15 So, I suppose that you consider that my painstakingly crafted answers to the very long series of questions that you posed in your worksheet deserves no acknowledgement, let alone thanks or a vote up.

@seppe Please carefully reread my previous answer, because I had already anticipated your most-recent question, and I explicitly answered it.

Please let me know when you find the answer. And if you can't find it, I'll give more details.

@seppe It is true that in the vast majority of cases, "only the value is passed to the procedure", and the procedure never sees the associated name. To change this, you need to do it in the parameter declarations, like this:

NameOf:= proc(t::evaln) convert(t, string) end proc:
or, simpler,
NameOf:= (t::evaln)-> convert(t, 'string'):

If you want to require that t be assigned a particular type of object, such as an Array, you could make that

NameOf:= (t::evaln(Array))-> convert(t, string):

Analogous to the unevaluation quotes, if you don't even care whether there's an associated name, you could do

AsPassed:= (t::uneval)-> convert(t, string):

(It won't always be 100% exactly as passed because things called automatic simplifications will always be done: 1+1 will always be 2, {2,1} will always become {1,2}, etc.)

In all these cases, the assigned value of the expression or name can be obtained inside the procedure as eval(t).

What you said about Diff is completely wrong. You can verify that by

x:= 3:
Diff(f(x,y), x);

You need to show me an example that made you believe what you said so that I can explain to you what's actually happening.

@tomleslie The variable x in the Matlab code is declared as type syms, i.e., symbolic. As far as I see, it's the only such variable. The one diff and the several ints are wrt x.

@Rohith This is yet another bug in Maple's 2D Input. I never use it (I use Maple Input (aka 1D input)), so I didn't know, but it's not surprising. I'm glad that you figured out a workaround. 

I just made a very small change to the most-recent code, so you should download it again. The change will not make any difference with the examples that we've worked on already; it's just in anticipation of the future.

It would help me to write an answer if I knew your perspective on this. Are you:

• a calculus student who wants to learn how to do that limit problem?
• a calculus student who knows how to do that limit problem but is exploring the possibilities of Maple?
• a calculus instructor whose students are learning to do that problem?
• something  else?

I've seen many of these nanofluid-related BVPs because they're one of the most-common sources of questions on MaplePrimes. This one seems overly simplified. Are you sure that you've entered the problem correctly into Maple? The equation f1 implies a nearly trivial relationship between between phi and theta, namely phi(y) = -Nt/Nb*theta(y) + C1*y + C2. Even ignoring the BCs, the pair of ODEs can be symbolically solved by dsolve to very simple elementary functions. It seems unlikely that there would be research-level interest in such simple equations. Are you missing a nonlinear term in f1?

Rouben's argument is solid to me: There is no nontrivial solution to the BVP as posed. That's mathematical fact, not Maple limitation.

@Christopher2222 The idea of partitioning (or dividing) the sector different ways is a purely theoretical exercise, a thought experiment. Any practical answer will be expressed via integration. Yes, there may be different means based on the variable of integration. If the variable of integration is meaningful (such as central angle, arclength, time (if a particle is moving along the ellipse)), then the resulting mean will be meaningful.

@Markiyan Hirnyk Indeed, the OP is also the author of the StackExchange Answer to which you referred.

Leo Brewin: It would be great if you would embed into this MaplePrimes thread a Maple example similar to what you did as a Mathematica example on StackExchange. In the MaplePrimes editor, look on the toolbar for a symbol like <>. That one lets you embed plaintext. And look for the green uparrow. That one lets you upload a PDF or Maple worksheet (and some other file types).

@bliengme 

Both of those options are much better than what you had: They both instantiate t (i.e., replace it with another value) before using solve. Of those two options, I strongly prefer the second, because I prefer to never a make direct assignment to a problem's independent variable (t in this case).

There is nothing special about this value of t, t = 1. You should call it something like t_final (corresponding to Tfinal), and assign its value at the beginning of the worksheet.

@mmcdara Can you explain why your graphs have a cusp at 3*Pi/2? I'd intuitively expect the mean to be a differentiable function of the angle (but I'm not absolutely sure about that).

Continuing where the last post left off:

So, now that you've had a chance to think about last name evaluation, this may already be obvious: If LNE structures are assigned to both A and B (and even if those structures are identical, with the same address), then addressof(A) and addressof(B) will be different, simply because 'A' and 'B' are different. Whereas addressof(eval(A)) and addressof(eval(B)) will reveal information about the stored structures, which may be the same or different (which is the point that Preben made).

LNE is the sole reason for the apparently special effect that eval has on named tables, procedures, and modules (there is no special effect when those structures are unnamed (aka anonymous)). So the role of eval in your initial Question is trivial, and you should edit the title.

What the disassembly of a structure means: Your next set of questions is about diassemble(addressof(A)), etc. For your first example, the returned numbers are

8, 18446744074328626590, 18446744074328154110, 18446744073709551745

As you might guess from its name, disassemble shows the component substructures. The first number, 8, is a key to what type of structure is stored here. The key can be decoded via kernelopts(dagtag= key), In this case, that returns NAME, which makes sense: A is a name (not a table because of LNE). The second number is the address of what's stored in name A, in this case the table. The third number is a pointer (aka address) to the attributes of A (this is an uncommonly used Maple feature (see ?attributes)). The 4th number is a pointer to the string of characters that is literally the name of A, namely "A". If you pointto that last number, you get 65, which is the ASCII byte code for character A. (You cannot experiment with this by copy-and-pasting the above addresses because addresses are session dependent. You'll need to re-execute the relevant addressof commands.)

What about table references? Your next series of issues deals with table references, such as A[1], B[1], A[2]. Unlike tables themselves, table references do not have the LNE property. So, both addressof(A[1]) and addressof(B[1]) are equivalent to addressof("a"). Thus, they are necessarily equal.

If you want information about the table references themselves, then you need to use unevaluation quotes: addressof('A[1]'), etc. If you then disassemble this and look up its dagtag, 10, you'll see that it's a TABLEREF.

I think that I have now provided enough information for you to understand every issue that you raised. If not, or if you have any further questions, let me know.

@sand15 The anomaly with the saved files from your initial Question had nothing to do with tables; however, the anomalies discussed in your most-recently-posted worksheet are specific to tables (and a few other data structures). The relevant phenomenon is called last name evaluation (see ?last_name_eval), and it applies only to tables, procedures, and modules (except modules that are objects). For brevity, I'll call the relevant types LNE.

If a data structure of any non-LNE type is assigned to a name, as in

A:= 7:

then the following relation is false:

addressof(A) = addressof('A'),

the left side being the address of the integer 7 and the right side being the address of the literal name A.

If the 7 in the example is replaced by an LNE-type structure, then the address relation will be true, with both addresses being that of the literal name A. This concept explains many of the anomalies shown in your worksheet.