opencalteam / opencal Goto Github PK

The simulation object's step member is always initialized to 0 in calRunDef_D(). At the contrary, it should be initialized to initial_step. This is important, otherwise step will be initialized to 0 regardless of the third parameter of calRunDef_D() (that specifies the initial step of computation) in the case of simulation loop explicitation and substates' explicit update. This problem does not arise when you use implicit loop and update.

Test Suinos algorithms on scidddicaS3hex example, with OPT_ACTIVE_CELLS.

Some models requires volume rendering (e.g. http://www.vacet.org/gallery/images_video/AMRVolRend.png ). OpenCAL-GL does not support volume rendering at the moment.

Nella seriale di opencal i file CAL2DReduction e CAL3DReduction contenevano erroneamente dei riferimenti a delle funzioni di OpenMP.
In particolare questa implementazione seriale è stata derivata da una versione OMP, strippando le direttive al preprocessore che controllavano l'utilizzo di OMP come dimostra questo commit.

Bisogna che queste funzioni vengano ricontrollate per essere sicuri che funzionino correttamente.

Test the automatic local transfer with OpenCAL-CL.

Single layer substates must be register and deallocated.

lo steering deve diventare un array di puntatori a funzioni di steering.

Aggiungere il pre-steering allo stesso modo. _(per modellare le influenze esterne)_.

Rinominare steering in post-steering.

OK guys, it is time to write a test suite for this (now getting quite) library.

We can think about two level of testing:

1. Applications level
   Given a list of tests applications (few models, GAme of Life, Belousov-Zhabotinsky reaction, identity model etc), we can execute the serial and the version to be tested and compare the results. A configuration file for testing is reccomended that list the name of the applications to use as tests and the binary locations and other test dependent information (model's configurations etc.)
2. Library API level
   We should also provide a set of tests at API level (using Unit tests) maybe using this kind of tools https://github.com/philsquared/Catch or https://code.google.com/p/googletest/

In agreement with the linux/unix convention for shared objects

• shared object should have a version number (e.g. libopencal.so.1.0)

• symbolic links should be created at installation time to point to the actual shared object (e.g.
  libopencal.so.1 -> libopencal.so.1.0
  libopencal.so -> libopencal.so.1.0

  This can also be done by using the following commands
  ln -sf libopencal.so.1.0 libopencal.so.1
  ln -sf libopencal.so.1.0 libopencal.so

  In this way:

  • different versions can be installed without interfere each other (e.g. 1.1, 1.2, 2.0 and so on)
  • the unversioned link (libopencal.so) can be stet to point to the desired version (e.g. the last one)

This issue summarizes the considerations arisen from the conversation with me and Paola of yesterday.

++ version should aim to make the library:

1. More type safe by introducing compile time check on size of the automata. This mean introducing a numeric template parameter for the automata definition
   CALModel<uint,...>* mod2; mod2 = new CALModel<3 ...> (....)
2. Avoid dynamic allocation as much as possible using compile type array whenever possible (http://it.cppreference.com/w/cpp/container/array)
3. Avoid virtual function and polymorphism (apparently in some cases it is the only way to go at the moment). Library has to have speed in mind so no runtime overhead should be prefereable.
4. Raw pointers are dangerous and introduce rooms for segfault-like erros. C++ version should make heavy use of unique_ptr and scoped_ptr/shared_ptr (I would stick to STL implementation than Boost)
5. User defined transition functor (not function) have a fixed header i.e.
   void run(CALModel* calModel, int* indexes). We could consider to use improve that using variable number of arguments (of generic types) and enable support for Lambda functions instead of transition functors only. We should be able to do something like the following:

auto tf = [&](CalModel<3..>* model, std::array<uint, 3>) {
int sum = 0, n;
int neighborhoodSize =calModel->getNeighborhoodSize();
.....
} 
mod2->addElementaryProcess(tf);

at the moment it's mandatory specify the include path kernel but some time the user might not have include files.

Each GPU requires knowledge about the model space coordinate of its threads.

For instance if a boundary condition (for simplicity assume a dirichlet's one) has to be applied the following code can't work withouth each GPU knowing the global offset (which actual part of the model it's taking care of).

    calclThreadCheck2D();
    int i = calclGlobalRow()+borderSize;   
    int j = calclGlobalColumn();

	....

	if(i > 1 && i < ROWS-1 && j > 1 && j < COLS-1 )
            applyBoundaryConditions();

when this code is executed on more than one GPU the boundary conditions can't be correctly applied since i is always in the range [0-W(gpu_i)<ROWS] where (W(index_gpu) is the workload assigned to gpu numbeer i. . So the boundary on the topmost border would be applied by ALL GPUs and bottomost never applied.

The offset corrensponding to the coordinate of the first row of the model space the GPU is taking care of has to be passed to kernels.

    calclThreadCheck2D();
    int i = calclGlobalRow()+borderSize;   
    int j = calclGlobalColumn();

    int modelspace_i = computeGlobalcoordinate(i, gpu_ith_offset)

	....

	if(modelspace_i > 1 && modelspace_i < ROWS-1 && j > 1 && j < COLS-1 )
            applyBoundaryConditions();

Note that computeGlobalcoordinate function implementation is trivial: (i+offset). i.e. local coordinate + model space offset

Ho aggiunto un benchmark che verrà usato per vlaidare e valutare le prestazioni della libreria.
si trova nella cartella heat2D. quando il numero di steps è abbastanza alto (250000 bastano) il programma crasha perchè la memoria dell'host ospitante viene saturata.
Ad una più attenta analisi si vede che anche con pochi steps la curva che mostra l'uso della memoria cresce in modo lineare e regolare. Qeusto suggerisce un problema di gestione della memoria legata al ciclo RUN.
Il problema è anche verificato usando una sola GPU (ed un solo nodo ovviamente)
Per replicare il problema basta compilare il codice dentro mpibenchmark/heat2D ed eseguiro usando lo script opencalexec.sh (le istruzioni su come usarlo sono al suo interno) che si trova nella stess cartella.

Davede, if possible, change the test suit so that tests are get directly from the existing examples. You can take just the examples' executable. In this manner, we can avoid code duplication.
Note that test suite is inconsistent right now, since we (me and Alessio) were forced to modify some examples.
Please, Davide, help us!!!

It's time to empower the 3D part of library with MPI and MultiGPU capabilities as it has been already done for all the 2D API.

My suggestion is to implement what has been already implemented for the 2D part and testing it on the well known 3D heat transfer model (for which we already have a serial and shared memory counterpart) with a spherical source of heat at the very center of the domain.

Comments and suggestions are appreciated.

Scheduling policy must be specified by the user (cmake or other mechamism).

Need to link the c++ version against the python wrapper.

Elementary procees needs to be Class functor and not simple function pointer.

cal2D and cal2D have been modified in this sense.

Steps: compile the library using these new elementary processes and then build the swig wrapper against it. Example are in my opencal private fork (knotman90)

This produces a wrong initialization on the substate unless its type size is 1 byte.
File: https://github.com/OpenCALTeam/opencal/blob/master/OpenCAL-OMP/source/cal2DBuffer.c
at line 230.

void calSetBuffer2Di(CALint* M, int rows, int columns, CALint value)
{
memset(M, value, sizeof(CALint)_rows_columns);
}

The example in GL version of OpenCal does not compile on UNIX system under gcc-5.1 and freeglut opengl implementation.

In file included from ./opencal/OpenCAL-GL/examples/ForestInsect-calgl/source/forestInsect.c:1:0:
./opencal/OpenCAL-GL/examples/ForestInsect-calgl/source/forestInsect.h:46:12: error: field ‘windType’ has incomplete type

  enum WIND windType;

use cmake install command in order to pt libraries, includes binaries and documentation in the right places!

usage

install(TARGETS test DESTINATION lib)
install(FILES test.h DESTINATION include)

When gl version is compiled but omp is not this happen. link libgomp in that example!
Linking C executable ../../../../OpenCAL-GL/examples/calgl_omp_sciddicaT/bin/calgl_omp_sciddicaT
/usr/bin/ld: cannot find -lopencal-omp
collect2: error: ld returned 1 exit status

We should consider to bild an interface to other common mainstream programming languages such as java and python and obviously ... HASKELL ^^

The calAddActiveCellX2D() must be moved to the "unsafe source file". In fact, it modifies the state of a neighboring cell, which is an unsafe opration due to concurrency. Specifically:

• calAddActiveCellX2D() function must move from cal2D.h/cal2D.c to cal2DUnsafe.h/cal2DUnsafe.c
• calAddActiveCellX3D() function must move from cal3D.h/cal3D.c to cal3DUnsafe.h/cal3DUnsafe.c

Building opengl version produces lots of warnings that need to be "solved"

At the copy constructor https://github.com/OpenCALTeam/opencal/blob/master/OpenCAL%2B%2B/source/calActiveCells.cpp#L41

memory should be freed first than reallocated.

Suggest to test the whole library using valgrind

calSteeringOperation3Db function is listed in prototype functions in cal3DReduction.h but is not implemented.

At present, the callback function registered by calRunAddStopConditionFunc*D() takes a pointer to a CA object as parameter. This does not allow the callback to access the step member of the simulation object. Therefore, the callback parameter must be a pointer to a simulation object.

The idea is to implement a 3D model for heat transfer in a rectangular block. Each cell can be of one of the following states:

1. Normal
2. Wall
3. Heat Source ( a serpentine )

Visualization should be implemented using OpenCAL-GL with multiple subwindows, each showing different values of the simulation or different rendering methods (transparency for instance).

Opencl warnings need to be eliminated. Most of them are because of string to char* conversion

1. substitute each char* (in function that cause those problems) with char const *

2. solve using -Wno-write-strings compilation option (BAD PRACTICE)

It should be great if someone could create a cmake find_package to find and load settings from the different OpenCAL libraries:

• find_package(OpenCAL-1.0 REQUIRED)
• find_package(OpenCAL-OMP-1.0 REQUIRED)
• find_package(OpenCAL-CL-1.0 REQUIRED)
• find_package(OpenCAL-GL-1.0 REQUIRED)