Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Creating modules that depend on ParallelStencil.jl #75

Open
smartalecH opened this issue Oct 27, 2022 · 3 comments
Open

Creating modules that depend on ParallelStencil.jl #75

smartalecH opened this issue Oct 27, 2022 · 3 comments

Comments

@smartalecH
Copy link

Suppose I wanted to create a module that depends on ParallelStencil.jl (e.g. a self-contained finite-difference code). What's the best way to do this?

Normally this is rather straightforward... but the primary source of ambiguity for me is how to best handle the @init_parallel_stencil() macro.

Naively, I might just call that macro at the top of the script which calls the new module, but it gets hairy when you need to access the created Data class inside of your new module (there's a lot of redundant passing that occurs).

Perhaps a more elegant scenario is to call that macro within the module itself (but then you have a chicken-egg problem when trying to specify the parameters of that macro...)?

I'm curious to see how others tackle this.

@albert-de-montserrat
Copy link
Contributor

Not very elegant, this is what I currently do now:

function environment!(model::PS_Setup{T,N}) where {T,N}
    gpu = model.device == :gpu ? true : false

    # call appropriate FD module
    Base.eval(@__MODULE__, Meta.parse("using ParallelStencil.FiniteDifferences$(N)D"))

    # start ParallelStencil
    if model.device == :gpu
        eval(:(@init_parallel_stencil(CUDA, $T, $N)))
        Base.eval(Main, Meta.parse("using CUDA"))
    else
        @eval begin
            @init_parallel_stencil(Threads, $T, $N)
        end
    end

    generate_myStruct!(N) 
   
    # includes and exports
    @eval begin
        include("myFile.jl"))
        export myfun
       # etc
    end

and at the top of my script I include:

# setup ParallelStencil.jl environment
model = PS_Setup(:cpu, Float64, 2) # :cpu or :gpu
environment!(model)

I am also curious to know if there's a more elegant wat to handle this.

@smartalecH
Copy link
Author

Great! Thanks, @albert-de-montserrat!

It looks like the current strategy then is to "bootstrap" yourself through the loading process (which I guess is how ParallelStencil.jl itself works...)

I wonder if there's a cleaner (and more flexible) way to do this?

@korbinian90
Copy link

I'm using simply this to automatically decide which version to use:

using CUDA, ParallelStencil, ParallelStencil.FiniteDifferences3D

if CUDA.functional()
    @eval @init_parallel_stencil(CUDA, Float32, 3)
else
    @eval @init_parallel_stencil(Threads, Float32, 3)
end

The user cannot decide which version to use, however.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants