@Carl Love The implicitplot, and the whole example, comes from some Help page. The example, and the methodology, is not authored by me. I merely explained some purpose of part of the code (and made a minor tweak for an inefficiency that bothered me too much to ignore).

@Mikey_W I'm going to back up a bit to even simpler examples.

First, an example the doesn't have this "problem".

f := proc(x) x^3 - x + 2; end proc:

When we attempt,

plot(f(a), a=-3..3)

the first thing that happens is that the arguments to the plot command are evaluated, even before the plot routine receives them to work with. That means that the function call f(a) is evaluated, with its own argument being just a, an unassigned name. The result is a^3 - a + 2, and that expression is what the plot command actually receives.

Now let's use a trickier procedure:

f := proc(x)
  if x > 1 then
    x^2 + 1;
  else
    x^3 - x + 2;
  end if;
end proc:

Now the following attempt produces an error.

plot(f(a), a=-3..3);

Error, (in f) cannot determine if this expression is true or false: 1 < a

That happened because this up front evaluation itself failed,

f(a);

Error, (in f) cannot determine if this expression is true or false: 1 < a

This up-front problem with passing such a problematic argument as f(a) to some command is sometimes referred to by the (old, somewhat amusing) term "premature evaluation".

There are several ways to avoid the problem.

One useful way is to utilize a so-called operator form calling sequence of the plot command. Eg,

plot(f, -3..3)

Another way is to delay the up-front evaluation of plot's first argument, by quoting it with single right-ticks (a.k.a. unevaluation quotes):

plot('f(a)', a=-3..3)

I'm not such a fan of that way, because uneval quotes are ephemeral, and you can't always pass around and more generally manipulate such a quoted thing easily -- because any inadvertant evaluation will strip off a layer of such quotes, possibly throwing the error. And people find Maple's quotes confusing. And trickier situations involving layered/nested pairs of such quotes look even more confusing. 

A third way is to set up procedure f itself so that it can handle the case that its own argument is not numeric (ie. when the inequality cannot be tested against an unassigned symbolic name).

f := proc(x)
  if not type(x,numeric) then
    return 'f'(x);
  end if;
  if x > 1 then
    x^2 + 1;
  else
    x^3 - x + 2;
  end if;
end proc:

And now the following call to f returns itself unevaluated,

f(a);

               f(a)

That expression f(a) is now safe to pass around. Any evaluation of it (as it is, literally) will return merely itself. So the following attempt now succeeds.

plot(f(a), a=-3..3)

The situation in your example is slightly more complicated because there are two levels: the problematic procedure h, and the procedure BC2 which happens to invoke h.

The problem and its various possible fixes all involve what's going on (with up front evaluation) with the first argument being passed to implicitplot. How implicitplot then works to compute its results is secondary, and not directly related to this problem.

ps. Sometimes you might see the bailout in such a procedure written as,
   return 'procname'(x);
instead of (this example),
   return 'f'(x);
That's makes for a more convenient way to program; you can edit the name to which you assign your procedure without having to scour through the procedure's own source in order to change such literal references to itself.

I forgot to mention that there is avoidable duplication of effort in the approach, such as duplicate identical calls to h(a,b) inside the BC2 procedure, etc.

You can make such a call once, then assign to a local name, and then access in multiple places in the formula. It's a simple way to speed this up.

restart;
ode := diff(y(x),x,x) + (y(x))^2*diff(y(x),x) + cos(y(x)) = x:
h:=proc(a,b)
  local F,res;
  Digits := 10;
  F:=dsolve({ode,y(0)=a,D(y)(0)=b},y(x),numeric);
  res:=F(1);
  [rhs(res[2]),rhs(res[3])];
end proc:
BC1 := proc(a,b)
  (1 + a)*b - 3*a
end proc:
BC2 := proc(a,b)
  local res;
  res := h(a,b);
  (1 + res[1])*res[2] - 3*res[1] - res[1]^2 + 0.5
end proc:
plots:-implicitplot([(a,b)->BC1(a,b),(a,b)->BC2(a,b)],
                    -5..1, -11..7, color=[black,red],
                    legend=["BC1(a,b)=0","BC2(a,b)=0"],
                    size=[300,300]);

Title? Caption? Legend? Axis labels? Text positioned beside curves?

You should clarify exactly what you mean by "label".

@chri69a9 Unfortunately your zipped attachment is an empty file.

Not only is there no partial Maple content, it is a file of zero bytes.

Could you try uploading your attachments again, possibly zipping them (.zip file)?

@AHSAN Stop assigning to the names k,Q,Br, etc.

Also, your F is an expression and not an operator or procedure, so it makes no sense when you apply that to arguments.

my_try_ac.mw

I suggest that you really try to understand why and how these mistakes were making it go wrong.

@Muhammad Usman You could include or exclude any of the following:
 - the colored density-plot
 - the black contours
 - those same contours, but colored to match the density-plot
 - the colored legend items

See attached,

Usman_3.mw

Also, as before, you can also customize thicknesses and overall size.

@jalal Try to zip up your .maple workbook file, to use it as an uploaded attachment on this site.

@MadPenguin I launch Maple's GUI from a console window (xterm) in Linux.

Then I look at the error messages that the Java GUI sends to that console when it tries to open a file with corrupted XML.

Some years ago there were a whole variety of flavours of such XML file corruption. In Maple 2022 it's down to mostly one common kind of malformed "Equation" element, which can simply be removed. The error message indicates the text-file line-number location of the first one.

I correct the broken XML element using a text editor, in my case I use vi. Fortunately I happen to know quite a bit about how Maple documents use that format, although often the fixes are common sense.

Then I close the opened document tab in the Maple GUI (which wasn't fixed properly by the GUI -- a major point here...).

Then I re-open it, and repeat as necessary.

Lastly (and this is sometimes important) I make sure to Save the ostensibly hand-fixed file, using the same Maple version. In rare occasions in the past this revealed further issues to be fixed.

When I can round-trip Open->Save->Re-open using the member's Maple version then I consider it done.

The whole process usually takes me about 5-15 minutes. Sometimes I get a vote-up; sometimes not.

In many cases the hand recovery gets much more content recovered than does the Maple GUI (up until Maple 2022, at least).

Hope that helps.

Please add your close followup examples on this topic as Replies/Comments to this Question thread, instead of in a wholly separate, new Question thread.

@KIRAN SAJJAN The values of Phid and Phid1 as eta approaches zero appear to be the same for the four different RVals parameter values. Their slopes (derivative w.r.t. eta) differ near eta=0. The plots appear to confirm that.

error_in_table_value_1_ac.mw

@2cUniverse Please correct (or make more "exact") your Question here, rather than correcting it in a wholly new Question thread,

Please don't spawn another wholly duplicate Question thread for this.

Such duplicate threads can be flagged as such and may be deleted.

If you have followup queries or additional details on this same topic please add them here instead.

@Hullzie16 It would be more helpful if you were to show what you're actually trying to accomplish when you first post the Question.