Charm++ parallel programming system

[Phil Miller <mille121 AT illinois.edu>]

On Fri, Sep 23, 2011 at 11:09, Evghenii Gaburov
<e-gaburov AT northwestern.edu>
 wrote:
> Is it possible there is something else missing in the documentation, 
> because I get the following errors:
>
> After I added
>
> extern module completion;
>
> into my *.ci file,  and start compiling the code (I did not add anything 
> else) (with -module completion),
> I get immediate error:
>
> myMainChare.decl.h: fatal error: completion.decl.h: No such file or 
> directory

Errr, yeah. That module is not in Charm++ 6.2. Since you're actively
developing this application, I'd recommend using the development
version of Charm++, from our repository. On mainstream platforms, it's
quite stable.

> Quick "$ find . " in charm-6.2 source files does not reveal any filenames 
> with completion word in them.
>
> Anything I am missing here?
>
> Cheers,
>  Evghenii
>
>> The documentation is missing the note on how to include that module.
>> In your ci file, you should be add the line 'extern module
>> completion;' to tell the interface generator that you'll be using the
>> completion-detection module. Then include completion.h in your source
>> file where you access it, and you'll be set.
>>
>> On Fri, Sep 23, 2011 at 10:40, Evghenii Gaburov
>> <e-gaburov AT northwestern.edu>
>>  wrote:
>>> I seeking help with  completion detection module:
>>>
>>> As described in documentation, I have the following constructor:
>>>
>>> CProxy_CompletionDetector detector = CProxy_CompletionDetector::ckNew();
>>>
>>> but at this the code fails to compile with the following error:
>>>
>>> myMainChare.cpp: error: 'CProxy_CompletionDetector' was not declared in 
>>> this scope.
>>> myMainChare.cpp: error: expected ";" before 'detector'
>>>
>>> I compile with  $charmc -module completion.
>>>
>>> Is there something I am missing?
>>>
>>> Thanks,
>>>  Evghenii
>>>
>>>
>>>
>>>
>>> On Sep 22, 2011, at 10:20 PM, Phil Miller wrote:
>>>
>>>> There's actually a mechanism that Jonathan and I added recently to do
>>>> localized completion detection, a sort of 'counting barrier'.
>>>> Simdemics is actually using it, and it seems to be working well for
>>>> them.
>>>> The documentation for it can be found at
>>>> http://charm.cs.illinois.edu/manuals/html/charm++/3_15.html#SECTION000315100000000000000
>>>> That needs to be revised slightly, to indicate that production and
>>>> consumption are both incremental processes that can potentially
>>>> overlap. In the case posited, sending a request would correspond to a
>>>> produce() call, while receiving a request and exporting data would
>>>> correspond to a consume() call. When a given chare is done making
>>>> requests, it calls done(), and eventually the library sees that all
>>>> requests have been served.
>>>>
>>>> Phil
>>>>
>>>> On Thu, Sep 22, 2011 at 22:00, Kale, Laxmikant V 
>>>> <kale AT illinois.edu>
>>>>  wrote:
>>>>> I think, in your context,  quiescence detection is the most elegant
>>>>> solution. I am curious: Why do you not like it?
>>>>>
>>>>> If you have multiple modules active at the time this exchange is
>>>>> happening, and messaging form the other modules should continue across
>>>>> this "import-export" activity, that would be one reason why QD is not a
>>>>> good solution. But that¹s not the case for you.
>>>>>
>>>>> May be the non-threaded version (CkStartQD with a callback) is better
>>>>> suited?
>>>>>
>>>>> Incidentally, how can you use MPI_Barrier in your MPI code? You wouldn't
>>>>> know when to call it, since you don't know another process is not 
>>>>> sending
>>>>> a request your way next.
>>>>>
>>>>> --
>>>>> Laxmikant (Sanjay) Kale         http://charm.cs.uiuc.edu
>>>>> <http://charm.cs.uiuc.edu/>
>>>>> Professor, Computer Science     
>>>>> kale AT illinois.edu
>>>>> 201 N. Goodwin Avenue           Ph:  (217) 244-0094
>>>>> Urbana, IL  61801-2302          FAX: (217) 265-6582
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 9/22/11 9:15 PM, "Evghenii Gaburov" 
>>>>> <e-gaburov AT northwestern.edu>
>>>>>  wrote:
>>>>>
>>>>>> Dear All,
>>>>>>
>>>>>> As a new user, who is porting his MPI code to Charm++, I have the
>>>>>> following question:
>>>>>>
>>>>>> I have a snippet of the code that requests data from remote chares, and
>>>>>> these chares need to send data to the requesting chare. There is no way
>>>>>> to know how many messages a give chare receives from remote chares 
>>>>>> with a
>>>>>> request to export data. In other words, a given chare may need to 
>>>>>> export
>>>>>> (different) data to many remote chares that request this, and this 
>>>>>> chare
>>>>>> does not know how many remote chares request the data.
>>>>>>
>>>>>> For logical consistency it is not possible to proceed with further
>>>>>> computations unless all data requested is imported/exported. This leads
>>>>>> me to issue with a global barrier, an equivalent if which,
>>>>>> MPI_Barrier(MPI_COMM_WORLD), I use in my MPI code (there does not seem 
>>>>>> to
>>>>>> be a way around such a global barrier, since this step established
>>>>>> communication graph between MPI tasks, or for Charm++ between chares,
>>>>>> which later use point-to-point communication).
>>>>>>
>>>>>> Regretfully, I fail to find the most optimal way to issue such a 
>>>>>> barrier.
>>>>>> Using CkCallbackResumeThread() won't work because the calling code 
>>>>>> (from
>>>>>> MainChare that is a [threaded] entry) also sends messages to other 
>>>>>> remote
>>>>>> chares with request to import/export data, and those themselves
>>>>>> recursively send Msg to other remote chares to export data until close
>>>>>> condition is satisified. (the depth of recursion is 2 or 3 calls to 
>>>>>> same
>>>>>> function).
>>>>>>
>>>>>> Now I use CkWaitQD() in the MainChare as a global synchronization 
>>>>>> point.
>>>>>> I was wondering if there is a more elegant solution to issue a barrier 
>>>>>> so
>>>>>> that all previous issued message completed before proceeding further.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Cheers,
>>>>>> Evghenii
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> charm mailing list
>>>>>> charm AT cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/charm
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> charm mailing list
>>>>> charm AT cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/charm
>>>>>
>>>>> _______________________________________________
>>>>> ppl mailing list
>>>>> ppl AT cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/ppl
>>>>>
>>>
>>> --
>>> Evghenii Gaburov, 
>>> e-gaburov AT northwestern.edu
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
> --
> Evghenii Gaburov, 
> e-gaburov AT northwestern.edu
>
>
>
>
>
>
>