Parallel parameters with start_system

[Jan Kosata]

The support for parallel parameters was added here #342

This allows the user to use the keyword argument target_parameters::Vector{Vector{Number}} in solve and then parallelize with threading=true. However, it works with neither start_system=:total_degree nor start_system=:polyhedral .

For a System f and vectors a, b, c, the following
solve(f, start_system=:polyhedral, target_params = [a, b, c])
does not run while
solve(f, start_system=:target_params, target_params = [a, b, c])
appears to only take the first parameter vector from target_params and simply repeat the solution.

It would be great to have an input method similar to that introduced in #342 .

[Paul Breiding]

Hi, thank you for your message.

I think this is an issue with syntax. Can you send a full example?

[Jan Kosata]

Apologies, the full example follows.
using HomotopyContinuation
@var x, a, b
s = System([x^2 + a*x + b], variables=[x], parameters=[a,b])
p1, p2 = [1,1], [2,2] # parameter vectors to solve for

This solves correctly:
soln = solve(s, [[1.0*im], [-1.0*im]], start_parameters=[0.,1.], target_parameters=[p1, p2])
solutions.(getindex.(soln,1))

OUTPUT: 2-element Vector{Vector{Vector{ComplexF64}}}:
[[-0.5 + 0.8660254037844387im], [-0.5 - 0.8660254037844387im]]
[[-1.0 + 1.0im], [-1.0 - 1.0im]]

This appears to solve for p1 and then repeat the solution:
solve(s, start_system=:start_system, target_parameters=[p1, p2])

OUTPUT: 2-element Vector{Vector{Vector{ComplexF64}}}:
[[-0.5 + 0.8660254037844387im], [-0.5 - 0.8660254037844387im]]
[[-0.5 + 0.8660254037844387im], [-0.5 - 0.8660254037844387im]]

This gives an error
solve(s, start_system=:polyhedral, target_parameters=[p1, p2])

OUTPUT: MethodError: no method matching target_parameters!(::PolyhedralTracker{HomotopyContinuation.ToricHomotopy{MixedSystem{Int32, (0x4aa2bd54c25b1aff, 1)}}, CoefficientHomotopy{MixedSystem{Int32, (0x4aa2bd54c25b1aff, 1)}}, Matrix{ComplexF64}}, ::Vector{Int64})

[Paul Breiding]

Hi, here is the fix for what you want to do:

using HomotopyContinuation
@var x, a, b
s = System([x^2 + a*x + b], variables=[x], parameters=[a,b])
p1, p2 = [1,1], [2,2] # parameter vectors to solve for

p_generic = randn(ComplexF64, 2)
soln_generic = solve(s, target_parameters = p_generic)

soln = solve(s, solutions(soln_generic), start_parameters = p_generic, target_parameters = [p1, p2])

Let me explain what happens: our software has implemented a function that tracks one parameter to many parameters in an optimized way. This is also what you have above in the lines coming after "This solves correctly:". There is no function that takes as input just a system and tracks towards many parameters. You always have to give a start parameter.

The way to get a starting parameter is to randomly sample a complex vector of parameters and solve for them. This is not just a hot fix: starting at a random complex parameter significantly increases the stability of the method. So, if you would like to solve for many parameters always do this: first solve a random complex parameter, then starting from this complex parameter solve the parameters you are interested in.

Does this help?

[Jan Kosata]

Thanks a lot for taking the time to help us out!

Up until now, we have indeed worked with the randomized initial solution you describe. However, depending on the randomly-chosen p_generic, soln_generic can contain different numbers of complex solutions. Starting from soln_generic can then miss entire solution branches as (AFAIK) soln always has <= solutions of soln_generic. In addition, solution branches would sometimes be tracked correctly in some parameter regions but not in others (maybe because the initial guess became too far from the sought solutions) - a branch would then appear "smaller" in parameter space than it really was.

We also tried constructing p_generic from one of the target_parameters multiplied by a complex number of modulo 1, reasoning that this initial guess will be "close" to the eventual solutions. We hit the same problems there.

Starting from the total degree homotopy for each single parameter set has been much slower, but very reliable, so we wanted to have it as a "safe" option in our code.

[Paul Breiding]

Hi, what random numbers are you sampling for p_generic?

In theory, if you sample a random complex start parameter with probability one you will get all solutions in soln. So, what you describe can't be a problem in the method, but I guess some detail in the code needs to be fixed.

[Jan Kosata]

We were sampling standard Gaussians with mean = 0 and stdev = 1 using randn(ComplexF64, length::Int64)

I will try and diagnose what went wrong again then, thanks.

[Paul Breiding]

That should be ok. Please, let me know what is the outcome of the diagnosis.

[Sascha Timme]

Are the random parameters coordinate wise representative in magnitude for the parameter range you are interested in?

[Jan Kosata]

I relegated the missing-solutions issue to #492