yade-mpi team mailing list archive
-
yade-mpi team
-
Mailing list archive
-
Message #00031
Re: Coordination of next week
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>
Follow ups
References