<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">Il giorno Mer 12 Dic 2018, 20:04 Stefano Zampini <<a href="mailto:stefano.zampini@gmail.com">stefano.zampini@gmail.com</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">My problems are all real.</div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">And my mental issues all imaginary.... </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div dir="auto">I was just building a complex version of petsc and noticed these issue. As far as it is made clear (as it is) that Tao only supports real valued objective functions, there's no need to disable the solvers suite when petsc is compiled with complexes, since all the vectors and matrices used in TAO solvers will be zero in their  imaginary part. But probably there are other issues that I'm not considering?</div></div><br><div class="gmail_quote"><div dir="ltr">Il giorno Mer 12 Dic 2018, 18:46 Munson, Todd <<a href="mailto:tmunson@mcs.anl.gov" target="_blank" rel="noreferrer">tmunson@mcs.anl.gov</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Yes; the optimization problems do not make sense if the objective function is <br>
from C^n to C, as there is not a natural ordering for complex numbers.  If<br>
your objective is from C^n to R (and the constraints are from C^n to R^m), <br>
then the problem can be well defined.  Then we need to get into what bound<br>
constraints mean, etc.<br>
<br>
One challenge from the optimization perspective is dealing with the complex<br>
vectors and creating complex Hessian approximations.  I think its possible,<br>
but has never been a priority.  If the bounds are on the magnitude of the<br>
complex values, then we need appropriate nonlinear constraints to enforce<br>
them.<br>
<br>
Todd.<br>
<br>
> On Dec 12, 2018, at 9:18 AM, Stefano Zampini via petsc-dev <<a href="mailto:petsc-dev@mcs.anl.gov" rel="noreferrer noreferrer" target="_blank">petsc-dev@mcs.anl.gov</a>> wrote:<br>
> <br>
> <br>
> <br>
> Il giorno mer 12 dic 2018 alle ore 18:06 Dener, Alp <<a href="mailto:adener@anl.gov" rel="noreferrer noreferrer" target="_blank">adener@anl.gov</a>> ha scritto:<br>
> Hi Stefano,<br>
> <br>
> I can’t really speak to why the entirety of TAO is disabled in complex builds. Todd can probably offer historical insight to the reason(s). <br>
> <br>
> However, we do have some methods in TAO that are not tested or guaranteed to be correct for complex-valued objective functions.<br>
> <br>
> As far as I understands, TAO is clear in requiring  real objective functions, having PetscReal on the prototype for the callback<br>
> <br>
> The limited-memory quasi-Newton codes, for instance, currently only construct the approximate Hessian for the real part of the function and do not generate step directions in the complex part. I also don’t know whether any of the CG methods or line searches require any modifications to be correct in complex builds either.<br>
> <br>
> In your itemized list, I agree that at minimum we should be supporting #3 even if TAO itself does not work correctly for complex-valued functions.<br>
> <br>
> In the meantime, TAO can test real gradients or Hessians internally with `-tao_test_gradient` or `-tao_test_hessian`. Or you can also call `TaoTestHessian()` too. It’s a finite-difference test though, and not a complex-step test.<br>
> <br>
> ——<br>
> Alp Dener<br>
> Argonne National Laboratory<br>
> <a href="https://www.anl.gov/profile/alp-dener" rel="noreferrer noreferrer noreferrer" target="_blank">https://www.anl.gov/profile/alp-dener</a><br>
> <br>
> <br>
>> On Dec 12, 2018, at 8:23 AM, Stefano Zampini via petsc-dev <<a href="mailto:petsc-dev@mcs.anl.gov" rel="noreferrer noreferrer" target="_blank">petsc-dev@mcs.anl.gov</a>> wrote:<br>
>> <br>
>> If I compile PETSc with complex support, all of the TAO methods are not registered.<br>
>> Fare enough? not really, I can imagine at least three valid reasons to use those<br>
>> <br>
>> 1) I want to check that my code works for complex builds, even if I have pure real function evaluations. I may need complex support in other parts or the code (not when using TAO), or I just want to be a diligent PETSc developer<br>
>> 2) I want to test REAL gradients or Hessians using built-in capability, instead of writing my own<br>
>> 3) I want to use the complex differentiation trick to compute REAL gradients<br>
>> <br>
>> Last time I checked, at least option 2) was available; However, from commit 5921d7004dad83427f45468906667b100d2e2b6e, no Tao methods are registered when PETSC_USE_COMPLEX is defined, and code like the one below fail at runtime:<br>
>> <br>
>> TaoCreate()<br>
>> TaoSetFromOption()<br>
>> TaoSetObjectiveRoutine()<br>
>> TaoTestGradient()<br>
>> <br>
>> [0]PETSC ERROR: Unknown type. Check for miss-spelling or missing package: <a href="http://www.mcs.anl.gov/petsc/documentation/installation.html#external" rel="noreferrer noreferrer noreferrer" target="_blank">http://www.mcs.anl.gov/petsc/documentation/installation.html#external</a><br>
>> [0]PETSC ERROR: Unable to find requested Tao type lmvm<br>
>> <br>
>> <br>
>> -- <br>
>> Stefano<br>
> <br>
> <br>
> <br>
> -- <br>
> Stefano<br>
<br>
</blockquote></div>
</blockquote></div></div></div>