Yes, sure.
I would propose this solution
#include "mpi.h"
#include <octave/oct.h>
#include <octave/error.h>
class mpicomm : public octave_base_value
{
public:
// Constructor
mpicomm (const std::string _name = "")
: octave_base_value (), name (_name)
{
}
void print (std::ostream& os, bool pr_as_read_syntax = false) const
{
os << name << std::endl;
}
bool is_defined (void) const { return true; }
private:
const std::string name;
DECLARE_OCTAVE_ALLOCATOR
DECLARE_OV_TYPEID_FUNCTIONS_AND_DATA
};
DEFINE_OCTAVE_ALLOCATOR (mpicomm);
DEFINE_OV_TYPEID_FUNCTIONS_AND_DATA (mpicomm, "mpicomm", "mpicomm");
static bool mpicomm_type_loaded = false;
DEFUN_DLD(mpicomm, args, ,"")
{
if (!mpicomm_type_loaded)
{
mpicomm::register_type ();
mpicomm_type_loaded = true;
mlock ();
}
octave_value retval;
if (args.length () != 1 || !args (0).is_string ())
{
error ("mpicomm: first argument must be a string");
return retval;
}
const std::string name = args (0).string_value ();
if( name == "MPI_COMM_WORLD" )
{
MPI_Comm Mine = MPI_COMM_WORLD;
}
else if( name == "MPI_COMM_SELF" )
{
MPI_Comm Mine = MPI_COMM_SELF;
}
else if( name == "MPI_COMM_NULL" )
{
MPI_Comm Mine = MPI_COMM_NULL;
}
else
{
// Error about invalid type
error ("MPI: not a valid communicator");
}
retval = new mpicomm (name);
return retval;
}
At least we get rid of raw pointer and abuse of reinterpret cast like here
#if __ia64__ || __x86_64__ // IA-64 / EM64T/AMD64
#define OpenMPI_OctPtrTyp octave_uint64
#define OpenMPI_OctIntFcn uint64_scalar_value
#define OpenMPI_64BIT 1
#define OpenMPI_ST_offset 2
#else // #elif __i386__ // IA-32
#define OpenMPI_OctPtrTyp octave_uint32
#define OpenMPI_OctIntFcn uint32_scalar_value
#define OpenMPI_64BIT 0
#define OpenMPI_ST_offset 1
#endif
#define OpenMPI_intcast(cptr) OpenMPI_OctPtrTyp (\
reinterpret_cast <unsigned long> ( cptr ) )
#include "mpi.h"
#undef MPI_COMM_WORLD
#define NAME MPI_COMM_WORLD
DEFUN_DLD ( MPI_COMM_WORLD, args, nargout,
"MPI_COMM_WORLD Openmpi_ext constant for corresponding communicator
object\n\
\n\
Current value (openmpi-1.3.3) is:\n\
\n\
typedef struct ompi_communicator_t *MPI_Comm;\n\
#define MPI_COMM_WORLD OMPI_PREDEFINED_GLOBAL( MPI_Comm, ompi_mpi_comm_world)\n\
\n\
SEE ALSO: comms\
")
{
octave_value result;
// var = MPI_COMM_WORLD
// Definition stolen from mpi.h
// #define MPI_COMM_WORLD OMPI_PREDEFINED_GLOBAL( MPI_Comm, ompi_mpi_comm_world)
result = (OpenMPI_intcast( NAME ) // defined -> expanded
}
that JWE would definitely rule out.
We could consider the first as a temporary solution.
What do you think Jarolaslav?
Respectfully
Riccardo
--- Mar 24/11/09, Michael Creel <michael.cr...@uab.es> ha scritto:
Da: Michael Creel <michael.cr...@uab.es>
Oggetto: Re: Monte Carlo example for new MPI bindings
A: "Jaroslav Hajek" <high...@gmail.com>
Cc: "Riccardo Corradini" <riccardocorrad...@yahoo.it>, "octave-forge list"
<octave-dev@lists.sourceforge.net>
Data: Martedì 24 novembre 2009, 10:36
On Mon, Nov 23, 2009 at 2:31 PM, Jaroslav Hajek <high...@gmail.com> wrote:
Hi Riccardo and Michael,
I have already implemented basic support for the communicators in the SVN tree.
The relevant functions now accept comm as their last argument, defaulting to
MPI_COMM_WORLD if not provided.
MPI_COMM_WORLD is a new function.
Note 1: The implementation imposes the requirement that MPI_Comm is a typedef
for signed 32-bit or 64-bit integer (int, long, or long long) which is true in
all major MPI implementations with the notable exception of OpenMPI. OpenMPI
uses raw pointers, which make things a bit difficult. One option is to simply
typecast the pointers to integers; but I feel a bit uneasy about working with
raw pointers in Octave, so I'm thinking about a solution providing some
validation as well.
I would, however, like to avoid creating a user type for each of MPI's types.
Note 2:
There are no functions for creating new communicators yet.
Hi all,
A check out this morning is not compiling for me:
mich...@yosemite:~/Desktop/openmpi_ext/src$ make all
mkoctfile -c -I/usr/lib/openmpi/include -I/usr/lib/openmpi/include/openmpi
comm-util.cc
comm-util.cc: In function ‘ompi_communicator_t* do_get(const octave_value&)
[with T = int]’:
comm-util.cc:39: error: invalid conversion from ‘int’ to ‘ompi_communicator_t*’
comm-util.cc: At global scope:
comm-util.cc:34: error: explicit template specialization cannot have a storage
class
comm-util.cc: In function ‘ompi_communicator_t* do_get(const octave_value&)
[with T = long int]’:
comm-util.cc:51: error: invalid conversion from ‘long int’ to
‘ompi_communicator_t*’
comm-util.cc: At global scope:
comm-util.cc:46: error: explicit template specialization cannot have a storage
class
comm-util.cc:72: error: explicit template specialization cannot have a storage
class
comm-util.cc:78: error: explicit template specialization cannot have a storage
class
make: *** [comm-util.o] Error 1
mich...@yosemite:~/Desktop/openmpi_ext/src$
Is that expected at the moment?
Cheers, Michael
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Octave-dev mailing list
Octave-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/octave-dev
