Question: which ode to verify against? original or the root?

This might be more of a math question but I am using dsolve and odetest.

I have number of problems like this. Given an ode, where we need to first solve for y'(x) to isolate it. Say the ode has y'(x) under square root. So need to first square the ode.

Then say we obtain two roots. i.e. two solutions. Each is now an ode that can be solved directly.

Each one of these is solved on its own and generates a solution.

Now the question is this: Should one verify the solution of each of these root ode's against the original ode or against each root on its own that was used to generate this specific solution?

For example, given the ode sqrt(1 + diff(y(x), x)^2) + a*diff(y(x), x) = x then maple first solves for diff(y(x), x). This gives two new ode's. So we end up with two solutions. But odetest will not verify these two solutions against the orginal ode. 

It does verify each solution however against each of the root ode's. 

But should not the two generated solutions satisfy the original ode? Is it OK just to verify the solution against each root?

Here is worksheet example showing one such problem. I know that squaring an equation introduces extraneous solutions. but  in this case both solutions fail to verify against the original ode and not just one!

I am asking what is the accepted approach to this problem? Will it be OK to always verify the solution against the root of the original ode, or should one verify against the original ode used to solve for these roots? I have many ode's like this where odetest do not verify the solution generated because I am using the original ode to check the solution against. 

Download which_ode_to_verify_against.mw

Update

I think the verification should be done against the original ode and not against each of the root odes.

After all, this is the ode the user is asking to solve. Also the user have no idea what the root ode's are in order to use odetest against them and get zero residue. 

I think the issue is that it is just it is hard to symbolically verify that the residue from odetest is zero or not. This is the zero test problem.

I found that it depends on the value of a. 

if we assume a>1 or a<-1, then one of the two solutions is the correct one and the other is the extraneous as expected.

But using simplify with this assumption, maple was still not able to verify the residue is zero. But plotting it shows that this is the case.

Here is worksheet showing this.

Original ode generated two solutions. We then find the residue of each by calling odetest. Plotting each residue over say x=-3..3 and giving different values for a shows that one residue is always zero when a>1  (which means one solution is correct) and when a<-1 then it flips. 

At a=1 and a=-1, there is dvision by zero. For a between -1 and +1, both solution are wrong !  

So the bottom line is this:

Maple's solutions are as expected. Nothing wrong with them. After all, this is quadrature ode. So it is just one step to solve, which is to do integration. So if the integration is correct, that is it.

The hard part is to know which is the correct solution of the two, as it depends on value of a but simplify could not verify symbolically even using assumptions that residue is zero. Also when giving odetest assumptions on a it still could not verify the solution.

May be someone can find clever way to verify one of the residues is zero symbolically with this assumption. I could not.

Only numercially this is possible by plotting and looking. Here is worksheet. The problem with using the root ode's to verify the two solutions against gives true on both of them.

But this is false true. As only one of these two solutions is correct and it depends on the value of a which of the two solution is the correct one!
 

Download which_ode_to_verify_against_V2.mw

For some reason the plots do not display above (may be because they are in list). Here is screen shot

The best way to solving such ode's is to avoid squaring the ode in the first place. Sometimes this is possible, but not in this example. At least I could not find a way using some change of variables to avoid squaring it.