yade-mpi team mailing list archive

[Bruno Chareyre <bruno.chareyre@xxxxxxxxxxxxxxx>]

Hi,
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
enough.

> (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.

Cheers

Bruno





> (while keeping mpy.py as a reference for now ?) , what do you think
> François?
>
> 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
>> <https://gitlab.com/yade-dev/trunk/issues/68#note_165656291>.
>>
>> 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++.
>>
>> Cheers
>>
>> Bruno
>>
>>
>>
>> --
>> --
>> _______________
>> 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
>> <https://marcuselliott.co.uk/wp-content/uploads/2017/04/emailCharter.jpg>
>>
>>
>> --
>> 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
<https://marcuselliott.co.uk/wp-content/uploads/2017/04/emailCharter.jpg>