[Developers] help

[hughwang at cct.lsu.edu]

Hey, All,
    If there are some examples to show the usage of hyperslabbing API,  
that will be a great help.
    It is of their interesting for people who are seeking HPC on  
Cactuscode since these examples illustrate how to get the  
communications between processors.

Regards,

Hugh



Quoting David Rideout <dprideout at gmail.com>:

> On 10/1/06, jtao at cct.lsu.edu <jtao at cct.lsu.edu> wrote:
>> Quoting Erik Schnetter <schnetter at cct.lsu.edu>:
>> > On Sep 28, 2006, at 01:33:32, jtao at cct.lsu.edu wrote:
>> >> As Erik pointed out in his email, each processor will read its   
>> own  data and
>> >> output its own result. I don't think there is anyway to go around
>> >> this on the
>> >> user's level.
>> > Cactus offers a hyperslabbing API, which transfers chunks of arrays
>> > between processors.  If the users' guide is too cryptic, then we  could
>> > use a blackboard to clarify things.
>>
>> It seems to me that it is optimal to use parellel IO in Hugh's case but
>> there might be some other considerations. Anyway, some examples showing the
>> capabilities of hyperslab will be very helpful.
>>
>> >> Just to get things started, I output the chunk for each processor
>> >> labeled by result_Procxxx.dat.
>> >
>> > Cactus offers several I/O thorns that can output data in standard
>> > formats, such as ASCII and HDF5.  However, if you need your own
>> > special format, then writing the data yourself as you did is often  the
>> > easiest way.
>>
>> I tried to use Cactus I/O thorns since the results are dumped in
>> a grid function. I thought it might be easier but Coord_GetDefaultSystem
>> was required by thorn IO. It is a natural requirement in many problem
>> domains but it is uncessary in Hugh's case.
>
> Indeed, I also often want to use standard Cactus I/O thorns in
> situations where there is no coordinate system.  It seems silly to be
> forced to compile and activate CoordBase in these cases.  Could this
> 'requires' be changed to a 'uses'?
>
>> Also, driver::global_nx might be better called driver::global_n1 and so
>> on just like what was suggested in ADMBase(gxx->g11). As the user base of
>> Cactus expands, another level of abstraction might be necessary to minimize
>> confusion in the future.
>
> Indeed.  I imagine that such things will be cleaner in Cactus 5.
>
> Cheers,
> David
> _______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers
>
>