<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 14, 2015 at 10:56 AM, Jared Crean <span dir="ltr"><<a href="mailto:jcrean01@gmail.com" target="_blank">jcrean01@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>    Hello everyone,<br>
              I got the package in a reasonably working state and Travis
      testing setup, so I am putting the package up on Github.<br>
      <br>
              <a href="https://github.com/JaredCrean2/PETSc.jl" target="_blank">https://github.com/JaredCrean2/PETSc.jl</a><br>
      <br>
              There is still a lot more work to do, but its a start.<br>
      <br>
              A couple questions:<br>
              When looking though the code, I noticed the MPI
      communicator is being passed as a 64 bit integer.  mpi.h typedefs
      it as an int, so shouldn't it be a 32 bit integer?<br></div></div></blockquote><div><br></div><div>Some MPI implementations store the communicator as a pointer, which may be 64 bits. I think the only thing the standard says is</div><div>that MPI_Comm should be defined.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
              Also, is there a way to find out at runtime what datatype
      a PetscScalar is?  It appears PetscDataTypeGetSize does not accept
      PetscScalar as an argument.</div></div></blockquote><div><br></div><div>If PETSC_USE_COMPLEX is defined its PETSC_COMPLEX, otherwise its PETSC_REAL. You can also just use sizeof(PetscScalar). What do you</div><div>want to do?</div><div><br></div><div>  Thanks,</div><div><br></div><div>     Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div><span class="HOEnZb"><font color="#888888"><br>
          Jared Crean</font></span><div><div class="h5"><br>
      <br>
      <br>
      On 07/06/2015 09:02 AM, Matthew Knepley wrote:<br>
    </div></div></div><div><div class="h5">
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Mon, Jul 6, 2015 at 4:59 AM,
            Patrick Sanan <span dir="ltr"><<a href="mailto:patrick.sanan@gmail.com" target="_blank">patrick.sanan@gmail.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div dir="ltr">I had a couple of brief discussions about
                this at Juliacon as well. I think it would be useful,
                but there are a couple of things to think about from the
                start of any new attempt to do this:
                <div>1. As Jack pointed out, one issue is that the PETSc
                  library must be compiled for a particular precision.
                  This raises some questions - should several versions
                  of the library be built to allow for flexibility?</div>
                <div>2. An issue with wrapping PETSc is always that the
                  flexibility of using the PETSc options paradigm is
                  reduced - how can this be addressed? Could/should an
                  expert user be able to access the options database
                  directly, or would this be too much violence to the
                  wrapper abstraction?</div>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>I have never understood why this is an issue. Can't you
              just wrap our interface level, and use the options just as
              we do? That</div>
            <div>is essentially what petsc4py does. What is limiting in
              this methodology? On the other hand, requiring specific
              types, ala FEniCS,</div>
            <div>is very limiting.</div>
            <div><br>
            </div>
            <div>   Matt</div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div class="gmail_extra">
                <div class="gmail_quote">On Sat, Jul 4, 2015 at 11:00
                  PM, Jared Crean <span dir="ltr"><<a href="mailto:jcrean01@gmail.com" target="_blank">jcrean01@gmail.com</a>></span>
                  wrote:<br>
                  <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
                    <div bgcolor="#FFFFFF" text="#000000"> <big>Hello,<br>
                             I am a graduate student working on a CFD
                        code written in Julia, and I am interested in
                        using Petsc as a linear solver (and possibly for
                        the non-linear solves as well) for the code.  I
                        discovered the Julia wrapper file Petsc.jl in
                        Petsc and have updated it to work with the
                        current version of Julia and the MPI.jl package,
                        using only MPI for communication (I don't think
                        Julia's internal parallelism will scale well
                        enough, at least not in the near future).<br>
                        <br>
                             I read the discussion on Github [<a href="https://github.com/JuliaLang/julia/issues/2645" target="_blank">https://github.com/JuliaLang/julia/issues/2645</a>],
                        and it looks like <br>
                        there currently is not a complete package to
                        access Petsc from Julia.  With your permission,
                        I would like to use the Petsc.jl file as the
                        basis for developing a package.  My plan is
                        create a lower level interface that exactly
                        wraps Petsc functions, and then construct a
                        higher level interface, probably an object that
                        is a subtype of Julia's AbstractArray, that
                        allows users to store values into Petsc vectors
                        and matrices.  I am less interested in
                        integrating tightly with Julia's existing linear
                        algebra capabilities than ensuring good
                        scalability.  The purpose of the high level
                        interface it simple to populate the vector or
                        matrix.<br>
                        <br>
                             What do you think, both about using the
                        Petsc.jl file and the  overall approach?<span><font color="#888888"><br>
                            <br>
                                 Jared Crean</font></span></big><br>
                    </div>
                  </blockquote>
                </div>
                <br>
              </div>
            </blockquote>
          </div>
          <br>
          <br clear="all">
          <div><br>
          </div>
          -- <br>
          <div>What most experimenters take for
            granted before they begin their experiments is infinitely
            more interesting than any results to which their experiments
            lead.<br>
            -- Norbert Wiener</div>
        </div>
      </div>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div>
</div></div>