Make it optional to use RealSingle and ComplexDouble versions of PETSc

[tadeu]

Currently we have to build PETSc 3 times, even if it will be used only for the RealDouble version (which I assume is the majority of use cases).

There's a place where this could be configured globally: defs.jl. For example, it could be configured to have only:

const petsc_libs = [:petscRealDouble]
const petsc_type = [Float64]

The problem is that there are some places where it is hard-coded the usage of the 3 PETSc's, for example, in c_funcs.jl:56:

for (T, P) in ( (Float64, petscRealDouble), (Float32, petscRealSingle), (Complex128, petscComplexDouble) )

What do you think about this?

[JaredCrean2]

Yes, I've been secretly hoping to do this for some time. This issue will definitely increase the priority.

[tadeu]

Cool! Just FYI, I've managed to make it work with a "quick and dirty" hack in the code (patch below). I only had to change a few places. Also note that I hardcoded a pre-compiled version of PETSc I had here (as I'm working on Windows, it's easier to just use a pre-compiled version).

---
 src/generated/c_funcs.jl |  2 +-
 src/generated/defs.jl    | 23 ++++++++++++++++++-----
 src/petsc_com.jl         | 10 +++++-----
 3 files changed, 24 insertions(+), 11 deletions(-)

diff --git a/src/generated/c_funcs.jl b/src/generated/c_funcs.jl
index 0abc857..46e46e5 100644
--- a/src/generated/c_funcs.jl
+++ b/src/generated/c_funcs.jl
@@ -53,7 +53,7 @@ function MatShellSetOperation(arg1::Mat,arg2::MatOperation,arg3::Ptr{Void})
 end
 =#

-for (T, P) in ( (Float64, petscRealDouble), (Float32, petscRealSingle), (Complex128, petscComplexDouble) )
+for (T, P) in ( (Float64, petscRealDouble), )
   @eval begin
     function MatShellGetContext(arg1::Mat{$T})
     # get the user provided context for the matrix shell
diff --git a/src/generated/defs.jl b/src/generated/defs.jl
index 946cfe0..ab958ac 100644
--- a/src/generated/defs.jl
+++ b/src/generated/defs.jl
@@ -7,12 +7,25 @@ export PetscErrorCode
 export PetscBool
 export PetscInt # defined in depfile

-const depfile = joinpath(dirname(@__FILE__), "..", "..", "deps", "deps.jl")
-isfile(depfile) || error("PETSc not properly installed. Please run Pkg.build(\"PETSc\")")
-include(depfile)
+# const depfile = joinpath(dirname(@__FILE__), "..", "..", "deps", "deps.jl")
+# isfile(depfile) || error("PETSc not properly installed. Please run Pkg.build(\"PETSc\")")
+# include(depfile)

-const petsc_libs = [:petscRealDouble, :petscRealSingle, :petscComplexDouble]
-const petsc_type = [Float64, Float32, Complex128]
+# const petsc_libs = [:petscRealDouble, :petscRealSingle, :petscComplexDouble]
+# const petsc_type = [Float64, Float32, Complex128]
+
+const petscRealDouble = "D:\\PETSc\\petsc.dll"
+
+# STUB
+const petscRealSingle = "D:\\PETSc\\petsc.dll"
+
+# STUB
+const petscComplexDouble = "D:\\PETSc\\petsc.dll"
+
+const PetscInt = Int64
+
+const petsc_libs = [:petscRealDouble]
+const petsc_type = [Float64]

 typealias Scalar Union{Float32, Float64, Complex128}

diff --git a/src/petsc_com.jl b/src/petsc_com.jl
index 571f67c..3e00979 100644
--- a/src/petsc_com.jl
+++ b/src/petsc_com.jl
@@ -7,15 +7,15 @@ function __init__()
     MPI.Init()
   end

-  PetscInitialize(Float32)
+  # PetscInitialize(Float32)
   PetscInitialize(Float64)
-  PetscInitialize(Complex128)
+  # PetscInitialize(Complex128)

   # we want Petsc to return errors to us, rather than using its own
   # error handlers, so that we can catch error codes and throw exceptions
   # need to do this for all Petsc versions

-  for i=1:3
+  for i=1:1
     libname = C.petsc_libs[i]
     val = @eval(cglobal((:PetscIgnoreErrorHandler, C.$libname)))
     C.PetscPushErrorHandler(C.petsc_type[i], val, C_NULL)
@@ -23,9 +23,9 @@ function __init__()

   # register atexit finalizers for the Petsc libraries
   atexit() do
-    C.PetscFinalize(Float32)
+    # C.PetscFinalize(Float32)
     C.PetscFinalize(Float64)
-    C.PetscFinalize(Complex128)
+    # C.PetscFinalize(Complex128)
   end
 end

-- 

[JaredCrean2]

Perfect. I was considering something like this when I wrote the code, so I'm glad it is possible. This should also compose nicely with your other issue.

I probably won't get to implementing this until the end of the semester (2 week from now), but it sounds like you have things working temporarily, so hopefully the delay won't be too much of an inconvenience.

[JaredCrean2]

closed via #69