compiling with quad precision

Hello Matthias,

I will have a look and try to compile yade with QUAD_PRECISION defined
trying to eliminate all errors. Unfortunately currently I am a bit busy, so
probably it won't be finished this week. But should be beginning of the
next week, I will inform you :-)
cheers
Jan

2013/7/31 matthias <email address hidden>

> New question #233320 on Yade:
> https://answers.launchpad.net/yade/+question/233320
>
> I want to compile yade with quad precision
> (-DCMAKE_CXX_FLAGS="-DQUAD_PRECISION"). my nummerical stability problem is
> still not solved. I tried it with some different fitness function. this
> reduces the impact of the instability, but solves not the problem. So I
> need more precision.
>
> While compiling yade I get some of these errors:
>
> In file included from
> /home/yade/trunk/yade/lib/triangulation/RegularTriangulation.h:10:0,
> from
> /home/yade/trunk/yade/lib/triangulation/Tesselation.h:9,
> from
> /home/yade/trunk/yade/lib/triangulation/TriaxialState.h:16,
> from
> /home/yade/trunk/yade/lib/triangulation/KinematicLocalisationAnalyser.hpp:15,
> from /home/yade/trunk/pkg/dem/MicroMacroAnalyser.cpp:16:
> /home/yade/trunk/yade/lib/triangulation/def_types.h:37:1: Fehler:
> Ungültige Anwendung von »sizeof« auf unvollständigen Typen
> »boost::STATIC_ASSERTION_FAILURE<false>«
> /home/yade/trunk/yade/lib/triangulation/def_types.h:37:1: Fehler:
> Templateargument 1 ist ungültig
> /home/yade/trunk/yade/lib/triangulation/def_types.h:37:54: Fehler: invalid
> type in declaration before »;« token
> /home/yade/trunk/pkg/dem/MicroMacroAnalyser.cpp: In Elementfunktion
> »CGT::TriaxialState& MicroMacroAnalyser::makeState(unsigned int, const
> char*)«:
> /home/yade/trunk/pkg/dem/MicroMacroAnalyser.cpp:141:61: Fehler: keine
> passende Funktion für Aufruf von »min(const result_type&, long double)«
>
> I know i want to use an experimental feature. But is there a version which
> could be build with this option, or must I repair the code be hand.
>
>
> --
> You received this question notification because you are a member of
> yade-users, which is an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp
>

Hello (Bruno),

the problem (as Matthias' error says) in
file yade/lib/triangulation/def_types.h. Specifically sizeof(Traits::RT)
does not equal long double (which is typedefed as Real in
lib/base/Math.hpp). Would it be somehow possible to use TraitsReal instead
of Real in the plasces where it is used in lib/trangulation? Or possibly
some conversion from long double to ordinary double where it would be
needed?
cheers
Jan

2013/8/1 Jan Stránský <email address hidden>

> Question #233320 on Yade changed:
> https://answers.launchpad.net/yade/+question/233320
>
> Status: Open => Answered
>
> Jan Stránský proposed the following answer:
> Hello Matthias,
>
> I will have a look and try to compile yade with QUAD_PRECISION defined
> trying to eliminate all errors. Unfortunately currently I am a bit busy, so
> probably it won't be finished this week. But should be beginning of the
> next week, I will inform you :-)
> cheers
> Jan
>
>
>
> 2013/7/31 matthias <email address hidden>
>
> > New question #233320 on Yade:
> > https://answers.launchpad.net/yade/+question/233320
> >
> > I want to compile yade with quad precision
> > (-DCMAKE_CXX_FLAGS="-DQUAD_PRECISION"). my nummerical stability problem
> is
> > still not solved. I tried it with some different fitness function. this
> > reduces the impact of the instability, but solves not the problem. So I
> > need more precision.
> >
> > While compiling yade I get some of these errors:
> >
> > In file included from
> > /home/yade/trunk/yade/lib/triangulation/RegularTriangulation.h:10:0,
> > from
> > /home/yade/trunk/yade/lib/triangulation/Tesselation.h:9,
> > from
> > /home/yade/trunk/yade/lib/triangulation/TriaxialState.h:16,
> > from
> >
> /home/yade/trunk/yade/lib/triangulation/KinematicLocalisationAnalyser.hpp:15,
> > from /home/yade/trunk/pkg/dem/MicroMacroAnalyser.cpp:16:
> > /home/yade/trunk/yade/lib/triangulation/def_types.h:37:1: Fehler:
> > Ungültige Anwendung von »sizeof« auf unvollständigen Typen
> > »boost::STATIC_ASSERTION_FAILURE<false>«
> > /home/yade/trunk/yade/lib/triangulation/def_types.h:37:1: Fehler:
> > Templateargument 1 ist ungültig
> > /home/yade/trunk/yade/lib/triangulation/def_types.h:37:54: Fehler:
> invalid
> > type in declaration before »;« token
> > /home/yade/trunk/pkg/dem/MicroMacroAnalyser.cpp: In Elementfunktion
> > »CGT::TriaxialState& MicroMacroAnalyser::makeState(unsigned int, const
> > char*)«:
> > /home/yade/trunk/pkg/dem/MicroMacroAnalyser.cpp:141:61: Fehler: keine
> > passende Funktion für Aufruf von »min(const result_type&, long double)«
> >
> > I know i want to use an experimental feature. But is there a version
> which
> > could be build with this option, or must I repair the code be hand.
> >
> >
> > --
> > You received this question notification because you are a member of
> > yade-users, which is an answer contact for Yade.
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~yade-users
> > Post to : <email address hidden>
> > Unsubscribe : https://launchpad.net/~yade-users
> > More help : https://help.launchpad.net/ListHelp
> >
>
> --
> You received this question notification because you are a member of
> yade-users, which is an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp
>

what is the state of this issue? i tried to compile yae this morning again, but the error is still the same
matthias

Hello Mathias,

the status of the problem did not change. The problem is in

yade/lib/triangulation/def_types.h

file, which I have no experience with. Therefore we need some advice/hint
from somebody a bit familiar with it..
cheers
Jan

2013/8/20 matthias <email address hidden>

> Question #233320 on Yade changed:
> https://answers.launchpad.net/yade/+question/233320
>
> Status: Answered => Open
>
> matthias is still having a problem:
> what is the state of this issue? i tried to compile yae this morning
> again, but the error is still the same
> matthias
>
> --
> You received this question notification because you are a member of
> yade-users, which is an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp
>

Hi,
Yes, the template parameters of the CGAL module can surely be changed. I confess it is not quite cleanly implemented.
Plus even if I asked my students to use "Real" everywhere, they keep typing some "double" in their code, so that there is a tedious handwork to switch all the number types.

Fortunately for Mathias, this would be overkill to change the number types in this part of the code.
Disable CGAL feature at compile time, then def_types.h will be ignored. :)

Bruno

disabling of CGAL leads to this error

In file included from /home/yade/trunk/lib/triangulation/Tenseur3.h:4:0,
                 from /home/yade/trunk/lib/triangulation/Tenseur3.cpp:2,
                 from /home/yade/trunk/lib.6.cpp:1:
/home/yade/trunk/lib/triangulation/def_types.h:37:1: Fehler: Ungültige Anwendung von »sizeof« auf unvollständigen Typen »boost::STATIC_ASSERTION_FAILURE<false>«
/home/yade/trunk/lib/triangulation/def_types.h:37:1: Fehler: Templateargument 1 ist ungültig
/home/yade/trunk/lib/triangulation/def_types.h:37:54: Fehler: invalid type in declaration before »;« token

maybe this issue is in some more type definitions

matthias

You did not disable it apparently. Try a fresh build and make sure cgal is disabled by inspecting cmake output (enabled/disabled features are listed at the end of the output).

Yes, i did this. CGAL was not in the feature list

-- CGAL NOT found
-- CGAL NOT found: PFVFLOW disabled

-- Yade configured with following features: Eigen3 VTK OpenMP GTS GUI GL2PS
-- Disabled features: CGAL PFVflow LinSolv

So, this is compilation bug, sorry. :(
CMake should not even read the triangulation folder when CGAL is disabled.
Not sure if the bug was here for quite a long time or if recent changes in the build system are the cause.
We will have to find out.

I think you can simply delete al files in lib/triangulation to be sure the compiler will not try anything with them.

B

there is also an error
/home/yade/trunk/lib.6.cpp:1:58: Schwerwiegender Fehler: /home/yade/trunk/lib/triangulation/Tenseur3.cpp: File or Directory not found

Then goto #7.
"Try a fresh build"

You cannot have /home/yade/trunk/lib.6.cpp pointing to Tenseur3.cpp if it is not in sources.
"Fresh" means delete completely what's in your build directory, then cmake. There is maybe be no compilation bug.

2013/8/21 Bruno Chareyre <email address hidden>

> Question #233320 on Yade changed:
> https://answers.launchpad.net/yade/+question/233320
>
> Bruno Chareyre proposed the following answer:
> So, this is compilation bug, sorry. :(
> CMake should not even read the triangulation folder when CGAL is disabled.
> Not sure if the bug was here for quite a long time or if recent changes in
> the build system are the cause.
> We will have to find out.
>
> From my point of view, there is no bug. Files in triangulation-folder
should be picked up
only if CGAL and GMP are found and CGAL is enabled [1].

But it should be tested in a clean build-directory, of course.

[1] https://github.com/yade/trunk/blob/master/CMakeLists.txt#L201

Cheers,

Anton

> Files in triangulation-folder should be picked up only if CGAL and GMP are found and CGAL is enabled

Exactly. Then I thought to a bug because it was picked up without CGAL.
I suspect this was only due to a dirty build dir. Matthias will tell us.

this is a try from yesterdays newly checked out trunk with disabled GUI CGAL GTS PFVflow (sometimes PFVflow enables CGAL because its dependency, maybe this is the reason, why CGAL is erroneously picked up)

In file included from /home/yade/trunk/lib.0.cpp:8:0:
/home/yade/trunk/lib/opengl/GLUtils.cpp: In statischer Elementfunktion »static void GLUtils::QGLViewer::drawArrow(const Vector3r&, const Vector3r&, float, int)«:
/home/yade/trunk/lib/opengl/GLUtils.cpp:56:43: Fehler: »Eigen::PlainObjectBase<Eigen::Matrix<long double, 3, 3> >::Scalar* {aka long double*}« kann nicht nach »const GLdouble* {aka const double*}« für Argument »1« nach »void glMultMatrixd(const GLdouble*)« umgewandelt werden

the next two weeks i'm on vacations, but in the 2nd september week, i'm with my (annoying) questions

matthias

I will have a look and try to repair all places with this problem. Two
weeks should be enogh time :-)
Jan

2013/8/23 matthias <email address hidden>

> Question #233320 on Yade changed:
> https://answers.launchpad.net/yade/+question/233320
>
> Status: Answered => Open
>
> matthias is still having a problem:
> this is a try from yesterdays newly checked out trunk with disabled GUI
> CGAL GTS PFVflow (sometimes PFVflow enables CGAL because its dependency,
> maybe this is the reason, why CGAL is erroneously picked up)
>
> In file included from /home/yade/trunk/lib.0.cpp:8:0:
> /home/yade/trunk/lib/opengl/GLUtils.cpp: In statischer Elementfunktion
> »static void GLUtils::QGLViewer::drawArrow(const Vector3r&, const
> Vector3r&, float, int)«:
> /home/yade/trunk/lib/opengl/GLUtils.cpp:56:43: Fehler:
> »Eigen::PlainObjectBase<Eigen::Matrix<long double, 3, 3> >::Scalar* {aka
> long double*}« kann nicht nach »const GLdouble* {aka const double*}« für
> Argument »1« nach »void glMultMatrixd(const GLdouble*)« umgewandelt werden
>
> the next two weeks i'm on vacations, but in the 2nd september week, i'm
> with my (annoying) questions
>
> matthias
>
> --
> You received this question notification because you are a member of
> yade-users, which is an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp
>

By the way, would it be ok for you to change the language of compiler
errors to English? :-)

2013/8/23 Jan Stránský <email address hidden>

> Question #233320 on Yade changed:
> https://answers.launchpad.net/yade/+question/233320
>
> Status: Open => Answered
>
> Jan Stránský proposed the following answer:
> I will have a look and try to repair all places with this problem. Two
> weeks should be enogh time :-)
> Jan
>
>
> 2013/8/23 matthias <email address hidden>
>
> > Question #233320 on Yade changed:
> > https://answers.launchpad.net/yade/+question/233320
> >
> > Status: Answered => Open
> >
> > matthias is still having a problem:
> > this is a try from yesterdays newly checked out trunk with disabled GUI
> > CGAL GTS PFVflow (sometimes PFVflow enables CGAL because its dependency,
> > maybe this is the reason, why CGAL is erroneously picked up)
> >
> > In file included from /home/yade/trunk/lib.0.cpp:8:0:
> > /home/yade/trunk/lib/opengl/GLUtils.cpp: In statischer Elementfunktion
> > »static void GLUtils::QGLViewer::drawArrow(const Vector3r&, const
> > Vector3r&, float, int)«:
> > /home/yade/trunk/lib/opengl/GLUtils.cpp:56:43: Fehler:
> > »Eigen::PlainObjectBase<Eigen::Matrix<long double, 3, 3> >::Scalar* {aka
> > long double*}« kann nicht nach »const GLdouble* {aka const double*}« für
> > Argument »1« nach »void glMultMatrixd(const GLdouble*)« umgewandelt
> werden
> >
> > the next two weeks i'm on vacations, but in the 2nd september week, i'm
> > with my (annoying) questions
> >
> > matthias
> >
> > --
> > You received this question notification because you are a member of
> > yade-users, which is an answer contact for Yade.
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~yade-users
> > Post to : <email address hidden>
> > Unsubscribe : https://launchpad.net/~yade-users
> > More help : https://help.launchpad.net/ListHelp
> >
>
> --
> You received this question notification because you are a member of
> yade-users, which is an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp
>

yes of course, I translate this error messages, some mesages from gcc are english some german...

> In file included from /home/yade/trunk/lib.0.cpp:8:0:
> /home/yade/trunk/lib/opengl/GLUtils.cpp: in static elementary function
> »static void GLUtils::QGLViewer::drawArrow(const Vector3r&, const Vector3r&, float, int)«:
> /home/yade/trunk/lib/opengl/GLUtils.cpp:56:43: Error:
> »Eigen::PlainObjectBase<Eigen::Matrix<long double, 3, 3> > ::Scalar* {aka long double*}« could not be converted from
> »constGLdouble* {aka const double*}« argument »1« to »void >glMultMatrixd(const GLdouble*)«

GTS and GUI have some type errors, too. but these features i do not need for automatic optimization

Matthias

This error was understandable, but for future please use english :-) I will
correct all problems (including gts and vtk), except for cgal related
files, that ones maybe later..
Jan

2013/8/23 matthias <email address hidden>

> Question #233320 on Yade changed:
> https://answers.launchpad.net/yade/+question/233320
>
> matthias posted a new comment:
> yes of course, I translate this error messages, some mesages from gcc
> are english some german...
>
> > In file included from /home/yade/trunk/lib.0.cpp:8:0:
> > /home/yade/trunk/lib/opengl/GLUtils.cpp: in static elementary function
> > »static void GLUtils::QGLViewer::drawArrow(const Vector3r&, const
> Vector3r&, float, int)«:
> > /home/yade/trunk/lib/opengl/GLUtils.cpp:56:43: Error:
> > »Eigen::PlainObjectBase<Eigen::Matrix<long double, 3, 3> > ::Scalar*
> {aka long double*}« could not be converted from
> > »constGLdouble* {aka const double*}« argument »1« to »void
> >glMultMatrixd(const GLdouble*)«
>
> GTS and GUI have some type errors, too. but these features i do not need
> for automatic optimization
>
> Matthias
>
> --
> You received this question notification because you are a member of
> yade-users, which is an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp
>

 Hi Jan,
now I'm back and read this good message. I tried this immediately to compile it. the actual trunk will not work, so i tried the revision of 23th august. Compilation finishes (with some warnings)...fine. But starting "yadequad" ends up with a python error:

Welcome to Yade Unknown
Traceback (most recent call last):
  File "/usr/local/bin/yadequad", line 115, in <module>
    import yade
  File "/usr/local/lib/x86_64-linux-gnu/yadequad/py/yade/__init__.py", line 93, in <module>
    import utils # some others?
  File "/usr/local/lib/x86_64-linux-gnu/yadequad/py/yade/utils.py", line 27, in <module>
    from yade._utils import *
TypeError: No to_python (by-value) converter found for C++ type: Eigen::Matrix<long double, 3, 1, 0, 3, 1>

Good point, I only focused on compilation, not startup :-) I will try to do
the update, but currently I am a bit busy, so I am not sure when it will
be..
cheers
Jan

2013/9/9 matthias <email address hidden>

> Question #233320 on Yade changed:
> https://answers.launchpad.net/yade/+question/233320
>
> Status: Answered => Open
>
> matthias is still having a problem:
> Hi Jan,
> now I'm back and read this good message. I tried this immediately to
> compile it. the actual trunk will not work, so i tried the revision of 23th
> august. Compilation finishes (with some warnings)...fine. But starting
> "yadequad" ends up with a python error:
>
> Welcome to Yade Unknown
> Traceback (most recent call last):
> File "/usr/local/bin/yadequad", line 115, in <module>
> import yade
> File "/usr/local/lib/x86_64-linux-gnu/yadequad/py/yade/__init__.py",
> line 93, in <module>
> import utils # some others?
> File "/usr/local/lib/x86_64-linux-gnu/yadequad/py/yade/utils.py", line
> 27, in <module>
> from yade._utils import *
> TypeError: No to_python (by-value) converter found for C++ type:
> Eigen::Matrix<long double, 3, 1, 0, 3, 1>
>
> --
> You received this question notification because you are a member of
> yade-users, which is an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp
>

hi jan,
whats' the state of the 'quad project' ?

Matthias

Hi Matthias,
I had to do different things recently, but I will have a look today :-)
Jan

2013/10/9 matthias <email address hidden>

> Question #233320 on Yade changed:
> https://answers.launchpad.net/yade/+question/233320
>
> Status: Answered => Open
>
> matthias is still having a problem:
> hi jan,
> whats' the state of the 'quad project' ?
>
> Matthias
>
> --
> You received this question notification because you are a member of
> yade-users, which is an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp
>

Hello Matthias,

with the lastest trunk version I was able to compile and launch yade
without problems.. What minieigen do you use? the yade version, or the
external package? (you can post the console output of you cmake command,
the information should be there).
Thanks
Jan

2013/10/9 Jan Stránský <email address hidden>

> Question #233320 on Yade changed:
> https://answers.launchpad.net/yade/+question/233320
>
> Status: Open => Answered
>
> Jan Stránský proposed the following answer:
> Hi Matthias,
> I had to do different things recently, but I will have a look today :-)
> Jan
>
>
> 2013/10/9 matthias <email address hidden>
>
> > Question #233320 on Yade changed:
> > https://answers.launchpad.net/yade/+question/233320
> >
> > Status: Answered => Open
> >
> > matthias is still having a problem:
> > hi jan,
> > whats' the state of the 'quad project' ?
> >
> > Matthias
> >
> > --
> > You received this question notification because you are a member of
> > yade-users, which is an answer contact for Yade.
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~yade-users
> > Post to : <email address hidden>
> > Unsubscribe : https://launchpad.net/~yade-users
> > More help : https://help.launchpad.net/ListHelp
> >
>
> --
> You received this question notification because you are a member of
> yade-users, which is an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp
>

yes with the minieigen version of yade the compilation and running works.

here is a first taste of long double results
 long double double
 0,8793 0,8334
 0,8826 0,8805
 0,8223 0,8457
 0,9297 0,8808
 0,8313 0,9003
 0,9039 0,822
 0,912 0,8958
 0,8637 0,9246
 0,8718 0,9153
 0,8667 0,8409
 0,858 0,8328
 0,8658 0,8103
 0,8481 0,8625
 0,8457 0,8766
 0,8598 0,8574
 0,8667 0,9744
 0,9195 0,7809
 0,9144 0,8151
 0,9276 0,8172
 0,879 0,864

mean 0,877395 0,861525
median 0,86925 0,85995
std 0,0313071957 0,0460952889

so the long double version of yade has a quite lower standard deviation of a fitness function defined on a model. this is of course no general result, but it helps me to run fewer replications through an optimization

> std 0,0313071957 0,0460952889

hi matthias,

thanks for this interesting results.
that means quad precision shows nearly no effect on standard deviation in multithreading?

amazing!

Cheers,

Christian

Interesting. Thanks for feedback. Would you tell us again what sort of calculation that is?

@Christian
this standard deviation is the standard deviation of the posted data columns. so of course, also long double multithreaded simulation is affected by floating point indeterminism, but fewer than double or single floats

i test this with 1000 clumps (with 3 spheres) flowing through an hopper within my packaging machine model during 183335 iteration, this data values are fitness values whichs represent how 'compact' the particles flow through the hopper

more details next week

> this standard deviation is the standard deviation of the posted data columns.

yes, i followed this discussion from the beginning.

> so of course, also
> long double multithreaded simulation is affected by floating point indeterminism, but fewer
> than double or single floats

right. i meant, that the difference 0,046 - 0,031 = 0,015 is not as high as expected (at least by me).

could you (as far as your time allows) please check indeterminism differences (double vs. long double) with maximum/minimum body forces at particles?
e.g. at end of your simulation ...

On the other hand, (stdDevNew-stdDevOld)/stdDevNew =approx 1/2, which might
be considerable..
Cheers
Jan
Dne 11.10.2013 17:46 "Christian Jakob" <email address hidden>
napsal(a):

> Question #233320 on Yade changed:
> https://answers.launchpad.net/yade/+question/233320
>
> Christian Jakob posted a new comment:
> > this standard deviation is the standard deviation of the posted data
> columns.
>
> yes, i followed this discussion from the beginning.
>
> > so of course, also
> > long double multithreaded simulation is affected by floating point
> indeterminism, but fewer
> > than double or single floats
>
> right. i meant, that the difference 0,046 - 0,031 = 0,015 is not as high
> as expected (at least by me).
>
> could you (as far as your time allows) please check indeterminism
> differences (double vs. long double) with maximum/minimum body forces at
> particles?
> e.g. at end of your simulation ...
>
> --
> You received this question notification because you are a member of
> yade-users, which is an answer contact for Yade.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~yade-users
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~yade-users
> More help : https://help.launchpad.net/ListHelp
>

could you (as far as your time allows) please check indeterminism differences (double vs. long double) with maximum/minimum body forces at particles?
e.g. at end of your simulation ...

could you define your desired data? maybe post a funcion which i can apply on my simulation runs

maxF = 0.0
minF = 1e9
for b in O.bodies:
 F = O.forces.f(b.id)
 maxF = max(maxF,F.norm())
 minF = min(minF,F.norm())

ok, i will do this. but is takes some time

so, i did some runs with long double and double with 1,2 and 4 threads. at the beginning, the and and every 1000 iterations i run that code from above. the result is ambiguous. i can't see any difference.

@christian i mail you that raw data, maybe you could find whatever you look for

"can't see any difference" means the results are all exactly the same in all simulations, or there is approximately the same indeterminism with double and quad?
I would not be really surprised by the latest. It was actually my first guess when you came up with this question on quad precision.
Still to confirm with more stats.

"can't see any difference" means i can't recognize any different in the force output. so the indeterminism ALONG some runs are maybe the same. therefore you are right. but i distinguish between the indeterminism along one run and the indeterminism between fitness values of some replications. and therefore i think longer floats are better for this application because you shift the indeterministic operations "less significant" ranges.

but bruno, you can propose some other experiements to test that approach

a further comment related to post #25:
the half 0.95 confidence interval width for the double column is 0.0202
the half 0.95 confidence interval width for the long double column is 0.0137

if i would have the confidence level of the "double results", in this example i need only 11 long double to have the same confidence level (0.0191, calculated from the first 11 replications)

@Mattias,
I don't have precise experiments to suggest unfortunately. I'm only speculating.

I've read you *.ods sheet (thanks). If I guess correctly, what it shows is that indeterminacy is of similar amplitude on max force if you compare "double" runs between them and "quad" runs between them.

My interpretation is that any small difference between two states gives completely different results after some time but at the same time the result is bounded by physical constraints. So what you see is not the magnitude of rounding errors, it is the range of physically acceptable configurations, as if indeterminacy was deeply rooted in the problem.

Now the thing that doesn't fit in this picture is #25, where you find different behaviour for the bulk material. A question is if the difference in std deviation is obtained with a sufficient number of results. It may be just luck that you get a smaller one with quads.

i think at this point, we should examine the impact of that data types. so please propose somewhat like a model, number of spheres and iterations,...

this is my proposal :
- maybe 5000 sphere are flowing out of an hopper over maybe 150000 iterations. not more sphere because of computation time.
- defining a objective Function. this function must defined on all spheres, if its depends on only some sphere, the functions values are too noisy. the values of #25 ware generated in the following way:
i defined a plane a little bit below the hopper. every i iterations (for i \in {1...50}) is measure which sphere passed the plane and store that timestamp (or iteration number). in the end of a run i calculate the std-dev on this set.

\ /
 \******/
  \*****/
   \****/
    \***/
      **
  ------- <- measure timestamp here
     ++

this objective function should represent how 'compact' the spheres are flowing out.

during a run could Fmean logged or somelike other...
maybe 50 or 100 replications per data type (wich 2 threads, because more threads have too much overhead [and 8 threads are much slower then 4 threads, using real parallel algorithms are a quiet good idea]) should be enough.

what do you think about this?

hi guys,
i tried this proposal of post #40 with some surprising results. i ran 100 replication with 2 threads on an intel and an amd machine.

cpu; data type;min;avg;max;std-dev
Intel(R) Core(TM) i7-3770;double;0,1135;0,3479;0,3706;0,0248
Intel(R) Core(TM) i7-3770;long double;0,3331;0,3555;0,3771;0,0070
AMD FX(tm)-8350 Eight-Core Processor ; double;0,3346;0,3500;0,3613;0,0059

the long double version i compiled only on my intel machine, so there are no result for th amd machine. the realy surprising thing is, the amd results are similar to the intel long double ones. so on my machine i get an increase of accuracy.

i have no explanation, why the results of the amd double experiment are significant better than the intel double results. so the overall conclusion is, it's depends on the cpu how good/accurate/noisy are the results.

Thanks Jan Stránský, that solved my question.

The real meaning of "double" and "long double" is hardware dependent. Some 64-bits architectures will give long double when you ask double. Check below a random google result on this aspect.

http://stackoverflow.com/questions/8922216/why-are-double-and-long-double-completely-the-same-on-my-64-bit-machine