[Developers] help

[David Rideout]

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