[petsc-users] Why PETSc needs PetscScalar datatype?

Youjun Hu youjunhu at gmail.com
Sat Aug 4 16:13:56 CDT 2018


I just tried to change PetscScalar to the specific datatype PetscComplex in
my Fortran code, but the compiler raised the following error:
PetscComplex   my_coeff
Error: Unclassifiable statement at (1)

It seems that the compiler does not know this datatype.

My Petsc was configured with ./configure   --with-scalar-type=complex
--with-precision=double

Before the modification, the code was complied successfully.
Could someone help?

Thanks,
Youjun

On Sat, Aug 4, 2018 at 12:28 PM Smith, Barry F. <bsmith at mcs.anl.gov> wrote:

>
>
> > On Aug 4, 2018, at 1:11 PM, Youjun Hu <youjunhu at gmail.com> wrote:
> >
> > Thank Barry for the clarification.
> > In summary, application code developers should choose the specific
> datatypes (PetscReal and PetscComplex) rather than the more general
> datatype PetscScalar
> > because application codes usually have fixed datatype and the
> flexibility provided by PetscScalar is for PETSc library developers and
> usually not for application developers.
> > If an application developer uses PetscScalar to declare a variable that
> is intended by the developer to be complex and is assigned a complex value
> later in the code and then used in, e.g.,  MatSetValues, but it happens
> that petsc is configured with --with-scalar-type=real
> > then, it is not possible for this error to be detected at compiling
> time. If the developer specify PetscComplex, then this inconsistency can be
> seen by compilers and hopefully an error message can be raised during
> compiling.
> >
> > Conclusion: avoid using PetscScalar in application codes unless it is
> absolutely needed (which is not common). The example application codes
> provided in tutor folds of petsc often use PetscScalar, which is a little
> misleading and should better be revised to use concrete datatypes.
>
>     The reason the examples use PetscScalar is so that all the examples
> can be used to test both the real and complex versions of the libraries. If
> they used the specific types they could only be testing one or the other.
>
>     Note there is no harm in writing applications with PetscScalar it is
> just usually not needed.
>
>    Barry
>
> > Correct me if anybody finds this conclusion is not justified.
> >
> > Cheers,
> > Youjun
> >
> >
> >
> > On Sat, Aug 4, 2018 at 11:03 AM Smith, Barry F. <bsmith at mcs.anl.gov>
> wrote:
> >
> >   For a particular configuration (./configure --with-scalar-type= real
> or complex) the PETSc objects, such as vectors and matrices either contain
> real values or complex values. In the same running code it is not possible
> to have some vectors with real numbers and some vectors with complex
> numbers.
> >
> >   Depending on how you configure PETSc ./configure --with-scalar-type=
> real or complex the variable name PetscScalar becomes either PetscReal or
> PetscComplex. PETSc code is written with PetscScalar so we can reconfigure
> the same source code and have it work with real numbers or complex.
> >
> >    For users who just work with real numbers you can simply use
> PetscReal as your variable type. If working with just with complex numbers
> you can use PetscComplex. If you want to sometimes configure with real
> numbers and sometimes configure with complex (which is not common) you use
> PetscScalar.
> >
> >    Barry
> >
> >
> > > On Aug 4, 2018, at 11:39 AM, Youjun Hu <youjunhu at gmail.com> wrote:
> > >
> > > Hi all,
> > >
> > > I am just wondering why PETSc introduces PetscScalar datatype in
> addition to the PetscReal and PetscComplex.
> > > Could someone help clarify the rationale behind this design?
> > > I am primarily a Fortran guy. The additional datatype PetscScalar
> seems to only confuse me rather than provide me any flexibility.
> > > Cheers,
> > > Youjun Hu
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-users/attachments/20180804/de21d2e5/attachment.html>


More information about the petsc-users mailing list