yade-mpi team mailing list archive
Mailing list archive
Re: Coordination of next week
And thanks Bruno for that coordination point.
What about yadempi.py ? Deepak, do you think that it would be possible to
move things to mpy.py from this file also then remove it ? For example, you
could define a new optimisation flag, just like Bruno did in mpy.py.
I confirm that I will work on the third point from the todo list, but
merging files before would be great. Bruno, about python vs C++, must I
keep a full control under python (intrs find, calls with list of bodies to
exchange, etc...) or a basic python trigger is enough (sthg like
find_intrs(), exchange_bodies() ) ?
Le dim. 5 mai 2019 à 12:39, Bruno Chareyre <bruno.chareyre@xxxxxxxxxxxxxxx>
a écrit :
> Thanks Deepak.
> On Sun, 5 May 2019 at 02:24, Deepak Kn <deepak.kn1990@xxxxxxxxx> wrote:
>> I propose we keep working from mpf.py as that already deals nicely with
>> the states communication and we can use those profiling functions,
> Well... in that case rename mpf.py->mpy.py and mpy.py->mpy_old.py. But of
> course it's exactly the same. ;)
> The real question is more: are the latest changes in current mpy.py
> reflected in mpf.py? If so the merge is done and renaming as above is
> > (while keeping mpy.py as a reference for now ?)
> No need to archive old versions "for reference" since git has all previous
> versions and it's easy to roll back.
> It is not a good thing to have multiple duplicates of something.
>> (while keeping mpy.py as a reference for now ?) , what do you think
>> On Fri, May 3, 2019 at 11:34 AM Bruno Chareyre <
>> bruno.chareyre@xxxxxxxxxxxxxxx> wrote:
>>> Hi François and Deepak,
>>> As you may be both working on mpi next week I'm opening this discussion
>>> to try and coordinate.
>>> I suggest we refer to my TODO list as it appears on gitlab
>>> From recent discussions I feel that François may concentrate on point 3
>>> while Deepak may continue point 2. Do you both agree?
>>> for point 1 you will have to interact. From now on I suggest to avoid
>>> working on duplicated clones (or even duplicated branches...) since it
>>> sounds safe in the short term but it generates a lot of work for merging
>>> later. We have presently three versions of mpy.py... git is designed to
>>> handle regressions, reverts, conflicts, etc. no need to reinvent the wheel.
>>> About intersections and mirror intersections: please refrain from moving
>>> their definition+assignement to c++ too early since 1/ its's not critical
>>> since it happens only when collision detection occurs and 2/ many
>>> opimizations can be experimented (e.g. those lists contain non-necessary
>>> bodies atm, they could be updated asynchroneously,...) and that would be
>>> painful to experiment such things in C++.
>>> I actually planned to submit a 2nd hackaton subject which could be about
>>> optimal handling of these intersections and of body re-allocation, and I'd
>>> like it to not involve c++.
>>> Bruno Chareyre
>>> Associate Professor
>>> ENSE³ - Grenoble INP
>>> Lab. 3SR
>>> BP 53
>>> 38041 Grenoble cedex 9
>>> Tél : +33 4 56 52 86 21
>>> Email too brief?
>>> Here's why: email charter
>>> Mailing list: https://launchpad.net/~yade-mpi
>>> Post to : yade-mpi@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~yade-mpi
>>> More help : https://help.launchpad.net/ListHelp
> Bruno Chareyre
> Associate Professor
> ENSE³ - Grenoble INP
> Lab. 3SR
> BP 53
> 38041 Grenoble cedex 9
> Tél : +33 4 56 52 86 21
> Email too brief?
> Here's why: email charter
> Mailing list: https://launchpad.net/~yade-mpi
> Post to : yade-mpi@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~yade-mpi
> More help : https://help.launchpad.net/ListHelp