[petsc-dev] why is there a #requirespackage 'PETSC_HAVE_PCBDDC'

[Stefano Zampini]

HI,

I extensively tested and used the BDDC/FETI-DP code on two different linux
clusters and on BlueGene/Q and it worked fine for me.
The example (src/ksp/ksp/examples/tutorials/ex59.c) needs to be adapted in
its LAPACK calls to get it working on BlueGene/Q; namely,  LAPACKsterf_
should be added to petscblaslapack header files (Jed, can you do this?).
Also, I remember that some time ago Jed experienced some runtime problems
with this example. Can you test it now? It should work.

Yes, the complex case is not yet supported; also, there is some additional
work to do to get it working with 64 bit indices.

Regarding PARMETIS dependency: now the code makes explicit calls to METIS
functions and uses METIS types. Using MatPartitioning interface is on my
todo list to remove such an explicit dependency.

In the dev repo, the BDDC/FETI-DP code is all contained in bddc.c; I have
an improved version on my laptop and on BlueGene/Q with source codes split
in different files (for BDDC, FETI-DP and the BDDCGraph structure which is
used to analyze the interface between subdomains) and with the 64 bit
indices issue solved, but I cannot push it because it contains an advanced
scaling operator (see e.g. p. 9 bottom at
http://cs.nyu.edu/csweb/Research/TechReports/TR2013-951/TR2013-951.pdf)
which I'm extensively using in my research. Also, the new code needs the
Colpack library to compute distance 1 coloring of graphs (there's a
preliminary version of interface to Colpack at
https://bitbucket.org/petsc/petsc-dev/issue/25/add-support-for-1-coloring-instead-of-only
)

In summary: I'm fine with you adding the guards for PARMETIS, reals and 64
bit indices. I'm the only developer of BDDC code in PETSc, and now I don't
have time to push changes since I mostly work on it in my spare time (and
now I don't have spare time.. Maybe by the end of March)


2013/3/5 Stefano Zampini <s.zampini at cineca.it>

> HI,
>
> I extensively tested and used the BDDC/FETI-DP code on two different linux
> clusters and on BlueGene/Q and it worked fine for me.
> The example (src/ksp/ksp/examples/tutorials/ex59.c) needs to be adapted in
> its LAPACK calls to get it working on BlueGene/Q; namely,  LAPACKsterf_
> should be added to petscblaslapack header files (Jed, can you do this?).
> Also, I remember that some time ago Jed experienced some runtime problems
> with this example. Can you test it now? It should work.
>
> Yes, the complex case is not yet supported; also, there is some additional
> work to do to get it working with 64 bit indices.
>
> Regarding PARMETIS dependency: now the code makes explicit calls to METIS
> functions and uses METIS types. Using MatPartitioning interface is on my
> todo list to remove such an explicit dependency.
>
> In the dev repo, the BDDC/FETI-DP code is all contained in bddc.c; I have
> an improved version on my laptop and on BlueGene/Q with source codes split
> in different files (for BDDC, FETI-DP and the BDDCGraph structure which is
> used to analyze the interface between subdomains) and with the 64 bit
> indices issue solved, but I cannot push it because it contains an advanced
> scaling operator (see e.g. p. 9 bottom at
> http://cs.nyu.edu/csweb/Research/TechReports/TR2013-951/TR2013-951.pdf)
> which I'm extensively using in my research. Also, the new code needs the
> Colpack library to compute distance 1 coloring of graphs (there's a
> preliminary version of interface to Colpack at
> https://bitbucket.org/petsc/petsc-dev/issue/25/add-support-for-1-coloring-instead-of-only
> )
>
> In summary: I'm fine with you adding the guards for PARMETIS, reals and 64
> bit indices. I'm the only developer of BDDC code in PETSc, and now I don't
> have time to push changes since I mostly work on it in my spare time (and
> now I don't have spare time.. Maybe by the end of March)
>
> Stefano
>
>
> 2013/3/5 Jed Brown <jedbrown at mcs.anl.gov>
>
>>
>> On Mon, Mar 4, 2013 at 6:25 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:
>>
>>> The makefile should be marked as not supporting complex
>>>
>>> > It was put into the repository mostly because we don't have a good
>>> system for supporting forks.\
>>>
>>>    I thought bitbucket now gives a system for handling forks?
>>>
>>
>> Yeah, this was before we used bitbucket, but we still haven't established
>> a workflow conducive to supporting downstream forks.
>>
>>
>>> > It was off by default because the code was unstable and untested.
>>> There is an example now (src/ksp/ksp/examples/tutorials/ex59.c) so I think
>>> we can remove the --with-pcbddc option. Stefano, does this sound right to
>>> you?
>>>
>>>    Or it could be a good test example for a PETSc plugin repository?
>>>
>>
>> Yes, either way. Stefano, if you feel it is reasonably stable, can you
>> remove the --with-pcbddc guard and put in the necessary restrictions
>> (#requirespackage 'PETSC_HAVE_PARMETIS', #requiresscalar real)?
>>
>
>


-- 
Stefano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130305/accae0e2/attachment.html>