[bddcml-users] Complex number support

Sebastian Grimberg sebastiangrimb at gmail.com
Tue Jan 26 00:13:21 CET 2021


Hi Jakub,

Sure thing, I won't make any changes to master of course. I'll look forward
to hearing what Juan has to say on this topic, I am also by no means an
expert here and happy to learn best approaches.

For the weights, I was speaking purely hypothetically as I don't know if I
will be using the diagonal stiffness. That makes sense about the weights
for the inner product being a totally different thing than the weights from
the BDDC point of view, so as long as they are constructed to add up to one
then you can use them to compute dot products of parallel vectors, since
the redundant dofs will be weighted to add to one. This is all good and
makes sense for the Krylov solvers.

Sorry again, but two last quick questions out of curiosity:
1. Why BiCGSTAB over GMRES? Would it be substantial to implement GMRES
given what already exists, and/or would it provide any benefit?
2. From my understanding, the "use_arithmetic_constraints" add for each
subdomain edge a single coarse constraint for the average of the fine dofs
on that edge (is this correct?). If you wanted to add all edge dofs to the
coarse space, so that you are actually imposing continuity at each edge dof
separately, how would you do this? I would imagine the input to
bddcml_setup_preconditioner would be a matrix of size n_edge_nodes x
n_nodes where n_edge_nodes is the number of subdomain nodes lying on an
edge. This matrix would just have a one in each row corresponding to the
edge node. Is my understanding here correct? Obviously this would lead to a
very large coarse space but just curious if I understand what is going on.

Thanks, and I've already got most of the complex branch changes compiling
so just need to test them out to see if I broke anything.

Sebastian

On Mon, Jan 25, 2021 at 1:55 PM Jakub Sistek <sistek at math.cas.cz> wrote:

> Hi Sebastian,
>
> I have added you as a developer of BDDCML. Just do not push to the master,
> please. Another branch, say "complex", is fine!
>
> I will add Juan Calvo into the discussion on Nedelec elements vs.
> BDDC(ML). He has studied these things. I have never worked with these
> elements too closely really, but would be happy to learn.
>
> I think that I now understand your question about the inner products and
> weights! It is a slight abuse of the concept of partition of unity. In DD
> methods, the weighting operator plays a crucial role and there is a number
> of strategies available like the diagonal stiffness etc. Do you actually
> plan to use the diagonal stiffness at this side?
>
> In the Krylov method, on the other hand, the operator is just reused to
> get the right outcome from the duplicated entries at the interface. There
> are multiple ways how to do this, but I decided to go for this weighted
> inner products to avoid the need to assign unknowns to processes in a
> unique way as this is not needed anywhere else in the code. However, ANY
> partition of unity would do this job without affecting the performance of
> the preconditioner. So, the simple weights by cardinality would help here
> just fine. If you plan to use the diagonal stiffness in the preconditioner,
> then we will perhaps need to use separate weights here, it is not a problem
> although we would need to think how to do that. Otherwise, you could just
> use the
> wights_type = 0
> straightaway.
> Even if you needed the diagonal stiffness weights and thus the new
> partition of unity for inner products, that should be a rather simple thing
> to be done. I think I would not put the complex numbers as weights into
> these inner products.
>
> Let us keep in touch on this! I will contact the other developers to get
> their points of view and put you in the loop.
>
> Do not hesitate to ask! The code can be quite hard to read at many places
> so a quick question can be worth hours of decyphering the code. I am more
> than happy to help!
>
> Best wishes,
>
> Jakub
>
> --
> Jakub Sistek, Ph.D.
>
> Researcher
> Institute of Mathematics
> Czech Academy of Sciences
> sistek at math.cas.czhttp://www.math.cas.cz/~sistek
> +420 222 090 710
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.math.cas.cz/pipermail/bddcml-users/attachments/20210125/da9af9e3/attachment.html>


More information about the bddcml-users mailing list