Cholesky DPOTRS solve function

[Roberto Corradini]

Hello FLAME community.

Here I have a small question to submit to you.

My code is using dpotrf_ and dpotrs_ LAPACK functions.

Till today I had these two lines in my source file :

  dpotrf_ (char *uplo, int *n, double *a, int *lda, int *info);
  dpotrs_ (char* uplo, int* n, int* nrhs, double* a, int* lda, double* b, int* ldb, int* info);

and I was linking against libflame.a , being build with the flag --enable-lapack2flame , successfully.

With the intention to move to native FLAME functions in the coming days, I included the "FLAME.h" header into my file , and commented the two lines above.

The function dpotrf_ is included in the "FLAME.h" header , while dpotrs_ is not.

Adding to my file the two following lines:

  #define F77_dpotrs F77_FUNC( dpotrs , DPOTRS )
  int F77_dpotrs(char* uplo, int* n, int* nrhs, double* a, int* lda, double* b, int* ldb, int* info);

solves the issue.

So , my question to the libFLAME development team is:

  is there a reason why dpotrs_ is missing , or it is just a "missing, left behind" function ?

Thank you,

Roberto

[Field G. Van Zee]

Hi Roberto,

Thanks for your question.

You are correct that libflame prototypes dpotrf_() but does not
prototype dpotrs_().

To explain why, first, consider that Fortran does not require
prototypes, and many C applications that already use LAPACK provide
their own prototypes in some way.

Thus, omitting our own prototypes is typically not a problem.

Now, I think the reason we do have prototypes for some functions, such
as dpotrf_(), is that we chose to prototype the LAPACK APIs for which we
have mappings to native implementations. Think of it as a sort of
checklist: when we implement an operation natively in libflame and then
provide an LAPACK compatibility mapping to that implementation, we check
it off the list by adding a prototype.

You may now finding yourself wondering why libflame provides a native
implementation of dpotrf_(), but not dpotrs_(). The reason: libflame
sometimes does not contain natively implement routines that are merely
wrappers to BLAS.

dpotrf_() is a Cholesky factorization, which libflame does natively
implement via FLA_Chol(). We provide the LAPACK compatibility interface
so that no API change is necessary.

dpotrs_() is a pair of triangular solves that uses the output of a
Cholesky factorization. There is no benefit to natively implementing
dpotrs_() in libflame because ultimately it will reduce to the same two
invocations of the trsm operation. Thus, libflame implements dpotrs_()
non-natively, which means that it defines dpotrs_() as a straightforward
C translation of the netlib LAPACK Fortran code.

Hopefully this answers your question.

Field

On 4/12/20 12:36 PM, 'Roberto Corradini' via libflame-discuss wrote:
> Hello FLAME community.
>
> Here I have a small question to submit to you.
>
> My code is using dpotrf_ and dpotrs_ LAPACK functions.
>
> Till today I had these two lines in my source file :
>
>   dpotrf_ (char *uplo, int *n, double *a, int *lda, int *info);
>   dpotrs_ (char* uplo, int* n, int* nrhs, double* a, int* lda, double*
> b, int* ldb, int* info);
>
> and I was linking against libflame.a , being build with the flag
> --enable-lapack2flame , successfully.
>
> With the intention to move to native FLAME functions in the coming days,
> I included the "FLAME.h" header into my file , and commented the two
> lines above.
>
> The function dpotrf_ is included in the "FLAME.h" header , while dpotrs_
> is not.
>
> Adding to my file the two following lines:
>
>   #define F77_dpotrs F77_FUNC( dpotrs , DPOTRS )
>   int F77_dpotrs(char* uplo, int* n, int* nrhs, double* a, int* lda,
> double* b, int* ldb, int* info);
>
> solves the issue.
>
> So , my question to the libFLAME development team is:
>

> /  is there a reason why dpotrs_ is missing , or it is just a "missing,
> left behind" function ?/
>
> Thank you,
>
> Roberto
>
> --
> You received this message because you are subscribed to the Google
> Groups "libflame-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to libflame-discu...@googlegroups.com
> <mailto:libflame-discu...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/libflame-discuss/880a76d8-522d-2d63-586b-e32cae5d1831%40yahoo.it
> <https://groups.google.com/d/msgid/libflame-discuss/880a76d8-522d-2d63-586b-e32cae5d1831%40yahoo.it?utm_medium=email&utm_source=footer>.

[rob.co...@gmail.com]

Thank you Field, it is clear to me now.

Roberto

> an email to libflame...@googlegroups.com
> <mailto:libflame-discuss+unsub...@googlegroups.com>.