I have been adding support for cmake in SLEPc. My simple approach is:
1) generate a SLEPcConfig.cmake file
2) generate CMakeLists.txt with a cmakegen module adapted from petsc-dev
3) run cmake with a cmakeboot module adapted from petsc-dev
Step 3 loads RDict and uses 'script' to process all PETSc
d's FindPETSc.cmake
> module?
>
If you decide to use it, let me know if you find any problems. Writing
significant logic in cmake-script is no fun.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110311/1765072d/attachment.html>
The IOR() intrinsic does this in every fortran compiler I've been able
to test (gnu, pgi, intel, absoft) (yes, I find it sad that I have that
many fortran compilers available to me here... I think we have nag
somewhere as well...).
Will clean them out.
Ethan
On Thu, 2011-03-10 at 19:37 -0600, Ba
On 11 March 2011 13:16, Ethan Coon wrote:
> The IOR() intrinsic does this in every fortran compiler I've been able
> to test (gnu, pgi, intel, absoft) (yes, I find it sad that I have that
> many fortran compilers available to me here... I think we have nag
> somewhere as well...).
>
> Will clean t
On Thu, 2011-03-10 at 23:53 -0300, Lisandro Dalcin wrote:
> While updating petsc4py for the latest DMDA chages, and alto taking
> into account some new in NumPy C API related to neighborhood
> iterators, I've got new idea. What about the API below?:
>
> enum DMDABoundaryType:
> DMDA_BOUNDARY_
On 11 March 2011 13:29, Ethan Coon wrote:
> On Thu, 2011-03-10 at 23:53 -0300, Lisandro Dalcin wrote:
>> While updating petsc4py for the latest DMDA chages, and alto taking
>> into account some new in NumPy C API related to neighborhood
>> iterators, ?I've got new idea. What about the API below?:
On 11 March 2011 13:38, Lisandro Dalcin wrote:
> On 11 March 2011 13:29, Ethan Coon wrote:
>> On Thu, 2011-03-10 at 23:53 -0300, Lisandro Dalcin wrote:
>>> While updating petsc4py for the latest DMDA chages, and alto taking
>>> into account some new in NumPy C API related to neighborhood
>>> iter
We are about to develop an interface to pARMS in petsc-dev, similar to that of
Hypre. But there is already a pARMS.py module. Has anyone started this already?
Jose
bed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110311/f08d6356/attachment.html>
It's not hard, just a lot of code. GetLocalInfo(), the DM_DA struct,
the DMDALocalInfo struct, etc etc. I started going through this,
shouldn't take long. Barry can take it or leave it ;)
Not that I'm volunteering, but at what point does this all go to ADDA?
Ethan
On Fri, 2011-03-11 at 13:50
El 11/03/2011, a las 17:58, Matthew Knepley escribi?:
> Yes, there was a good amount of effort spent on it. Is it broken?
>
> Thanks,
>
> Matt
I cannot find anything in petsc-dev related to pARMS, other that the configure
module pARMS.py. Where is it?
Jose
resting than any results to which their experiments
lead.
-- Norbert Wiener
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110311/878ebc8d/attachment.html>
interesting than any results to which their experiments
lead.
-- Norbert Wiener
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110311/e33df531/attachment.html>
ay's BuildSystem.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110311/08231579/attachment.html>
in their experiments
is infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20110311/41f53c58/attachment.html>
On 11 March 2011 14:01, Ethan Coon wrote:
> It's not hard, just a lot of code. ?GetLocalInfo(), the DM_DA struct,
> the DMDALocalInfo struct, etc etc. ?I started going through this,
> shouldn't take long. ?Barry can take it or leave it ;)
>
> Not that I'm volunteering, but at what point does this
On Mar 11, 2011, at 10:25 AM, Lisandro Dalcin wrote:
> On 11 March 2011 13:16, Ethan Coon wrote:
>> The IOR() intrinsic does this in every fortran compiler I've been able
>> to test (gnu, pgi, intel, absoft) (yes, I find it sad that I have that
>>
>
> 2) Change to the cleaner API I've suggeste
Ok, here's a patch that makes the below change, and changes the APIs of
DMDACreate*D(), DMDAGetInfo(), and DMDASetBoundaryType().
Nearly every tutorial/test example is touched, and everyone's DA code is
broken. Up to you if you want it :)
This should deal with Lisandro's c++ issue with int/enum
On 11 March 2011 20:35, Ethan Coon wrote:
> Ok, here's a patch that makes the below change, and changes the APIs of
> DMDACreate*D(), DMDAGetInfo(), and DMDASetBoundaryType().
>
You missed a couple of fixes (pasted at the end). After applying your
patch, the updated (also working with petsc-3.1)
I just pushed this patch along with the fix you mentioned.. [and
couple of other fixes]
Satish
On Fri, 11 Mar 2011, Lisandro Dalcin wrote:
> On 11 March 2011 20:35, Ethan Coon wrote:
> > Ok, here's a patch that makes the below change, and changes the APIs of
> > DMDACreate*D(), DMDAGetInfo(), a
20 matches
Mail list logo
