Hi everyone,
As Hong pointed out the optimization variable and gradient are both complex
in my use case. Just to give some context, the TS solves the IVP with the
parameters representing the refractive indices of the object at a given
orientation (Ni orientations in total). The optimization
In Sajid’s problem, the optimization variables (F_t in the equation u_t =
A*(u_xx + u_yy) + F_t*u) are complex-valued. The gradients should also be
complex-valued. The objective function may be real-valued.
Hong (Mr.)
On Apr 14, 2020, at 5:52 PM, Dener, Alp mailto:ade...@anl.gov>>
wrote:
We'd have complex values in vectors that contain the likes of gradients
with respect to (real-valued) parameters so there would likely need to
be lots of PetscRealPart() within TAO. It won't just compile if we turn
on complex, but these changes should be feasible and is surely a better
solution
This is correct. As long as the optimization variables and the objective
function, and it’s gradient are real valued, intermediate variables (such as
PDE states) can be complex.
In principle it is also possible to minimize real valued functions in complex
variables by converting to rectangular
On Tue, Apr 14, 2020 at 6:26 PM Stefano Zampini
wrote:
> Not true in general when you minimize an objective function as a
> functional of the parameter only
> For same methods (Newton for example, gradient descent, etc) the state
> variables do no enter the minimization, so it should be fine to
Not true in general when you minimize an objective function as a functional of
the parameter only
For same methods (Newton for example, gradient descent, etc) the state
variables do no enter the minimization, so it should be fine to have
complex-valued state variables
> On Apr 15, 2020, at
Sorry for the time travel. As far as I know, optimization over complex-valued
parameters is not a well-defined problem. I am not sure how you can develop an
optimization algorithm for it. Perhaps our optimization experts have better
suggestions in this direction.
The real-valued formulation
First, you need to order your equations (r_0, i_0, r_1, i_1, ...) and then
set a block size of two (times the real block size of your equations) in
the matrix, for GAMG to work. PETSc can do this for you with fieldsplit.
The symmetric stuff that GAMG requaries is just for the (parallel) graph
Tao does not support --with-scalar-type=complex
Il Mar 14 Apr 2020, 22:09 Matthew Knepley ha scritto:
> On Tue, Apr 14, 2020 at 2:44 PM Sajid Ali <
> sajidsyed2...@u.northwestern.edu> wrote:
>
>> Hi Hong,
>>
>> Apologies for creating unnecessary confusion by continuing the old thread
>> instead
Hi Matthew,
The TAO manual states that (preface, page vi) "However, TAO is not
compatible with PETSc installations using complex data types." (The tao
examples all require !complex builds. When I tried to run them with a petsc
build with +complex the compiler complains of incompatible pointer
On Tue, Apr 14, 2020 at 2:44 PM Sajid Ali
wrote:
> Hi Hong,
>
> Apologies for creating unnecessary confusion by continuing the old thread
> instead of creating a new one.
>
> While I looked into converting the complex PDE formulation to a real
> valued formulation in the past hoping for better
Hi Hong,
Apologies for creating unnecessary confusion by continuing the old thread
instead of creating a new one.
While I looked into converting the complex PDE formulation to a real valued
formulation in the past hoping for better performance, my concern now is
with TAO being incompatible with
On Mar 27, 2019, at 8:07 PM, Sajid Ali via petsc-users
mailto:petsc-users@mcs.anl.gov>> wrote:
Hi,
I'm able to solve the following equation using complex numbers (with ts_type cn
and pc_type gamg) :
u_t = A*u'' + F_t*u;
(where A = -1j/(2k) amd u'' refers to
Hi Jed/PETSc-developers,
My goal is to invert a set of these PDE's to obtain a series of parameters
F_t (with TSSolve and TSAdjoint for function/gradient computation). I was
planning to use TAO for setting up the inverse problem but given that TAO
doesn't support complex scalars, I'm re-thinking
When you roll your own equivalent real formulation, PETSc has no way of
knowing what conjugate transpose might mean, thus symmetry is lost. I
would suggest just using the AVX2 implementation for now and putting in
a request (or contributing a patch) for AVX-512 complex optimizations.
Sajid Ali
Hi,
I'm able to solve the following equation using complex numbers (with
ts_type cn and pc_type gamg) :
u_t = A*u'' + F_t*u;
(where A = -1j/(2k) amd u'' refers to u_xx+u_yy implemented with the
familiar 5-point stencil)
Now, I want to solve the same problem using
16 matches
Mail list logo
