[vtk-developers] Changing floating point Types in VTK

Max Sagebaum max.sagebaum at scicomp.uni-kl.de
Wed May 20 04:58:05 EDT 2015


Hello David,

I have set up a gitlab repository with the version we have modified. I
hope the gitlab repository is ok for you.

The clone id for the repo is:
>  git at gitlab.com:MaxSagebaum/vtk-5.10.1-FloatModified.git

We started our modification with the 5.10.1 version of vtk. As we needed just
the packages verdict, kwsys, vtkCommon, vtkFiltering and vtkGraphics only these 
are modified and build for our purposes.

I provided an install script, which shows the basic steps to setup everything.
The script shows the installation of 3 variants. Basically 
VTK_unmod and VTK_double are the same. Only in VTK_adolc the floating
point type is exchanged with the ADOL-c AD type. We have also done this
for the dco AD tool but this tool is not freely available.

If you Have a look at the files Common/adDefines*, you will see the tool
specific implementations we had to do. The one for ADOL-c is quite big
because I inlined all the includes we would normally need.

The file Common/adDefinesDouble.h is very small which means that for the
normal floating point type not that much has changed.

Cheers

Max


On Tue, 2015-05-12 at 09:56 -0600, David Gobbi wrote:
> Hi Max,
> 
> 
> From your description, it sounds like this change would be very
> labour-intensive to maintain, since all future uses of floating-point
> numbers in VTK would have to follow new rules.  But I can definitely
> understand the benefit of "plug-in" floating point types (I've even
> used some VTK algorithms with custom fixed-point types in the past).
> 
> 
> Can you host your changes somewhere so that interested parties can try
> them out and provide feedback?
> 
> 
>  - David
> 
> 
> 
> On Mon, May 11, 2015 at 2:22 AM, Max Sagebaum
> <max.sagebaum at scicomp.uni-kl.de> wrote:
>         Dear developers,
>         
>         we had asked for your opinions about a typedef for the
>         floating point
>         types in vtk and if we make this change if it would be
>         accepted. Until
>         now we have received no answer. We would appreciate it, if we
>         could get
>         some insights about the acceptance of the changes we want to
>         make.
>         
>         Best regards,
>         
>         Max Sagebaum
>         
>         On Mon, 2015-04-20 at 09:04 +0200, Max Sagebaum wrote:
>         > Dear developers,
>         > we are currently using parts of the VTK Version 5.10 for our
>         CFD
>         > Postprocessing Tool. We have successfully modified theses
>         parts to
>         > facilitate an AD-Tool (Algorithmic Differentiation) to
>         differentiate
>         > these code parts (intention is to not just get absolute
>         values for our
>         > CFD-results, but also evaluate sensitivities/gradients).
>         Caused by
>         > further developments in our tool we would like to go with
>         newer
>         > VTK-Versions, which means repeating the changes in the code
>         parts
>         > facilitating AD. We would like to implement these changes
>         into the
>         > VTK-trunk, to avoid reprogramming and to offer the
>         possibility of using
>         > AD to everyone. We would like to explain the changes in
>         short and ask
>         > you to judge if such changes are likely to be accepted or if
>         there is an
>         > interest in making VTK “AD-able”. If not, we would avoid the
>         presumably
>         > laborious implementation and would not put it into the
>         Git/Develop loop.
>         >
>         > There are two main changes we had to make. To get the
>         gradients of a
>         > program, the AD-Tool defines new AD floating point types
>         which take care
>         > of the derivative computation. In order to use these AD
>         types in VTK we
>         > needed to create two typedefs for float and double. Then
>         every usage of
>         > float and double in VTK was replaced by the new typedefs.
>         With this
>         > change, it is also possible to other types in VTK. E.g.
>         complex values.
>         >
>         > The second change we made, was to rename every 'static_cast'
>         call to a
>         > new function 'perform_cast'. Basically 'perfom_cast' just
>         calls
>         > 'static_cast'. If you use other types than float or double
>         'static_cast'
>         > will complain that the conversion from eg. 'MyFloatType' to
>         'int' does
>         > not exist. 'perfom_cast' was specialized for the AD types
>         and therefore
>         > the casts could be done. During this process we checked most
>         of the
>         > occurrences of 'static_cast' and validated that the usage
>         will not break
>         > the differentiation.
>         > There are two other solutions to our approach. We could
>         implement
>         > conversion operators for the AD types, which enables
>         'static_cast' to do
>         > the conversion. But this is mostly discouraged by the tool
>         developers.
>         > If the conversion operators are implemented, the compiler
>         starts to
>         > implicit convert the AD types and very weird things can
>         happen.
>         > The second approach would define these operators as explicit
>         which would
>         > prevent the compiler from implicitly converting them. But
>         then VTK would
>         > need to be compiled with C++11 enabled or if the user
>         changes these
>         > types he also has to enable C++11 if necessary.
>         >
>         > Is the any interest on the developers or users side to use
>         VTK with AD
>         > or other floating point types?
>         > Thanks for your opinions and judgment!
>         >
>         > Max Sagebaum
>         >
>         
>         
>         --
>         Max Sagebaum
>         
>         Chair for Scientific Computing,
>         TU Kaiserslautern,
>         Bldg/Geb 34, Paul-Ehrlich-Strasse,
>         67663 Kaiserslautern, Germany
>         
>         Phone: +49 (0)631 205 5638
>         Fax:   +49 (0)631 205 3056
>         Email: max.sagebaum at scicomp.uni-kl.de
>         URL:   www.scicomp.uni-kl.de
>         
>         
>         
>         
>         
>         _______________________________________________
>         Powered by www.kitware.com
>         
>         Visit other Kitware open-source projects at
>         http://www.kitware.com/opensource/opensource.html
>         
>         Search the list archives at:
>         http://markmail.org/search/?q=vtk-developers
>         
>         Follow this link to subscribe/unsubscribe:
>         http://public.kitware.com/mailman/listinfo/vtk-developers
>         
>         
> 
> 

-- 
Max Sagebaum

Chair for Scientific Computing,
TU Kaiserslautern,
Bldg/Geb 34, Paul-Ehrlich-Strasse,
67663 Kaiserslautern, Germany

Phone: +49 (0)631 205 5638
Fax:   +49 (0)631 205 3056
Email: max.sagebaum at scicomp.uni-kl.de
URL:   www.scicomp.uni-kl.de







More information about the vtk-developers mailing list