[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