<div dir="ltr"><div dir="ltr">Hi Jakub,<div><br></div><div>Thanks for getting back to me, it's nice to meet you!</div><div><br></div><div>The applications I'm interested in involve high-frequency time-harmonic electromagnetics, so typically dealing with complex symmetric indefinite operators. I know there is quite a bit of H(curl) specific BDDC literature out there involving better selection of coarse constraints using change of basis for Nedelec elements, but I figure if I end up needing this I could use the general user-defined constraints in BDDCML (maybe you have some thoughts on this?).</div><div><br></div><div>I'd be happy to work on implementing complex number support in the library and see where it goes. I have a few thoughts:</div><div><br></div><div>1. At a high level, I could see two ways to manage the different scalar types.</div><div><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div dir="ltr"><div>- First, something like what MUMPS does, is to just maintain two versions of every type-specific file so the user would include the correct module for double/complex support. This could be simple for just double/complex, but if later you also want to add an option for single precision or 64-bit integers it becomes rather involved.<br></div><div>- Alternatively, we could use conditional compilation in a more "C" approach to define at compile time the scalar type to be real(kind=8) or complex(kind=8) and use this throughout the code, wrapping type specific commands in #if defined/#else pragmas. I'm not even sure if this is possible in Fortran but would be the way to do it in C/C++ I think. Do you know anything about this? </div></div></blockquote><div dir="ltr"><div><br></div><div>2. The blopex object files for double versus complex share the same names (see the files in blopex_serial_double or blopex_serial_complex which would be needed). I presume this would cause some build issues, which further motivates building only a single library for real OR complex numbers and then just linking to the correct blopex version. But again, I don't know how this is possible in Fortran.</div><div><br></div><div>3. In the case of complex matrices, the partition of unity weights for interface degrees of freedom could be complex (when using diagonal stiffness scaling, for example). Is this allowed? Do we require them to be Hermitian at least? I see that for indefinite problems they are constrained to be positive. This is a bit beyond my expertise but I am not sure of the implications for requiring them to always be real and positive or allowing them to be complex and how to handle that in the dot products required for Krylov methods. I'm not sure what PETSc's PCBDDC does about this.</div><div><br></div><div>Sorry for the long email, I hope this makes sense to you and I'm curious to know your input before getting started. Thanks again!</div><div><br></div><div>Sebastian</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 22, 2021 at 7:28 AM Jakub Sistek <<a href="mailto:sistek@math.cas.cz" target="_blank">sistek@math.cas.cz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>Hi Sebastian,<br>
<br>
first of all, thank you for your interest in BDDCML!<br>
<br>
So far, there has been no need for supporting complex numbers in
BDDCML, so you are the first one asking for this :-) What
applications do you have in mind?<br>
<br>
Implementation-wise, this may not be too bad, as you suggest,
although the "double" type is hard-coded in a lot of subroutines
where it would require changing. Even blopex has a version for
complex numbers, although one should start without the adaptivity.
And yes, it would be applicable only to Hermitian matrices. MUMPS
supports all the types one needs, so this should be
straightforward.<br>
<br>
More flexible variable types would be helpful in other scenarios I
am interested in, such as<br>
* using long integers for certain indices for very large problems<br>
* using single precision instead of double<br>
<br>
Also algorithmically, I am not aware of any principal issues. I
know other DD codes support complex numbers, such as HPDDM or the
PCBDDC preconditioner in PETSc. I know the developers, so I would
be able to ask for advice.<br>
<br>
This would actually be a nice extension of the functionality of
BDDCML! If you were interested in helping with this, I would be
happy to give you access to the project on Github and we could try
to devise such version in a new branch together.<br>
<br>
Let me know what you think.<br>
<br>
Best wishes,<br>
<br>
Jakub<br>
<br>
<br>
<br>
On 22/01/2021 05:29, Sebastian Grimberg wrote:<br>
</div>
<blockquote type="cite">
<div><span style="word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)">Hello
everyone,</span>
<div dir="auto" style="word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)"><br>
</div>
<div dir="auto" style="font-size:1rem;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)">I’m
a new user and am wondering if there is any interest or
thoughts on supporting complex numbers in BDDCML? I’m unsure
about the blopex dependency for adaptivity, and further it may
not even be applicable unless the input materials is
Hermitian, but it seems like it could be doable by calling the
correct MUMPS library and adjusting the interface a bit. Would
this be worth spending time to develop, and are there any
other foreseeable issues?</div>
<div dir="auto" style="word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)"><br>
</div>
<div dir="auto" style="font-size:1rem;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)">Cheers,</div>
<div dir="auto" style="word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)"><br>
</div>
<div dir="auto" style="font-size:1rem;word-spacing:1px;border-color:rgb(49,49,49);color:rgb(49,49,49)">Sebastian
Grimberg </div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
bddcml-users mailing list
<a href="mailto:bddcml-users@math.cas.cz" target="_blank">bddcml-users@math.cas.cz</a>
<a href="https://list.math.cas.cz/listinfo/bddcml-users" target="_blank">https://list.math.cas.cz/listinfo/bddcml-users</a>
</pre>
</blockquote>
<br>
<br>
<pre cols="72">--
Jakub Sistek, Ph.D.
Researcher
Institute of Mathematics
Czech Academy of Sciences
<a href="mailto:sistek@math.cas.cz" target="_blank">sistek@math.cas.cz</a>
<a href="http://www.math.cas.cz/~sistek" target="_blank">http://www.math.cas.cz/~sistek</a>
+420 222 090 710</pre>
</div>
</blockquote></div>
</div>