Sorry, my previous title "6, or possibly 5" was wrong. It was based on a two-day-old memory of having played around with this graph. It should actually be "7, or possibly 6". Specifically,

• I can easily show that the bondage number is <= 7 by removing all 7 edges from vertex 1 (and it probably would work for any vertex). Then it only takes miiliseconds (using my MinDominatingSets procedure) to show that the domination number is 5 instead of 4.
• Using the technique that I described in the Answer above, it takes an average of only 54 microseconds to remove a subset of edges and check whether the domination number is still 4. Using this, I've checked all 31 million 5-subsets of edges, and they all leave the domination number at 4. Thus, the bondage number is > 5.
• There are 406 million 6-subsets of edges. To check them all would take a little over 6 hours.
• I am working on a heuristic search method to look for an "unbinding set" of size 6. The idea is to use the edges that individually give the greatest reduction to the set of 300 dominating sets. Since many reduce it by 56, and 6*56 > 300, I have some hope for this.

Although the numeric BVP solver does provide the feature that I mentioned above, it might not be a good idea to use it in this particular case. Two reasons:

1. In this case, it is trivial to compute those three values after the system is otherwise solved. If sol is the solution returned by dsolve, they can be read off directly from sol(0).
2. I'm not sure about this, but it's possible that including the symbolic variables significantly increases the computational burden and increases the chance of that most-dreaded of BVP errors "Newton iteration is not converging".

Regarding the label=  "dontexpand": At ?RootOf, it's explained that its last argument can be label= (almost anything). My guess is that some part of the solving process added this to your RootOf to convey some information to some other part of the process. Although I'm not sure, I don't think that this has anything to do with the error. It just happened to be inside the RootOf at the time the error occurred.

@tomleslie Maple's numeric BVP solver will solve for symbolic scalar variables in the system if you provide one extra boundary condition for each such variable. The OP wants a[1], a[2], and a[3] to be those variables. Thus 10 is the correct number of boundary conditions.

@lcz It's not specific to graphs. If L is any list, and P is any permutation of its indices, then L[P] is the corresponding permutation of the elements. 

Thanks for catching the stray {. My eyesight can't distinguish it from [ at the default type size.

@tomleslie The edges do not need to be passed to the Graph constructor. You can replace

G2:= Graph({seq( seq( {i, j}, j in op(4,s)[i]), i=1..30)}):

with

G2:= Graph(op(4,s)):

And  you don't need IsIsomorphic to get phi. You can do

phi:= op(3,s) =~ [$nops(op(3,s))];

These aren't just syntactic shortcuts; they're significantly more efficient. 

@lcz My algorithm's approach is a simple straightforward check-all-subsets approach. Since the subsets are checked in size order, this is guaranteed to work. Of course, "all subsets" could easily be impossibly large to check, and some heuristics for special cases will likely have a better average-case time. I saw a paper recently that claimed a polynomial-time algorithm for certain classes of graphs, including triangle-free graphs. The writing was dense and very technical for me, and I didn't have the mental energy to plow through it. I'll post a link to that paper if you're interested. 

Formulating the problem as an ILP seems cute and academically interesting, but I'd guess that it doesn't have much practical value because there aren't average-case efficient algorithms for general ILPs. (Not sure.) Formulation as an LP would be a different matter.

I think that it could also be formulated as a boolean satisfiability problem, which Maple has a great algorithm for. (See ?Logic,Satisfy.) But, if the general problem is NP-hard, these things can't really help with the computation time.

@Danish Toheed I suppose that you're already aware that the "raw" Newton's method converges very slowly at points where both the function and its derivative are 0 (a condition usually equivalent to "multiple roots"). In practice, I often divide a function by its own derivative, then simplify, before applying Newton's to avoid this. (Yes, I know there are cases where this itself causes problems.)

@vlineze Your Answer reads to me as if it were written by ChatGPT. Was it?

@lcz Yes, in most languages that have a goto, it is fast, and the only harm that it can cause is stylistic. But the Maple goto is particularly slow (CPU time). If you don't believe me, then just construct a timing test of it.

I urge you to never consider using Maple's goto again. Maple's main looping command, do, is the most sophisticated looping command that I'm aware of in any language, and its options allow you to control any situation without using goto.

Just in case this wasn't already obvious: The main purpose of my Answer is to tell you that I don't think that it'd be a good idea to use evala on all your integrals. I wasn't denying that it can help in some cases.

@dharr As the OP has stated repeatedly over the years in numerous threads, they need an automatic way to stop processing, not a "button". The timelimit command is unreliable. Even if it works 99% of the time, that's not good enough. The OP does batch-mode processing of (I think) thousands of unrelated symbolic integrals and ODEs. It's a major hassle to get stuck on one that can't be killed via a trappable error such as timelimit gives.

@acer From reading only the posted and displayed part of Tom's worksheet, I don't see any.simplify with side relations command. Perhaps there is one in the worksheet that didn't get displayed. The result that I got is identical to what Tom got with subs followed by one-argument simplify.

@lcz Here is the reason that I know that the domination set that I return is of minimal size: Subsets of the vertices are checked in order by size. The loop that begins in V do checks all k-subsets of V on its k^th iteration.

The first 9 words of your title---"Is there no function in Maple to calculate the..."---which is more than appears in the index "Active Conversations", have almost zero information content. Please change the title to the words after those: "Domination number of a graph". If you feel that you must include low-information words, then put them at the end of the title where they'll do less damage.

And there's no need to phrase titles as grammatical questions. It should only be done if it doesn't destroy the inforrnation content at the beginning.

My objections apply only to titles. If you want to begin the body with an actual question, that's fine by me.