Johan Hake wrote:
> On Wednesday 06 May 2009 21:10:50 Garth N. Wells wrote:
>> On May 6 2009, Martin Sandve Alnæs wrote:
>>> On Wed, May 6, 2009 at 8:45 PM, Johan Hake <[email protected]> wrote:
>>>> On Wednesday 06 May 2009 14:07:11 DOLFIN wrote:
>>>>> One or more new changesets pushed to the primary dolfin repository.
>>>>> A short summary of the last three changesets is included below.
>>>>>
>>>>> changeset: 6098:4b3c43f72124bd0be03b6eaa0d7d2dd1f7b03d65 tag:
>>>>> tip user: "Garth N. Wells <[email protected]>" date: Wed
>>>>> May 06 13:06:55 2009 +0100 files: dolfin/la/BlockVector.cpp
>>>>> dolfin/la/BlockVector.h dolfin/la/EpetraVector.cpp
>>>>> dolfin/la/EpetraVector.h dolfin/la/GenericVector.h
>>>>> dolfin/la/MTL4Vector.cpp dolfin/la/MTL4Vector.h
>>>>> dolfin/la/PETScLUSolver.cpp dolfin/la/PETScMatrix.cpp
>>>>> dolfin/la/PETScMatrix.h dolfin/la/PETScVector.cpp
>>>>> dolfin/la/PETScVector.h dolfin/la/Vector.h dolfin/la/enums_la.h
>>>>> dolfin/la/solve.cpp dolfin/la/uBLASVector.cpp dolfin/la/uBLASVector.h
>>>>> dolfin/nls/NewtonSolver.cpp dolfin/ode/MonoAdaptiveNewtonSolver.cpp
>>>>> dolfin/ode/MultiAdaptiveNewtonSolver.cpp
>>>>> site-packages/dolfin/__init__.py site-packages/dolfin/errornorm.py
>>>>> description: Some enum -> std::string for la norms.
>>>> The nice thing with enums was that I could easily get hold of the
>>>> possible values. I just took a look in enum_la.h.
>>> And a decent editor could do auto-completion as well.
>>>
>>>> Now I have to look into the
>>>> different .cpp files and scan the 'if' statements.
>> This still needs to be documented in the header files.
>
> So documentation of this will be added?
>
Yes. The supported solvers and preconditioners should be listed at the
top of the relevant header files.
>>>> Could we predefine some variables for this purpose? Something like this
>>>> for preconditioners:
>>>>
>>>> std::string no_prec("no_prec"); // Instead of "none" due to PyDOLFIN?
>>>> std::string jacobi("jacobi");
>>>> std::string sor("sor");
>>>> std::string ilu("ilu");
>>>> std::string icc("icc");
>>>> std::string amg_hypre("amg_hypre");
>>>> std::string amg_ml("amg_ml");
>>>> std::string default("default");
>>> Then what's the point of using strings instead of enums?
>>> Could just as well use enums and make
>>> enum-to-string-to-enum utilities for file handling and printing.
>> - enums are a bit clumsy to use - enums are not wrapped automatically for
>> the Python interfface - we can use the string "none" in the Python
>> interface (?) - the diversity of linear algebra backends; the enum list can
>> become very long with solvers, precondintioners, etc which may only be
>> supported by one backend.
>
> Enums are actually wrapped to python but as ints.
This is what C++ does internally.
Garth
So we had some problems with
> function overloading when swig couldn't sort out of some of the resulting
> function signatures.
>
>>>> If I misspell the string I will not get an error but rather the default
>>>> version. Predefined variables will help for this.
>> Only in the Epetra backend as far as I know (which I didn't write). The
>> others throw an error.
>
> Yes, my error.
>
> Johan
>
>> Garth
>>
>>>> I parameter system with "allowed" values would ofcourse solve this.
>>> Yes, warnings or errors when using invalid strings is simply a must have.
>>>
>>> Martin
>>> _______________________________________________
>>> DOLFIN-dev mailing list
>>> [email protected]
>>> http://www.fenics.org/mailman/listinfo/dolfin-dev
>
>
_______________________________________________
DOLFIN-dev mailing list
[email protected]
http://www.fenics.org/mailman/listinfo/dolfin-dev
