[deprecated list] all yade users, please introduce yourself!

[Václav Šmilauer]

Hello everybody,

it seems there is quite many people using/developing yade now, but we
don't know much about you. I would like to collect this kind of
information so that we can steer in some way the development, to see
what annoys you, what you work on etc. Being open-source, yade builds on
your (that means _you_ who is just reading this, not some abstract
"you") participation and I would like to make that more intensive.

We ocasionally get such information from brave newcomers on the mailing
list (like Anton lastly -- thanks!), but I suppose there is many more
people who don't speak up for some reason.

I created a wiki page at http://yade.wikia.com/wiki/WhoIsDoingWhat ,
where I would like to ask you to tell us something about yourself and
your work. Fell free to not stick to the template and provide other
information that could interest us: your voice counts.

Please forward this message to people that are not subscribed the list
but work with/on yade, such as your master students and stagiers.

Thanks for your cooperation,

Václav


_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-***@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Václav Šmilauer]

Post by Václav Šmilauer
I created a wiki page at http://yade.wikia.com/wiki/WhoIsDoingWhat ,
where I would like to ask you to tell us something about yourself and
your work. Fell free to not stick to the template and provide other
information that could interest us: your voice counts.

Thanks for those who wrote about themselves, can others do the same as
well?

Nice to hear things that I wasn't aware of, and I perhaps need some
clarifications.

Vincent: "I don't feel good with interaction parameters that are stored
(embeded) in bodies": I am not sure what you mean here.

Bruno: "The time gain with "parallel" option is still very low". What
speedups you get? For TriaxialTest(fast=True,numberOfGrains=10000), I
have 48 vs. 28 iter/sec by setting OMP_NUM_THREADS to 4 and 1
respectively. If you have some ideas for improvements, they will be very
welcome.

Anton: "Good to have YADE deb-package in repositories.". The
infrastructure is there, https://launchpad.net/~yade-users/+archive/ppa
has (one) package, but given the speed how yade evolves and until
recently, you couldn't practically use it without writing c++ code, it
didn't make much sense to distribute binaries.

(I will paste these discussions to the wiki page WhoIsDoingWhat so that
it doesn't get lost. If you want, open bugreport/create blueprint for
those features you need. That's perhaps the best way to keep track.)

Vaclav


_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Bruno Chareyre]

Post by Václav Šmilauer
Bruno: "The time gain with "parallel" option is still very low". What
speedups you get? For TriaxialTest(fast=True,numberOfGrains=10000), I
have 48 vs. 28 iter/sec by setting OMP_NUM_THREADS to 4 and 1
respectively. If you have some ideas for improvements, they will be very
welcome.

Oh!! I still have to try this. I was only looking at this yesterday :
http://yade.wikia.com/wiki/Triaxial_Test_Parallel

Suggesting a max of 25% speedup. Has it change?

I had a few ideas, like merging geomEngineUnit and physEngineUnit (less
loops and less sync), or at least don't dispatch interactions when
i->physics exists . I tried that, it gives 3% speedup just moving
if(!interaction->interactionPhysics) from the engine unit to the dispatcher.
However, I saw you already merged geom+physics+contact law, so I gave
up... Is this merged version in the current SVN?
Btw, the scripts/test/triax-perf.py you refer to in this page in not in
the trunk.

Other questions :
I don't see any parallel command in the triaxialTest or in
ElasticContactLaw. How can it work?
Do you still have those big cpu time for the collider with 50k spheres?
I could have a few ideas for this.

Regarding paralelization, we are working on solid-fluid coupling and we
will use a solver that support parallelization for solving large linear
systems (an open source library called "taucs", used for sparse system
in mathematica, matlab, comsol and various good commercial codes). I
think it will be the good time to start using our multiproc server with
paralel Yade (I admit I did not really use this server yet...).

Post by Václav Šmilauer
Anton: "Good to have YADE deb-package in repositories.". The
infrastructure is there, https://launchpad.net/~yade-users/+archive/ppa
has (one) package, but given the speed how yade evolves and until
recently, you couldn't practically use it without writing c++ code, it
didn't make much sense to distribute binaries.

You can still run triaxial tests with various number of grains,
friction, granulometry, compacity, etc. Not a negligeable thing as the
triaxial test is the first simulation for more than 50% of the dem users
I think.

Bruno
--
_______________
Chareyre Bruno
Maitre de conference

Grenoble INP
Laboratoire 3SR - bureau E145
BP 53 - 38041, Grenoble cedex 9 - France
Tél : [phone]
Fax : [phone]
________________


_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Václav Šmilauer]

Post by Bruno Chareyre

Post by Václav Šmilauer
Bruno: "The time gain with "parallel" option is still very low". What
speedups you get? For TriaxialTest(fast=True,numberOfGrains=10000), I
have 48 vs. 28 iter/sec by setting OMP_NUM_THREADS to 4 and 1
respectively. If you have some ideas for improvements, they will be very
welcome.

http://yade.wikia.com/wiki/Triaxial_Test_Parallel
Suggesting a max of 25% speedup. Has it change?
I had a few ideas, like merging geomEngineUnit and physEngineUnit (less
loops and less sync), or at least don't dispatch interactions when
i->physics exists . I tried that, it gives 3% speedup just moving
if(!interaction->interactionPhysics) from the engine unit to the dispatcher.
However, I saw you already merged geom+physics+contact law, so I gave
up... Is this merged version in the current SVN?

Yes, since perhaps more than a month. it is the InteractionDispatchers
that is activated for TriaxialTest::fast. If you have some other ideas
for speed, add them somewhere at the bottom of
http://yade.wikia.com/wiki/Performance_Tuning

Post by Bruno Chareyre
Btw, the scripts/test/triax-perf.py you refer to in this page in not in
the trunk.

Sorry, I fixed that page. It should be examples/triax-perf/triax-perf.py
(see comments in it)

Post by Bruno Chareyre
I don't see any parallel command in the triaxialTest or in
ElasticContactLaw. How can it work?

Dispatchers handle that (either the triplet
InteractionGeometryEngineUnit, InteractionPhysicsEngineUnit,
ConstitutiveLawDispatcher; or InteractionDispatchers in one loop) with a
few openmp #pragma statemenets. The number of threads is set by the
OMP_NUM_THREADS env var in the shell.

Post by Bruno Chareyre
Do you still have those big cpu time for the collider with 50k spheres?
I could have a few ideas for this.

I didn't run that with InsertionSortCollider (it didn't exist back
then), but as seen from http://yade.wikia.com/wiki/Colliders_performace,
the collider should be about 2x faster. But it scales the same, so you
will get 80% of time in collider once you use 100k spheres again.
(BTW is it OK if I use InsertionSortCollider in TriaxialTest by default,
even without "fast"?)

Post by Bruno Chareyre
Regarding paralelization, we are working on solid-fluid coupling and we
will use a solver that support parallelization for solving large linear
systems (an open source library called "taucs", used for sparse system
in mathematica, matlab, comsol and various good commercial codes). I
think it will be the good time to start using our multiproc server with
paralel Yade (I admit I did not really use this server yet...).

(taucs has been last released in 2003, does that give you great deal of
confidence in its future?). How often are you going to solve the sparse
system? If at every step, most time will be spent there probably (unless
you have 100k+ particles). If taucs runs multi-threaded (it seems it
does), it may interact badly with openMP threads which will be allocated
independently. You will see.

Post by Bruno Chareyre

Post by Václav Šmilauer
Anton: "Good to have YADE deb-package in repositories.". The
infrastructure is there, https://launchpad.net/~yade-users/+archive/ppa
has (one) package, but given the speed how yade evolves and until
recently, you couldn't practically use it without writing c++ code, it
didn't make much sense to distribute binaries.

You can still run triaxial tests with various number of grains,
friction, granulometry, compacity, etc. Not a negligeable thing as the
triaxial test is the first simulation for more than 50% of the dem users
I think.

Hm, good point. I would like to release yade at some near future point,
just for such purposes. Please add bugs and attach them to the 0.20-0
milestone so that we can track what rests to be done. It looks more or
less stabilized now.

Vaclav


_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Bruno Chareyre]

Post by Václav Šmilauer
I didn't run that with InsertionSortCollider (it didn't exist back
then), but as seen from http://yade.wikia.com/wiki/Colliders_performace,
the collider should be about 2x faster. But it scales the same, so you
will get 80% of time in collider once you use 100k spheres again.
(BTW is it OK if I use InsertionSortCollider in TriaxialTest by default,
even without "fast"?)

Ok, I'm discovering this new collider now. 2x faster? That is good.
But I don't understand why a collider scaling with Nparticles is so bad,
other engines scale the same way don't they?
Did you implement the x/y/z threads trick for parallel collider?
Ok for using it in triaxial test.

Another option, for quasistatic simulations, is to use triangulation or
one of the old collider with radiusFactor = 1.2, and update the contact
list only once per N iterations. Depending on max velocity in the model,
N can be set to at least 10. You can adjust N during runtime
automatically if maxVel increases somewhere. In some very slow
compression tests, N could really be 50 or so.

Post by Václav Šmilauer
(taucs has been last released in 2003, does that give you great deal of
confidence in its future?). How often are you going to solve the sparse
system? If at every step, most time will be spent there probably (unless
you have 100k+ particles).

Anyway, the size of the fluid problem scales with the number of
partices. It won't be solve at each time step. Only the right-hand side
of the problem will vary at each iteration (M.X=b with b varying all the
time but M varying each N iterations, like above)

Post by Václav Šmilauer
If taucs runs multi-threaded (it seems it
does), it may interact badly with openMP threads which will be allocated
independently. You will see.

Mmmmh... Interesting, but not a very good news. Taucs works impressively
well in single thread. Do you know anything equivalent designed for openMP?

Let me ask this again before I start working on this :

I confirm that the current behaviour of ElasticContactLaw (requesting
deletion of interactions as soon as contact is lost), disable capillary
forces between distant grains.
I'm about to implement a "interactionDetectionFactor" in ElasticLaw the
same way as in
InteractingSphere2InteractingSphere4SpheresContactGeometry, and delete
interactions only if distance is larger than (r1+r2)*factor.

Anybody has a better idea?

Post by Václav Šmilauer

Post by Bruno Chareyre

Post by Václav Šmilauer
Anton: "Good to have YADE deb-package in repositories.". The
infrastructure is there, https://launchpad.net/~yade-users/+archive/ppa
has (one) package, but given the speed how yade evolves and until
recently, you couldn't practically use it without writing c++ code, it
didn't make much sense to distribute binaries.

You can still run triaxial tests with various number of grains,
friction, granulometry, compacity, etc. Not a negligeable thing as the
triaxial test is the first simulation for more than 50% of the dem users
I think.

Hm, good point. I would like to release yade at some near future point,
just for such purposes. Please add bugs and attach them to the 0.20-0
milestone so that we can track what rests to be done. It looks more or
less stabilized now.
Vaclav
_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

--
_______________
Chareyre Bruno
Maitre de conference

Grenoble INP
Laboratoire 3SR - bureau E145
BP 53 - 38041, Grenoble cedex 9 - France
Tél : [phone]
Fax : [phone]
________________


_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Václav Šmilauer]

Post by Bruno Chareyre
Ok, I'm discovering this new collider now. 2x faster? That is good.
But I don't understand why a collider scaling with Nparticles is so bad,
other engines scale the same way don't they?
Did you implement the x/y/z threads trick for parallel collider?
Ok for using it in triaxial test.

It scales N*log(N) (theoretically), and that is bad enough (black and
red curves at http://yade.wikia.com/wiki/Colliders_performace ).

It is bad because efficiency of parallelization (of the interaction
loop) grows with number of particles - as one step takes longer time,
the constant overhead of parallelization scheduling (etc) gets
proportionally smaller. And this nice effect is pretty much killed by
the collider.

Post by Bruno Chareyre
Another option, for quasistatic simulations, is to use triangulation or
one of the old collider with radiusFactor = 1.2, and update the contact
list only once per N iterations. Depending on max velocity in the model,
N can be set to at least 10. You can adjust N during runtime
automatically if maxVel increases somewhere. In some very slow
compression tests, N could really be 50 or so.

Agreed. But is there such collider written? (I know there are papers
about that.) What is the computation complexity of triangulation
collider? I know that the grid-based ones achieve O(N), but we don't
have that implemented either.

Post by Bruno Chareyre

Post by Václav Šmilauer
If taucs runs multi-threaded (it seems it
does), it may interact badly with openMP threads which will be allocated
independently. You will see.

Mmmmh... Interesting, but not a very good news. Taucs works impressively
well in single thread. Do you know anything equivalent designed for openMP?

Maybe
http://software.intel.com/en-us/intel-mkl/, but there must be more, I am
quite sure. But you can easily limit current number of threads for
openMP and allocate those to taucs, or just let the OS do the
thread-battle by itself.

Post by Bruno Chareyre
I confirm that the current behaviour of ElasticContactLaw (requesting
deletion of interactions as soon as contact is lost), disable capillary
forces between distant grains.
I'm about to implement a "interactionDetectionFactor" in ElasticLaw the
same way as in
InteractingSphere2InteractingSphere4SpheresContactGeometry, and delete
interactions only if distance is larger than (r1+r2)*factor.
Anybody has a better idea?

Before, it was the geometry functor deciding on which interaction to
delete (and there had to be IS2IS4SCGWater), now this responsibility
shifted to the constitutive law; so it is logical.

Wouldn't it be better, however, to create a separate constitutive law? I
fear a little that at some point everybody will ad his/her own
parameters into ElasticContactLaw. Maybe not grounded, though; this one
distanceFactor seems OK to me.

Don't add it to ElasticContactLaw, however, but to
ef2_Spheres_Elastic_ElasticLaw (shouldn't it be renamed to
Law2_Spheres[ContactGeometry]_Elastic[ContactInteraction]_Elastic for
clarity) and use ConstitutiveLawDispatcher/InteractionDispatchers.
ElasticContactLaw is nothing but loop around calls to
ef2_Spheres_Elastic_ElasticLaw with typecheck. Slower and
non-parallelizable.

Oh, BTW, is there agreement on having useShear by default and
progressively remove prevNormal from various InteractionPhysics classes?

Vaclav



_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Bruno Chareyre]

_ all yade users, please introduce yourself!_

OR YOU WILL BE BANNED! ;-)

Post by Václav Šmilauer

Post by Bruno Chareyre
Another option, for quasistatic simulations, is to use triangulation or
one of the old collider with radiusFactor = 1.2, and update the contact
list only once per N iterations. Depending on max velocity in the model,
N can be set to at least 10. You can adjust N during runtime
automatically if maxVel increases somewhere. In some very slow
compression tests, N could really be 50 or so.

Agreed. But is there such collider written? (I know there are papers
about that.) What is the computation complexity of triangulation
collider? I know that the grid-based ones achieve O(N), but we don't
have that implemented either.

Written? Yes, any of the colliders we have would do the job. Just set an
interval for e.g. insertionSortCollider, and run it periodically with
detectionFactor = 1.5.
During N timesteps, use the same list of interactions (some will go from
virtual to real, or real to virtual, no problem with that as long as
they can change many times).
I experimented that before with the triangulation collider, it worked
well, but it was not faster than SAPcollider for a stupid reason (*),
and I realised the same thing could be achieved with SAPcollider with
intDetectionFactor=1.5.
It needs a few adjustments in other classes now, perhaps, perhaps not.
For instance, i'm not sure requestDeletion(i) will let "i" become real
again, but this would be minimal changes.
The problem with CGAL::triangulation is its not parallel.

(*) the triangulation was fast, but iterations on all edges (i.e.
virtual contacts) was slow, because the data structure has only
vector<edge> and vector<cell>. There are workarounds but I'm not on that
now.
Soon however, we will have a triangulation in metabody to simulate flow,
so I guess it will be time to remove the collider and use the same
triangulation for flow and contact detection (in our specific problems).

Post by Václav Šmilauer
Maybe
http://software.intel.com/en-us/intel-mkl/, but there must be more, I am
quite sure. But you can easily limit current number of threads for
openMP and allocate those to taucs, or just let the OS do the
thread-battle by itself.

We will experiment, thank you for the tip. I'm not so sure a lot of
algebra libraries with parallel features are available.

Post by Václav Šmilauer
Before, it was the geometry functor deciding on which interaction to
delete (and there had to be IS2IS4SCGWater), now this responsibility
shifted to the constitutive law; so it is logical.

Note that we stopped using IS2IS4SCGWater after the intFactor was
implemented in IS2IS4SCG.
I think it is correct to define intFactor in the same law, because
anybody using more than one physical law between the same bodies would
have the same problem.

Post by Václav Šmilauer
Don't add it to ElasticContactLaw, however, but to
ef2_Spheres_Elastic_ElasticLaw (shouldn't it be renamed to
Law2_Spheres[ContactGeometry]_Elastic[ContactInteraction]_Elastic for
clarity) and use ConstitutiveLawDispatcher/InteractionDispatchers.
ElasticContactLaw is nothing but loop around calls to
ef2_Spheres_Elastic_ElasticLaw with typecheck. Slower and
non-parallelizable.

Good point.

Post by Václav Šmilauer
Oh, BTW, is there agreement on having useShear by default and
progressively remove prevNormal from various InteractionPhysics classes?

I'd prefer to keep the traditional (Cundall) incremental form for now.
The equations are simpler, especially in 3D, so it is easier to
understand what happens and implement different laws. I will change my
mind one day perhaps, but for now I feel like the incremental form is
good enough for dry friction. :)

Bruno
--
_______________
Chareyre Bruno
Maitre de conference

Grenoble INP
Laboratoire 3SR - bureau E145
BP 53 - 38041, Grenoble cedex 9 - France
Tél : [phone]
Fax : [phone]
________________


_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Václav Šmilauer]

Post by Bruno Chareyre
Written? Yes, any of the colliders we have would do the job. Just set
an interval for e.g. insertionSortCollider, and run it periodically
with detectionFactor = 1.5.
During N timesteps, use the same list of interactions (some will go
from virtual to real, or real to virtual, no problem with that as long
as they can change many times).
I experimented that before with the triangulation collider, it worked
well, but it was not faster than SAPcollider for a stupid reason (*),
and I realised the same thing could be achieved with SAPcollider with
intDetectionFactor=1.5.
It needs a few adjustments in other classes now, perhaps, perhaps not.
For instance, i'm not sure requestDeletion(i) will let "i" become real
again, but this would be minimal changes.
The problem with CGAL::triangulation is its not parallel.

We would need to define some measure of maximum velocity and adjust
collider's interval so that we wouldn't miss interactions. I am not sure
how much it would help, as number of AABB overlaps is proportional to
detectionFactor^3, whereas time savings are linear to the stride of
collider wakeups. As we have ABB overlaps in the same container as real
interactions, it will also slow down loop over interactions (shouldn't
we split that in 2 containers?). I will try to experiment with that; I
created https://blueprints.launchpad.net/yade/+spec/collider-stride to
track the idea.

"Written?"=triangulation collider. I am still not sure about legal
status of CGAL, if we may use it or not. They have something about using
it in GPL programs on their license page, but it is not very clear.
They're killing their product by those restrictions, at least for me
(too bad they have python wrappers for their lib, also).

Post by Bruno Chareyre
We will experiment, thank you for the tip. I'm not so sure a lot of
algebra libraries with parallel features are available.

There is PLENTY! At least those oofem uses are
http://glaros.dtc.umn.edu/gkhome/metis/parmetis/overview and
http://www.mcs.anl.gov/petsc/petsc-2/, which are damn good as far as I
know (see also
http://www.mcs.anl.gov/petsc/petsc-2/miscellaneous/external.html).

Post by Bruno Chareyre

Post by Václav Šmilauer
Oh, BTW, is there agreement on having useShear by default and
progressively remove prevNormal from various InteractionPhysics classes?

I'd prefer to keep the traditional (Cundall) incremental form for now.
The equations are simpler, especially in 3D, so it is easier to
understand what happens and implement different laws. I will change my
mind one day perhaps, but for now I feel like the incremental form is
good enough for dry friction. :)

Ah, nay, there is still misunderstanding here. Read
SpheresContactGeometry::updateShear and compare it to updateShearForce.
It is the _same_ incremental formulation, but it increments shear
_displacement_ (rather than _force_), which is, I think, what most
constitutive laws need (even if they are non-linear) and therefore can
use. I would like to have that incremental formulas at one place only.
(The non-incremental algo is in Dem3Dof* classes and I am quite happy
with it.)

V.


_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Bruno Chareyre]

Post by Václav Šmilauer

Post by Bruno Chareyre
We will experiment, thank you for the tip. I'm not so sure a lot of
algebra libraries with parallel features are available.

There is PLENTY! At least those oofem uses are
http://glaros.dtc.umn.edu/gkhome/metis/parmetis/overview and

Hehe, I know there are plenty, but Metis is a preconditionner, not a
solver, and in fact taucs is using Metis. ;-)
I compiled taucs and linked it with the last version of metis. And yes,
it works well, but metis is not the fastest preconditionning method for
our matrices (in single thread at least).
Taucs is actually linking with some of the libraries you see everywhere
in algebra web pages (blas, lapack, metis, atlas).

Post by Václav Šmilauer
http://www.mcs.anl.gov/petsc/petsc-2/, which are damn good as far as I
know (see also
http://www.mcs.anl.gov/petsc/petsc-2/miscellaneous/external.html).

We can't use fem/fvolumes and such codes out of the box because we are
assembling our won matrice in a non-traditional way.
If we use such programms, it is only by calling low level functions,
which in many cases means using taucs...

I saw one interesting thing in miscellaneous/external, though :

http://www.cs.utexas.edu/users/plapack/

taucs is based on lapack, but I don't think it uses plapack. plapack
will be something to consider perhaps.
Thanks.



Bruno

Post by Václav Šmilauer

Post by Bruno Chareyre

Post by Václav Šmilauer
Oh, BTW, is there agreement on having useShear by default and
progressively remove prevNormal from various InteractionPhysics classes?

I'd prefer to keep the traditional (Cundall) incremental form for
now. The equations are simpler, especially in 3D, so it is easier to
understand what happens and implement different laws. I will change
my mind one day perhaps, but for now I feel like the incremental form
is good enough for dry friction. :)

Ah, nay, there is still misunderstanding here. Read
SpheresContactGeometry::updateShear and compare it to
updateShearForce. It is the _same_ incremental formulation, but it
increments shear _displacement_ (rather than _force_), which is, I
think, what most constitutive laws need (even if they are non-linear)
and therefore can use. I would like to have that incremental formulas
at one place only. (The non-incremental algo is in Dem3Dof* classes
and I am quite happy with it.)

Oh ok. So, no problem.
Bruno
--
_______________
Chareyre Bruno
Maitre de conference

Grenoble INP
Laboratoire 3SR - bureau E145
BP 53 - 38041, Grenoble cedex 9 - France
Tél : [phone]
Fax : [phone]
________________


_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Bruno Chareyre]

Post by Bruno Chareyre
http://www.cs.utexas.edu/users/plapack/

At first sight, this is not for sparse systems (I could run out of
memory with sparse N*5(non-zeros) matrices, so forget N*N matrices...).
We need a library specialised for sparse, positive definite, symmetric
matrices. Any non-specialised lib will be slower than a specialised lib
for those matrices IMO.
But don't waste you time searching for us. :)

Bruno
--
_______________
Chareyre Bruno
Maitre de conference

Grenoble INP
Laboratoire 3SR - bureau E145
BP 53 - 38041, Grenoble cedex 9 - France
Tél : [phone]
Fax : [phone]
________________


_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Václav Šmilauer]

Post by Bruno Chareyre
But don't waste you time searching for us. :)

Eigen has sparse-system solvers (and they look quite fast, according to
their benchmarks): http://eigentuxfamily.org ; it doesn't run in
paralle, but is higly optimized c++ (using SSE2 instructions, for
instance, on machines that support it)



_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Václav Šmilauer]

Post by Václav Šmilauer
Eigen has sparse-system solvers (and they look quite fast, according to
their benchmarks): http://eigentuxfamily.org ;

oops: http://eigen.tuxfamily.org


_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Chen, Feng]

Post by Bruno Chareyre
Regarding paralelization, we are working on solid-fluid coupling and we
will use a solver that support parallelization for solving large linear
systems (an open source library called "taucs", used for sparse system
in mathematica, matlab, comsol and various good commercial codes).

Hi, Bruno:

May I ask what kind of fluid-soild coupling you are working on?

Feng Chen
Geotechnical Engineer
HNTB Federal
9100 Bluebonnet Centre Blvd Suite 301
Baton Rouge, LA 70809
http://fchen3.googlepages.com/home

[Václav Šmilauer]

Post by Chen, Feng
May I ask what kind of fluid-soild coupling you are working on?

Bruno will not answer until you are at
http://yade.wikia.com/wiki/WhoIsDoingWhat ;-)




_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Chen, Feng]

I have added my section, everyone should know I am doing what now :-)

I saw two people (Bruno and Sergei) are also working on the fluid coupling with YADE, especially Seigei, I would be gald to discuss my work with you if you are interested.
Feng Chen
Geotechnical Engineer
HNTB Federal
9100 Bluebonnet Centre Blvd Suite 301
Baton Rouge, LA 70809
http://fchen3.googlepages.com/home

________________________________

From: yade-users-bounces+fchen3=utk.edu-oU9gvf+***@public.gmane.org on behalf of Václav Smilauer
Sent: Tue 7/7/2009 3:49 PM
To: yade-users-oU9gvf+***@public.gmane.org
Subject: Re: [Yade-users] all yade users, please introduce yourself!

Post by Chen, Feng
May I ask what kind of fluid-soild coupling you are working on?

Bruno will not answer until you are at
http://yade.wikia.com/wiki/WhoIsDoingWhat ;-)




_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Bruno Chareyre]

Post by Chen, Feng
I have added my section, everyone should know I am doing what now :-)
I saw two people (Bruno and Sergei) are also working on the fluid
coupling with YADE, especially Seigei, I would be gald to discuss my
work with you if you are interested.

Sure! I suggest we don't use Yade mailing list for this specific topic,
as there is already a lot of traffic here these days (good to see btw).
In short, Emanuele Catalano is interested in internal flows in dense
packings, using finite volumes.

Bruno
--
_______________
Chareyre Bruno
Maitre de conference

Grenoble INP
Laboratoire 3SR - bureau E145
BP 53 - 38041, Grenoble cedex 9 - France
Tél : [phone]
Fax : [phone]
________________


_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Václav Šmilauer]

Post by Bruno Chareyre
Sure! I suggest we don't use Yade mailing list for this specific topic,
as there is already a lot of traffic here these days (good to see btw).

I would be also interested to see what is going on with fluids, please
do not keep that private (unless secret). Perhaps the best would that
you go to https://launchpad.net/people/+newteam to create something like
yade-fluid team; then you get mailing list to which other people can
subscribe as they will.

(In the same way as there is still the yade-python team, which was
however less successful that I hoped...)

Vaclav


_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Chen, Feng]

Hi,

I can honestly tell you what I have at this moment, the OpenFOAM solver and YADE are working well with each other, the function Sergei mentioned about exporting YADE's data to paraView is also available and working well (also one to FeatPost), you might see these screenshots in my webpage (sheet pile and fluidized bed), but there are still some internal problems with the solution equations, that is why I do not release the code at this time.

You are OK to ask me questions if you have trouble with this procedure.
Feng Chen
Geotechnical Engineer
HNTB Federal
9100 Bluebonnet Centre Blvd Suite 301
Baton Rouge, LA 70809
http://fchen3.googlepages.com/home

________________________________

From: yade-users-bounces+fchen3=utk.edu-oU9gvf+***@public.gmane.org on behalf of Bruno Chareyre
Sent: Wed 7/8/2009 9:30 AM
To: yade-users-oU9gvf+***@public.gmane.org
Subject: Re: [Yade-users] all yade users, please introduce yourself!

Post by Chen, Feng
I have added my section, everyone should know I am doing what now :-)
I saw two people (Bruno and Sergei) are also working on the fluid
coupling with YADE, especially Seigei, I would be gald to discuss my
work with you if you are interested.

Sure! I suggest we don't use Yade mailing list for this specific topic,
as there is already a lot of traffic here these days (good to see btw).
In short, Emanuele Catalano is interested in internal flows in dense
packings, using finite volumes.

Bruno

--

_______________
Chareyre Bruno
Maitre de conference

Grenoble INP
Laboratoire 3SR - bureau E145
BP 53 - 38041, Grenoble cedex 9 - France
Tél : [phone]
Fax : [phone]
________________


_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Václav Šmilauer]

Post by Chen, Feng
I can honestly tell you what I have at this moment, the OpenFOAM
solver and YADE are working well with each other, the function Sergei
mentioned about exporting YADE's data to paraView is also available
and working well (also one to FeatPost),

WHAT?? You have export to paraView on which I almost started working and
that code is not in trunk? Come on, man! ;-) It is OK if the code is not
perfect (that's what trunk is for), but duplicating other's work feels,
to say the least, unconfortable.

(BTW, you have many interesting things on the webpage)

V.


_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Bruno Chareyre]

Wait! Vincent wrote code for paraview as well...

Post by Václav Šmilauer

Post by Chen, Feng
I can honestly tell you what I have at this moment, the OpenFOAM
solver and YADE are working well with each other, the function Sergei
mentioned about exporting YADE's data to paraView is also available
and working well (also one to FeatPost),

WHAT?? You have export to paraView on which I almost started working and
that code is not in trunk? Come on, man! ;-) It is OK if the code is not
perfect (that's what trunk is for), but duplicating other's work feels,
to say the least, unconfortable.
(BTW, you have many interesting things on the webpage)
V.
_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

--
_______________
Chareyre Bruno
Maitre de conference

Grenoble INP
Laboratoire 3SR - bureau E145
BP 53 - 38041, Grenoble cedex 9 - France
Tél : [phone]
Fax : [phone]
________________


_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Vincent Richefeu]

Post by Bruno Chareyre
Wait! Vincent wrote code for paraview as well...

Remember. It was just prototype code for a data-structure based one
CGAL.

Post by Bruno Chareyre

Post by Václav Šmilauer

Post by Chen, Feng
I can honestly tell you what I have at this moment, the OpenFOAM
solver and YADE are working well with each other, the function Sergei
mentioned about exporting YADE's data to paraView is also available
and working well (also one to FeatPost),

WHAT?? You have export to paraView on which I almost started
working and
that code is not in trunk? Come on, man! ;-) It is OK if the code is not
perfect (that's what trunk is for), but duplicating other's work feels,
to say the least, unconfortable.
(BTW, you have many interesting things on the webpage)
V.

_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Chen, Feng]

Hi, Vaclav:

Please understand that you would have so many things to do when you graduate, and I am relocating from one state to another and the new job here takes most of my time, I even do not have time to revise a submitted manuscript :-|, and it is quite bit awkward that I do not even have a chance to learn the commands for uploading the code to the SVN, sorry for being so lazy :-) I never complain that there is no document in YADE, because I understand it is very common for many open source codes (e.g. for OpenFOAM there is even less), especially for research codes, I am still using the yade.0.11.1 (the version that require compile QGLViewer separately), because I never have time to keep up with the SVN with so many daily changes, especially changing class names or function names, as a PhD candidate, the most important thing for me is to get a correct solution for a specific problem and I am very reluctant to spend time on re-compiling of the code because another slight change in the SVN, not to mention those naming conventions, class names, etc.......

To be more detail, the code for exporting YADE's data to paraView is only within the revised OpenFOAM solver, as I have mentioned before, there is still a problem with the Navier-Stokes equation solution so I really think it improper to release the code which will confuse most people. Finally, the code for exporting YADE's data to paraView is very simple (no more than 100 lines), and I just used OpenFOAM's "foamToVTK" command to convert only the particle data (no walls) to .vtk files, it would take me a while to clean up the codes and comments even if I just release the current version. The proposed releasing time might be on August or September.

Anyway, I think YADE is really a nice code and I appreciate those original authors (especially Vaclav and Janek) for their great work, even if I do not work on research about DEM currently I am still reading the mailing list everyday but most of the time I just look at what other people are doing, if there is any problems that I can answer I will help, and I know one student in my previous department is working on the clump, and I am pretty sure he is also looking at this mailing list:-)

Please allow me one or two weeks to learn the SVN, trunk, etc, it would be difficult for me to find a time to read basic SVN tutorials, especially I need to find those tutorials myself first :-D

Feng Chen
Geotechnical Engineer
HNTB Federal
9100 Bluebonnet Centre Blvd Suite 301
Baton Rouge, LA 70809
http://fchen3.googlepages.com/home

________________________________

From: yade-users-bounces+fchen3=utk.edu-oU9gvf+***@public.gmane.org on behalf of Václav Smilauer
Sent: Wed 7/8/2009 10:14 AM
To: yade-users-oU9gvf+***@public.gmane.org
Subject: Re: [Yade-users] all yade users, please introduce yourself!

Post by Chen, Feng
I can honestly tell you what I have at this moment, the OpenFOAM
solver and YADE are working well with each other, the function Sergei
mentioned about exporting YADE's data to paraView is also available
and working well (also one to FeatPost),

WHAT?? You have export to paraView on which I almost started working and
that code is not in trunk? Come on, man! ;-) It is OK if the code is not
perfect (that's what trunk is for), but duplicating other's work feels,
to say the least, unconfortable.

(BTW, you have many interesting things on the webpage)

V.


_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Bruno Chareyre]

Post by Chen, Feng
Please understand that you would have so many things to do when you
graduate, and I am relocating from one state to another and the new
job here takes most of my time, I even do not have time to revise a
submitted manuscript :-|, and it is quite bit awkward that I do not
even have a chance to learn the commands for uploading the code to the
SVN, sorry for being so lazy :-) I never complain that there is no
document in YADE, because I understand it is very common for many open
source codes (e.g. for OpenFOAM there is even less), especially for
research codes, I am still using the yade.0.11.1 (the version that
require compile QGLViewer separately), because I never have time to
keep up with the SVN with so many daily changes, especially changing
class names or function names, as a PhD candidate, the most important
thing for me is to get a correct solution for a specific problem and I
am very reluctant to spend time on re-compiling of the code because
another slight change in the SVN, not to mention those naming
conventions, class names, etc.......

This is an interesting contribution.

Post by Chen, Feng
Please allow me one or two weeks to learn the SVN, trunk, etc, it
would be difficult for me to find a time to read basic SVN tutorials,
especially I need to find those tutorials myself first :-D

http://yade.wikia.com/wiki/Quick_subversion_tutorial :)

Bruno
--
_______________
Chareyre Bruno
Maitre de conference

Grenoble INP
Laboratoire 3SR - bureau E145
BP 53 - 38041, Grenoble cedex 9 - France
Tél : [phone]
Fax : [phone]
________________


_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Václav Šmilauer]

Post by Chen, Feng
I am still using the yade.0.11.1 (the version that require compile
QGLViewer separately), because I never have time to keep up with the
SVN with so many daily changes, especially changing class names or
function names

This is one of the reasons you should have your code in subversion,
since every time I do some changes, I am trying (of couse not always
suvccessful) to modify in the right way all the code affected.

I hope Kien is reading this also, because he addressed the same issue
(of frequently changing code) at the WhoIsDoingWhat page.

Nothing to do about that if your code sits in your computer.

Post by Chen, Feng
the most important thing for me is to get a correct solution for a
specific problem

All users are on the same boat: no one is paid just for development,
without needing results (including me). OTOH, thinking of immediate
results all the time will kill the project quite soon. There must be
some balance between long-term development and results here and now; we
are all trying to learn how to make that compromise.

Howgh ;-)

V.
_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Chen, Feng]

There must be some balance between long-term development and results here and now; we
are all trying to learn how to make that compromise.

->This is a very important and difficult question for every user :-), and this goes to the software engineering issue, we might need to learn from other larger open source projects, how they did that? Especially people like me who leave the research area but is still keeping an eye on the project.

_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Bruno Chareyre]

Post by Chen, Feng
Hi,
I can honestly tell you what I have at this moment, the OpenFOAM
solver and YADE are working well with each other, the function Sergei
mentioned about exporting YADE's data to paraView is also available
and working well (also one to FeatPost), you might see these
screenshots in my webpage (sheet pile and fluidized bed), but
there are still some internal problems with the solution equations,
that is why I do not release the code at this time.
You are OK to ask me questions if you have trouble with this procedure.

This is impressive!
We have slower (Stokes) flow and denser material than in the fluidized
bed problem. The 1D soil example you show is a good prototype of the
type of problems we want to solve.
Our mesh is tetrahedral with spheres at vertices.


What is the balance between Yade and openFOAM cpu time in your examples?

Bruno

p.s. I created a launchpad team "DEM fluid coupling", waiting approval
for the mailing list.
https://launchpad.net/~demfluid

_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Chen, Feng]

What is the balance between Yade and openFOAM cpu time in your examples?

-> I never tested that CPU time, and for my research topic, nobody cares, but I can test that :-)

Bruno

p.s. I created a launchpad team "DEM fluid coupling", waiting approval
for the mailing list.
https://launchpad.net/~demfluid

-> Thanks a lot!

_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Bruno Chareyre]

Huh?! Vàclav disabled my "reply to list" button remotely, for this
specific question!
I'm only supervising Feng, check on the wiki who is doing the PhD on
this topic and ask him. :)

Bruno

Post by Václav Šmilauer

Post by Chen, Feng
May I ask what kind of fluid-soild coupling you are working on?

Bruno will not answer until you are at
http://yade.wikia.com/wiki/WhoIsDoingWhat ;-)
_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

--
_______________
Chareyre Bruno
Maitre de conference

Grenoble INP
Laboratoire 3SR - bureau E145
BP 53 - 38041, Grenoble cedex 9 - France
Tél : [phone]
Fax : [phone]
________________


_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp

[Václav Šmilauer]

Post by Bruno Chareyre
http://yade.wikia.com/wiki/Triaxial_Test_Parallel

Updated. 58% for the collider with 50k spheres, in the "best" case. 71%
for the overall fastest case :-(



_______________________________________________
Mailing list: https://launchpad.net/~yade-users
Post to : yade-users-oU9gvf+***@public.gmane.org
Unsubscribe : https://launchpad.net/~yade-users
More help : https://help.launchpad.net/ListHelp