On May 9, 2011, at 1:56 PM, Blaise Bourdin wrote:
> Hi,
>
> There are still a bunch a sieve-related open issues (I realize that I email
> the tickets to petsc-maint and not petsc-dev) introduced when Mesh, DA and DM
> were consolidated, and after the XXXDestroy calling sequence was altered:
> - DMMeshView writes a text file, even when instructed to use a binary viewer
> - MeshLoad does not read the file written by DMMeshView (perhaps because of
> the issue above)
> - DMMeshRestoreCoordinatesF90 and DMMeshRestoreElementsF90 segfault
I'll build the sieve stuff and get cracking on fixing all these things. Do
you have examples you can point me to so I spend my time fixing the bugs rather
than trying to reproduce them?
>
> Also, I have been meaning to send a feature request but have been
> procrastinating. It deals with named options (as in enum) and fortran:
> In C, there are 2 ways to handle options: PetscOptionsXXX wrapped in a
> PetscOptionsBegin/End and PetscOptionsGetXXX.
> The former is nice in that it generates help, but only a subset of the later
> is implemented in fortran.
> 1. Is a fortran equivalent of the PetscOptionsXXX feasible? I understand that
> it would require more than just fortran bindings.
Big pain. We won't do it, it would have to be a user contribution.
> 2. Alternatively, one can implement the options management in C and use
> PetscBag to convert data from a fortran derived type to a C struct and back.
> One limitation is that enums again are not supported, but neither are arrays.
> 3. If neither 1. or 2. is feasible, would it be possible to add fortran
> support for PetscOptionsGetEnum. Assuming that we use a integer for the enum
> in fortran, my understanding is that all it would take would be to be able to
> pass an array of fortran strings as the list argument of PetscOptionsGetEnum.
This is the crux of the matter. We don't have any portable way of passing an
array of strings from Fortran to C. (Portably passing a single string is bad
enough). If someone figures out how, using the Fortran 2003 standard for
passing arguments to/from C, to handle arrays of strings (assuming the standard
supports it) then we could provide PetscOptionsGetEnum() for Fortran 2003, but
that would be a user contribution, we're not going to do the work ourselves.
>
> Lastly, since the changes DA->DMDA and in XXXDestroy are already going make
> many people angry, is it time to rename Vec PetscVec and Mat PetscMat?
Good question. If so, then shouldn't we name space everything? PetscSNES,
etc etc etc Maybe wait until next release so there are not too many user
changes this release?
Barry
>
> Blaise
>
> On May 9, 2011, at 1:30 PM, Barry Smith wrote:
>
>>
>> I'd like to get a PETSc release, 3.2 out before the summer rush. So let's
>> start checking PETSc-dev much more closely for build problems etc. Satish
>> will set up a release repository for extensive testing in about a week, but
>> even more then get your changes/updates in now.
>>
>> Thanks
>>
>> Barry
>>
>>
>
> --
> Department of Mathematics and Center for Computation & Technology
> Louisiana State University, Baton Rouge, LA 70803, USA
> Tel. +1 (225) 578 1612, Fax +1 (225) 578 4276
> http://www.math.lsu.edu/~bourdin
>
>
>
>
>
>
>
