[petsc-users] matrix with complex number

Hal Finkel hal.finkel at yale.edu
Sat Jan 23 09:04:16 CST 2010


Barry,

I'd think that adding efficient cross-type operations in C also has a 
combinatorial explosion problem :)

At the expense of a more complicated build system, the ugliness can be 
addressed in the following way: prior to compiling, ctags (or some sed 
script, etc.) is run against the source files to pull out the global 
symbol names. The list is then used to generate a header file which 
looks like:

#if defined(USE_FLOAT)
#define Sym1 Sym1_FLT
...
#elif defined(USE_DOUBLE)
#define Sym1 Sym1_DBL
...
#endif

I've done this kind of thing too, so I figured I'd mention it. It has 
the advantage that the source files are left essentially unchanged.

  -Hal

Barry Smith wrote:
> 
>   Hal,
> 
>    Thanks for the suggestion. I've played around with this approach over 
> the years, but given the size of PETSc I've always been too frightened 
> by the uglyness and complexity of maintaining such code. It also doesn't 
> cleanly handle mixing objects of different types together. For example, 
> from a user perspective it is completely reasonable to try to multiply a 
> complex vector by a real matrix, or conversely a real vector by a 
> complex matrix, or to put real values into a complex matrix or vector 
> but providing support for this requires even more "templating-like" 
> stuff with macros.
> 
>    Barry
> 
> On Jan 22, 2010, at 10:23 PM, Hal Finkel wrote:
> 
>> Barry,
>>
>> I've used the following process to achieve a similar effect in C 
>> projects:
>>
>> Modify the make files to build each source file multiple times, once 
>> for each base type (float, double, double complex, etc.). The type is 
>> selected via a preprocessor definition provided on the command line 
>> (-DUSE_FLOAT, -DUSE_DOUBLE, etc.). A prefix or suffix specific to each 
>> type is appended to the name of the resulting object file (so that 
>> they're unique). Also, the function names (and all other global 
>> symbols) in each file are wrapped with a function-like macro which 
>> appends a prefix or suffix depending on the current type selected. In 
>> this way, everything can be included in one library without conflict 
>> or unnecessary code duplication.
>>
>> -Hal
>>
>> Barry Smith wrote:
>>>   The issue is that PETSc is written in C and there are not C++ 
>>> templates in C. We do not want to write TWO copies of each file, one 
>>> with dcomplex everywhere and another with double everywhere and give 
>>> different names to the functions in each language. It would be a pain 
>>> to write and maintain and a pain to use. Who wants to write 
>>> MatSolve() to solve with real numbers and MatSolveComplex() to solve 
>>> with complex?
>>>  C++ templates can be used to make all this possible but they are not 
>>> perfect to the task. Basically we need a better language to allow 
>>> easy mixing of dcomplex and double.
>>>   Barry
>>> On Jan 22, 2010, at 2:43 PM, Yujie wrote:
>>>> Dear Barry,
>>>>
>>>> What are the difficult things if PETSc is revised with matrices of 
>>>> complex and real numbers? It should be more flexible for a general 
>>>> scientific toolbox. I am curious almost all the packages don't 
>>>> support both simultaneously. Thanks a lot.
>>>>
>>>> Regards,
>>>> Yujie
>>>>
>>>> On Fri, Jan 22, 2010 at 2:35 PM, Barry Smith <bsmith at mcs.anl.gov> 
>>>> wrote:
>>>>
>>>>  The way we handle complex numbered linear systems in PETSc is to 
>>>> compile all of PETSc with complex numbers and then just use the 
>>>> solvers on those complex numbers. The current drawback to this is 
>>>> that PETSc can only be built with support for complex numbers or for 
>>>> real numbers. We cannot build a PETSc where some matrices are 
>>>> complex and some are real.
>>>> We don't have any interest in solving complex systems as larger real 
>>>> systems.
>>>>
>>>>  Barry
>>>>
>>>>
>>>> On Jan 22, 2010, at 11:04 AM, Yujie wrote:
>>>>
>>>> Dear PETSc Developers,
>>>>
>>>> Recently, I am trying to find some complex number-based solvers and 
>>>> preconditioners. However, it is difficult to find a general 
>>>> framework to include some solvers and preconditioners. Trilinos is 
>>>> developing a package, komplex, to use the real-number-based solver 
>>>> to solve complex number -based problem. I don't know whether PETSc 
>>>> wants to develop such the function for complex number-based problem. 
>>>> I think it will significantly increase the application range of 
>>>> PETSc. After all, in PETSc, lots of solvers and preconditioners have 
>>>> been developed. Thanks  a lot.
>>>>
>>>> Regards,
>>>> Yujie
>>>>
>>>>


More information about the petsc-users mailing list