dorsal team mailing list archive

[Harish Narayanan <harish.mlists@xxxxxxxxx>]

On 3/7/12 10:06 PM, Garth N. Wells wrote:
> 
> 
> On 7 Mar 2012, at 21:01, Anders Logg <logg@xxxxxxxxx> wrote:
> 
>> On Wed, Mar 07, 2012 at 08:59:31PM +0000, Garth N. Wells wrote:
>>> On 7 March 2012 20:18, Anders Logg <logg@xxxxxxxxx> wrote:
>>>> On Wed, Mar 07, 2012 at 07:47:17PM +0000, Garth N. Wells wrote:
>>>>> On 7 March 2012 19:37, Fredrik Heffer Valdmanis <fredva@xxxxxxxxxx> wrote:
>>>>>> 2012/3/7 Anders Logg <logg@xxxxxxxxx>
>>>>>>>
>>>>>>> On Wed, Mar 07, 2012 at 04:24:13PM +0100, Fredrik Heffer Valdmanis wrote:
>>>>>>>> I think it might be a good time to bring this thread up again now. My
>>>>>>>> Dorsal branch is still working fine, but there are a couple of issues
>>>>>>>> that
>>>>>>>> should be discussed before merging:
>>>>>>>>
>>>>>>>> 1: As mentioned in my first email, the user has to set "default
>>>>>>>> CUDA_DIR=<path to cuda installation>" in the platform file, and add the
>>>>>>>> packages cusp and thrust to the beginning of the list of packages to
>>>>>>>> build
>>>>>>>> PETSc with Cusp support. This might not be the best way to solve this.
>>>>>>>> One
>>>>>>>> could of course set CUDA_DIR in dorsal/local.cfg instead, but the list
>>>>>>>> of
>>>>>>>> packages to install still has to be modified. Any opinions? Could this
>>>>>>>> be
>>>>>>>> (semi) automated?
>>>>>>>
>>>>>>> How about making a new package file called petscwithcuda or petsc-cuda or
>>>>>>> whatever naming schem Harish suggests.
>>>>>>>
>>>>>>> I think it is OK to require the user to set the environment variable
>>>>>>> CUDA_DIR before running Dorsal, either as part of the user's
>>>>>>> environment setup or in local.cfg.
>>>>>>>
>>>>>>>
>>>>>>>> 2: Thrust and Cusp only comes packaged in .zip-files, which Dorsal
>>>>>>>> doesn't
>>>>>>>> support as far as I can see. To get around this this, {thrust,
>>>>>>>> cusp}.package currently pull the latest hg repositories from Google
>>>>>>>> Code.
>>>>>>>> To make these development versions play nice with petsc-3.2-p6, I have
>>>>>>>> had
>>>>>>>> to add a patch to PETSc. A possible solution would be to package stable
>>>>>>>> versions of cusp and thrust ourselves and host them on
>>>>>>>> fenicsproject.org. PETSc-dev
>>>>>>>> works fine with these development versions, so we can skip the patching
>>>>>>>> once 3.2-p7 is released.
>>>>>>>
>>>>>>> I don't fully understand. Are there stable Thrust and Cusp packages
>>>>>>> available which work with stable PETsc?
>>>>>>>
>>>>>> Yes, the latest stable versions of Cusp (0.3.0 [1]) and Thrust (1.5.1 [2])
>>>>>> work fine with PETSc 3.2-p6, but they are only available as .zip-files, a
>>>>>> packaging scheme which is not supported by Dorsal as far as I understand.
>>>>>> Hence, we must either use the mercurial repositories, which is a type of
>>>>>> repo that Dorsal can pull, or we must repackage Cusp and Thrust in an
>>>>>> archive format that Dorsal supports and host them ourselves. It is not
>>>>>> really an alternative to use development versions, so we should repackage
>>>>>> Cusp and Thrust. Or implement zip-support in Dorsal ...
>>>>>>
>>>>>
>>>>> An up-to-date Thrust is part of the CUDA toolkit.
>>>>>
>>>>> Having installed the CUDA toolkit a number of times recently, I still
>>>>> don't think that it's ready for Dorsal.
>>>>
>>>> I don't understand this objection.
>>>
>>> Where's the 'objection'? It's an opinion based on my experience of
>>> installing the CUDA toolkit.
>>
>> It sounded like an objection to me. Maybe with your experience you
>> could help to tweak the package files when they are added.
>>
> 
> If it was just tweaking it would be easy. I think that before a decision is made those involved should understand what is required. For example, does Dorsal test for the gcc version (nvcc is picky about this)? I'm not interested in working on the level of tweaking required to get nvcc working on Ubuntu 11.10.

Dorsal does not natively test for gcc versions (or anything else,
really). But anything special that needs to be done for a package can
(in theory) be added to the package_specific_setup() function in its
package file.

I don't have experience with cuda etc., so others interested will have
to figure out the details. Fredrik, as Anders suggested earlier, create
your new petsc package as petscwithcuda.package and you can fiddle with
it as much as you want without affecting anything else. Dorsal now
supports zip files so that should make it one bit easier.

Harish

Harish