@ecterrab 

I am not taking you the wrong way at all. I am aware that my method of comparison is not ideal, I will take fault for that. I was unaware/naive about doing it as simply as you have. But this is where I think the final concern of mine can be seen and probably rectified. 

In your first reponse to my "potential bug" you have in (9) the expression for epsilon=0, a=b=1. Now in your latest post you have either (6) or (7) representing epsilon=0, a=b=1. You can see they do not match, and they should, they are both suppose to be the zeroth order expressions. Now I know we have ignored the physics discussion in this post but I assure you the expression that we obtain will be at most first derivative in both Phi and s. 

If there is something mathematical that I am forgetting and misunderstanding I will admit complete defeat but I am just so surprised that would be the case and that I have not picked that up. I do greatly appreciate your responses and help with post thus far as I have learned way better ways to use the Physics package. 

Edit:  I see your answer with the update you had posted today. Thank you very much for this. 

@ecterrab 

I aggree in that case but the discrepancy in (19) still bothers me. However, consider a different siuation instead. 

Don't let epsilon be zero at the start, instead do subs method for a=b=1 then a series for zeroth order in epsilon they do not agree with what are in the NO_BugMaple_(reviewed).mw file for epslion=0 at the start. Another issue that I think needs to be resolved, because it begs the question with all the options how would one no which is correct? Ofcourse Define is the best approach but requires the most computational time. 

I have attached the issue I described above, sadly I couldn't find a compact way to do it. 

SeriesBug.mw

@ecterrab

Here is attached worked sheet with the suspected bug I mentioned above. 

Curious about your thoughts on this as well.

BugMaple.mw

Thank you for this response. I look forward to seeing what you come up with. 

I also see this as an opportunity to bring to your attention a bug I have found. 

In trying to speed up the process and avoiding the use of Define i tried a method that simply assumed the tensor indices on each term individually and then added said expressions at the end, easy enough. I however noticed there are discrepinces when i condisdered the zeroth order expression in epsilon with this method and using Define. I would be curious to have your thoughts on this problem as well. I will try to make a compact worksheet displaying this issue and reply tho this thread with it. 

@ecterrab 

This is great. The change is self-explanatory. 

Thank you!

@vs140580 

I see what you mean by zeros now. My mistake.

Good question. 

@sursumCorda 

Thank you for your comment, I misread what you had written therefore I retract my previous statement. 

What variable are you trying to solve for? This is one equation with 4 unkowns as I see it. So you would have infinit solutions. Unless I am missing something. 

@tomleslie 

Thank you for inclduing this method as well, always wanting to learn new techniques! 

@acer 

I didn't think to much of the messages tone, I was just grateful for a response. 

Thanks again and thank for you including another method. 

@acer 

This is great thank you. My amateur status is showing. 

Will keep these comments under consideration with future "Arrays" I want to make. 

Thank you everyone who added a comment/suggestion. 

This was quite informative. 

@dharr @Axel Vogt @Carl Love

@Carl Love 

When we are telling maple that the discirminant is positive we are saying three real roots, but when doing what you described it only returns one, When it should be returning three. Is the explanation similar to what I above and that there is always imaginry contributions? 

@dharr 

Thank you for this. I did not know about solve,parametric. 

The issue that I am having though and maybe maple can not do what I am asking(or it is some general cubic property that I am forgetting). Is that in the solutions there is still an imaginary term. So it appears too me that analytic solutions will contain Imaginary contributions always but once numeric values for the parameters are inserted the imaginary part will become real. 

I assume there is no work around for this, and there will always be a imaginary contribution to a analytic solution?

@vv 

I see that, for this particular problem I need to know when things become complex so i will omit that command. 

What exactly did you tell maple to do? I still wanna understand it a bit more. (I do appreciate the solution though).