[Swift-devel] block allocation

[Zhao Zhang]

Hi, Mihael

Here comes another question about the definition of "block 
allocation".From my understanding, "block allocation" is that we grab 
bunch of
resources, then run workflowS on it without request the resource again.
Say, we request 1K compute nodes from a cluster, then we run a dock6 
workflow on it, after that we run a blast workflow on the same allocation.
Is my understanding correct?

In the current coaster design, coaster seems deallocate the resources 
after A workflow is done. So, next time when I tried to run another 
workflow,
I have to run it on a new allocation instead of the one we have already 
had in hand. Or is there any options we could set in coaster and could have
both the approaches? Thanks.

best
zhao

Mihael Hategan wrote:
> You should check whether blocks are properly de-allocated when all the
> work is done.
>
> On Wed, 2009-05-27 at 18:10 -0500, Zhao Zhang wrote:
>   
>> Sorry, Mihael, I didn't get your last question.
>>
>> zhao
>>
>> Mihael Hategan wrote:
>>     
>>> On Wed, 2009-05-27 at 17:33 -0500, Zhao Zhang wrote:
>>>   
>>>       
>>>> Mihael Hategan wrote:
>>>>     
>>>>         
>>>>> On Wed, 2009-05-27 at 16:49 -0500, Zhao Zhang wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> Mihael Hategan wrote:
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> On Wed, 2009-05-27 at 16:31 -0500, Zhao Zhang wrote:
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>>>> Hi, Mihael
>>>>>>>>
>>>>>>>> I did a clean run of 100 scip jobs on ranger. (scip is a new application 
>>>>>>>> from MCS).
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>> And?
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> I need your help to make sure coaster is working as expected.
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> Did the workflow finish successfully? I'll assume "yes", since you
>>>>> didn't mention any errors, but it would be useful to state such things
>>>>> from the start.
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>> Yes, it was successful.
>>>>     
>>>>         
>>> That's not a bad sign.
>>>
>>>   
>>>       
>>>>> As far as it working as expected, I have more confidence in the workings
>>>>> of the algorithm itself than in the ancillary stuff. In other words, if
>>>>> you don't see errors/restarted jobs or stack traces in the logs, it's
>>>>> likely that things are fine.
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>>>> The log is at /home/zzhang/scip/ranger-logs/coasters.log
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>> [hategan at communicado ~]$ less /home/zzhang/scip/ranger-logs/coasters.log
>>>>>>> /home/zzhang/scip/ranger-logs/coasters.log: Permission denied
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> try now.
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> [hategan at communicado ~]$ date
>>>>> Wed May 27 17:26:51 CDT 2009
>>>>> [hategan at communicado ~]$ less /home/zzhang/scip/ranger-logs/coasters.log
>>>>> /home/zzhang/scip/ranger-logs/coasters.log: Permission denied
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>> sorry, try again.
>>>>     
>>>>         
>>> Looks ok. There are some things that should probably be adjusted there,
>>> but it looks reasonable. Where the queued/running jobs removed from the
>>> queue when the workflow finished?
>>>
>>>
>>>   
>>>       
>
>
>