Re: Octave-MPI via oct-files

[Paul Kienzle]

On Wed, Dec 18, 2002 at 03:18:21PM -0800, JD Cole wrote:
> 
> You'll notice after grazing the code that I have copied the 
> read/save_binary_data functions and their depencies into mpi_send/recv. 
> This was done because I wanted that functionality but currently these 
> functions are "static" in load-save.cc in the Octave source. Of course, 
> I would rather not duplicate code, if I can avoid it, so I'm wondering 
> if it would be wrong to expose those functions in load-save.cc?

load-save is a big problem.  

We want to be able to allow user defined types to load and save themselves,
so the serialization code should be a method in octave_value.  But it would
also be nice to define a new file format in an oct file and have it work
as if the format was built into load/save.

As an example, consider the sparse matrix package in octave-forge.  How
can we design octave so that sparse matrices can be loaded from and saved
to octave/matlab/hdf files without modifying load-save.cc?  Could someone
define a separate package which for example extended load-save to handle
Maple file formats (if there is such a thing)?  How could the maple-file
package handle sparse matrices?  Could a third party write the sparse
handler for maple format without modifying sparse or maple?

The only way I can think to handle this is to have a mapping from
{type, format} into handler.

For save, if there is no handler for saving that type for that format
then the format driver could either ignore it, save a value of "undefined"
or maybe save the value as a "foreign" type using the octave_value
serializer method which each type must define so that even though other
applications wouldn't handle it correctly the file could be reloaded in
octave.  Of course, appropriate warnings about unsupported values should
be issued.

Load is tricky since you don't know what type it is in advance, so you 
won't know what type-format handler to call.  For well defined formats
you could ask each type handler for that format if it understands the
type specifier.  For octave files, this would be a string.  For matlab
binary files this would be an integer.  If no handler is found for that
specifier, hopefully the entry can be skipped (with an appropriate warning)
and the next value loaded from the file.  Presumably the format driver
would recognize undefined/foreign values and restore the appropriate octave
type directly without checking through each handler.

Is this too complicated?

> 
> Also, since LAM  MPI is quite sensitive to the sequence of calls 
> lamboot->MPI_Init-> (other MPI calls), i.e. it terminates a program 
> without remorse, I install a global variable octave_mpi_session_flag 
> which allows MPI functions to tell if MPI_Init of MPI_Finalize have been 
> called. (I have considered implementing this variable as shared memory, 
> i.e. external to Octave, as to not used octave internals such as the line:
> 
> symbol_record *sr = global_sym_tab->lookup("octave_mpi_session_flag");
> 
> if that practive is considered "taboo".)

I believe there is a function get_global_value("name") which would continue
to be part of any well defined API for octave once we defined one.

Paul Kienzle
address@hidden