Fix definition of quadruple precision

[Juergen Reuter]

THe quadruple precision defined in the kinds.f90 module is indeed only a 10byte precision.

[Juergen Reuter]

There is one issue in the LHAPDF structure function:

libtool: compile:  gfortran -I../misc -I../vamp/src -I../shower -I../pdf_builtin -I../muli -I../circe1/src -I../circe2/src -fopenmp -g -O2 -c sf_pdf_builtin.f90  -fPIC -o .libs/sf_pdf_builtin.o
sf_lhapdf.f90:535.49:

               call evolvePDFphotonM (data% set, x, qq, ff(6:-6:-1), fphot)
                                                 1
Error: Type mismatch in argument 'x' at (1); passed REAL(10) to REAL(8)
sf_lhapdf.f90:541.49:

               call evolvePDFphotonM (data% set, x, qq, ff, fphot)
                                                 1
Error: Type mismatch in argument 'x' at (1); passed REAL(10) to REAL(8)

[Juergen Reuter]

One idea I have is the following: for some of the tests we might make them conditional on the precision and maybe give different reference files for double and quadruple precision. What do you think?

[Juergen Reuter]

Replying to jr_reuter:

There is one issue in the LHAPDF structure function:

libtool: compile:  gfortran -I../misc -I../vamp/src -I../shower -I../pdf_builtin -I../muli -I../circe1/src -I../circe2/src -fopenmp -g -O2 -c sf_pdf_builtin.f90  -fPIC -o .libs/sf_pdf_builtin.o
sf_lhapdf.f90:535.49:

               call evolvePDFphotonM (data% set, x, qq, ff(6:-6:-1), fphot)
                                                 1
Error: Type mismatch in argument 'x' at (1); passed REAL(10) to REAL(8)
sf_lhapdf.f90:541.49:

               call evolvePDFphotonM (data% set, x, qq, ff, fphot)
                                                 1
Error: Type mismatch in argument 'x' at (1); passed REAL(10) to REAL(8)

This has been resolved in r4620.

[Juergen Reuter]

Plan: what is now quadruple should be renamed into extended (incl. self tests). TO's program should be incorporated into fortran.m4 and provide the precision decision. In case true quadruple prec. will be supported there will be a third set of reference files, and then NAG vs. gfortran shall be tested. JRR will do the trivial renaming soon-ish ...

[Juergen Reuter]

The renaming is actually done since quite a while now. The rest is still pending.

[Juergen Reuter]

What is the status about this? TO promised to do something concerning the determination of precision.... but nothing ever happened!! Will be, however, earliest in milestone 2.2.6.

[Juergen Reuter]

After all tests run (including cross-compilation, thanks to TO) all (known) issues are caught and included, and this ticket can be closed.