[Dune-devel] [PATCH] Use unqualified calls to allow ADL.

[Atgeirr Rasmussen]

Dear Duners,

The customization we are trying to do is to instantiate FieldMatrix with a
class using automatic differentiation. The reason this fails is that ADL
does not happen for the functions in fvmeta, because they are called
with fvmeta::functionname() (qualified), and ADL requires unqualified
calls: functionname(), without the fvmeta.

If we add our own overload for absreal() to Dune::fvmeta, and include
our class before fieldmatrix.hh, things work, since then the function is
seen at the point the template is read. But this is of course very fragile,
include fieldmatrix.hh first and you get a compile error that may not be
easy to understand (it took me a while at least).

The solution (and I have come to believe this is a common pattern) is
to use unqualified calls, with using-statements to include implementations
for standard types and using ADL to find the custom functions in the
namespace of the user-defined class.

1. sep. 2015 kl. 15:37 skrev Carsten Gräser <graeser at mi.fu-berlin.de>:

> Hi Christian,
> 
> Am 01.09.2015 um 15:06 schrieb Christian Engwer:
>> Hi Carsten,
>> 
>> (a) the double cast is only used, if K is an integer type.
> argh, of course you're right. However the precision issue
> still persists for types that don't fit into double, e.g.,
> long long. While not even the standard guarantees the
> existence of an sqrt function which enough precision
> (long double may only have 64bit), we may want to be
> able to customize here.
> 
>> (b) fvmeta is one of the ancient artifacts that are there from the
>>    (nearly) very beginning and the design is far from nice
>> (c) I guess Peter was the inital author, but this will be kind of
>>    tricky to find out, as the content was moved around quite often.
>> (d) I currently don't see where the current code fails with user
>>    defined types.
> Up to the precision issue, I had the same impression.

I fear that is not the case, see above.

> 
>> (e) the ADL is here quite new (from june), perhaps it isn't in the
>>    release branch?
> I can't remember, that/when I merged it, but it's indeed in
> the release branch.
> 
> Carsten
> 
>> 
>> Hi Atgeirr,
>> 
>> if it fails this is definitely a bug and must be fixed. Could you
>> please send a test example.

The following program fails with current Dune, but compiles with the patch.
(It also uses the Evaluation class from opm-material, in opm/material/localad,
and that must also be changed to have an absreal method in the same namespace
as the Evaluation class (Opm::LocalAd), but that I can get in myself.)
The program itself is of course nonsense, but should demonstrate the issue.

#include "config.h"

#include <dune/common/fmatrix.hh>
#include <opm/material/localad/Evaluation.hpp>

int main()
{
  typedef Opm::LocalAd::Evaluation<double, void, 2> Evaluation;
  typedef Dune::FieldMatrix<Evaluation, 2, 2> Matrix;
  typedef Dune::FieldVector<Evaluation, 2> Vector;

  Matrix M;
  Vector x, y;
  M.solve(x, y);
  return 0;
}

>> 
>> Ciao
>> Christian
>> 
>> On Tue, Sep 01, 2015 at 02:45:48PM +0200, Carsten Gräser wrote:
>>> Dear Atgeirr,
>>> thanks for the patch. To in corporate it in dune 2.4 I'd first
>>> like to see it in the master and then merge from there. Hence
>>> I'd prefer a patch against master. However, I'm unclear if we should
>>> merge this.
>>> 
>>> It seems to me that fvmeta already uses proper adl internally.

The issue is not with the internals of fvmeta, but in the calls to the
fvmeta functions.

Atgeirr