ianw-projects / inductioneq Goto Github PK

We could use Appveyor and/or Travis.

Actually, we are using the negative Laplace operator for the divergence cleaning method. This should be reflected in the names of the arrays containing the coefficients. We might want to reconsider the namimg of the other coefficient arrays, too.

We might want to discuss the usage of compiler warnings as in https://github.com/MuMPlaCL/InductionEq/blob/db5cb438d00096458d34e414cf8ecdf83e556c49/kernel/artificial_dissipation.cl#L170.
Why should one choice of artificial dissipation (i.e. none) be special? Additionally, OpenCL does not really give some help with warnings...

We could use some default coefficients, e.g. for the adaptive dissipation:

// default values for the adaptive artificial dissipation given by Svärd & Mishra (2009)
#ifndef CMIN
#define CMIN 1
#endif
...

Additionally, such default values might be set for the configuration dictionaries. What do you think?

Add a zenodo json file with ancillary information for DOI generation.

We will add a simple Julia interface mimicking the Matlab scripts. Although it is not very Julian, it makes the usage and switching between both languages easier.

We should compose a list with issues/errors that may occur. Maybe in the form of an extended user guide? Examples would be:

• Poor conditioning of a problem which may lead to NaN.
• Data type handling in Matlab. Some variables need to explicitly be defined as integers.
• Errors in OpenCL kernel typically lead to segmentation faults in Matlab.
• Explicit casting and precision of OpenCL defines.

It can be useful to have a (non-negative) coefficient multiplying all high-order dissipation terms.

Hi !
i started to write a PyOpenCl based backend and realized that all arrays are created in host memory. Afterwards they are copied to the OpenCL device, used by the kernel, and copied back by cl_run_kernel.
I would like to write functions which just create references to the arrays in OpenCL device memory and pass them around, because transfer to and from GPUs can be slow. What do you think ?

The coefficients are already implemented, we just need the high-level interface.

However, no second derivative approximation have been derived for these extended operators. Thus, not all options (narrow stencil) for the divergence cleaning via projection would be available.