<div dir="ltr"><div>Thank Thibaut for the information.</div><div>There is often no clear boundary between library codes and application codes.</div><div>For library codes, we do need the flexibility provided by the abstraction.</div><div>Cheers,</div><div>Youjun</div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Aug 4, 2018 at 11:33 AM Appel, Thibaut <<a href="mailto:t.appel17@imperial.ac.uk">t.appel17@imperial.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I can’t speak from a design point of view since I didn’t write PETSc myself but I assume it was to have more compact source files and to avoid copying routines twice (with one version for real and one version for complex).<br>
<br>
I am also using Fortran and it is actually flexible, as it allows you to write a unique version of your application code that works for both arithmetic types. If you need to write different pieces of code at some point, you can include preprocessed directives through the use of the PETSC_USE_COMPLEX boolean that is known at compilation time.<br>
<br>
Thibaut<br>
<br>
> Hi all,<br>
> <br>
> I am just wondering why PETSc introduces PetscScalar datatype in addition<br>
> to the PetscReal and PetscComplex.<br>
> Could someone help clarify the rationale behind this design?<br>
> I am primarily a Fortran guy. The additional datatype PetscScalar seems to<br>
> only confuse me rather than provide me any flexibility.<br>
> Cheers,<br>
> Youjun Hu<br>
<br>
</blockquote></div>