Discussion:
Octave-maintainers Digest, Vol 86, Issue 83
(too old to reply)
c.
2013-06-02 16:25:51 UTC
Permalink
On 31 May 2013, at 17:52, octave-maintainers-***@octave.org wrote:

> Message: 2
> Date: Fri, 31 May 2013 10:04:29 -0500
> From: Ruipeng Li <***@cs.umn.edu>
> To: Kai Torben Ohlhus <***@tuhh.de>
> Cc: Yousef Saad <***@cs.umn.edu>, octave-***@octave.org
> Subject: Re: GSoC - Incomplete factorization project, ITSOL
> Message-ID:
> <CANtCYPFUxRoj7SB11SbKaWs0aFoeQS-7T1wNasB=***@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi, Kai
>
> sure we can talk about it anytime you like and also I can provide you the
> standalone C code of ILUTP and ILUK.
>
>
> On Fri, May 31, 2013 at 9:52 AM, Kai Torben Ohlhus <***@tuhh.de>wrote:
>
>> On 05/31/2013 04:32 PM, Yousef Saad wrote:
>>
>>>
>>> Hi,
>>>
>>> Both Ruipeng and I will be able to help with advice and guidance.
>>> For one thing we have stand-along implementations of ILUT (+ ILUTP)
>>> and ILUK [not available in matlab- except for ILU0] which are more
>>> efficient and easier to implement than those you will extract from
>>> ITSOL. I will be fairly available after July 15th.
>>>
>>> With best regards,
>>>
>>> Yousef Saad
>>>
>>> On Fri, 31 May 2013, Kai Torben Ohlhus wrote:
>>>
>>> On 05/31/2013 02:34 AM, Nir Krakauer wrote:
>>>>
>>>>> Kai--
>>>>>
>>>>> It looks like Ruipeng will not be able to particpate in GSoC. So you
>>>>> should go ahead with studying ITSOL and deciding how to interface to
>>>>> Octave. Hopefully Ruipeng and Yousef will still be available for some
>>>>> advice and guidance.
>>>>>
>>>>> Nir
>>>>>
>>>>>
>>>> Oh, what a pity! Okay then I continue my plan with Octave-forge
>>>> project as a first step.
>>>>
>>>> Kai.
>>>>


Hi Kai,

Sorry for getting in touch with you this late, welcome to GSoC and to Octave!

I might have missed a few of your first posts on this list so I'm just checking in
with you and Nir to know how your first steps are going.

Have you tried building Octave sources yet?
Have you started getting acquatinted with its development environment?
Did you set up a GSoC blog?

Best wishes for your project!
c.
c.
2013-06-04 16:43:11 UTC
Permalink
On 2 Jun 2013, at 18:25, c. <***@gmail.com> wrote:

> Have you tried building Octave sources yet?
> Have you started getting acquatinted with its development environment?
> Did you set up a GSoC blog?

Kai,

a short comment on your post:
http://siko1056-gsoc.blogspot.it/2013/05/octave-forge-packet-incomplete.html#comment-form

1) There is no such thing as Octave 'packets'.
We do have Octave-Forge 'packages', but it is not
decided yet whether your code should be in a package
or in Octave-core itself.

2) There is an advantage in interfacing to ITSOL
rather than including the source code in Octave,
i.e. it will reduce the burden on Octave developers
for maintaining the code at a later time.
So I'd rather not dismiss


c.
Kai Torben Ohlhus
2013-06-04 21:45:42 UTC
Permalink
On 06/04/2013 06:43 PM, c. wrote:
>
> Kai,
>
> a short comment on your post:
> http://siko1056-gsoc.blogspot.it/2013/05/octave-forge-packet-incomplete.html#comment-form
>
> 1) There is no such thing as Octave 'packets'.
> We do have Octave-Forge 'packages',

Hello c.,

thank you for your comment. I fixed my diction.

> but it is not decided yet whether your code should be in a package
> or in Octave-core itself.
>
> Have you tried building Octave sources yet?
> Have you started getting acquatinted with its development environment?

I must admit that for Octave-core development I need an advice for the
workflow.

Up to now I update and build every week the octave sources via

hg pull
hg update
make (in my build directory)
make install

like described in
http://hg.savannah.gnu.org/hgweb/octave/file/tip/etc/HACKING

But this takes about an hour on my machine. That was my intention to
initially work in an Octave-forge package.

Now my question:
Let's say I made a code modification in "libinterp/corefcn/luinc.cc".
How do I get in a reasonable time (< 5 minutes) a "working Octave" and
compiler output that helps me to track errors in my code (that never
happens to me, of course ;-) ). What was your typical workflow for this
case?

> 2) There is an advantage in interfacing to ITSOL
> rather than including the source code in Octave,
> i.e. it will reduce the burden on Octave developers
> for maintaining the code at a later time.
> So I'd rather not dismiss
>
> c.
>

Yes I totally get your point and had a look about other libraries that
are included during the octave build process rather than maintaining the
sources by Octave itself. How do you handle the external library support
for Windows installations for example? (Sry, I only tried Octave
development with Ubuntu, so far). For Macs there you already created a
solution, as I've seen.
http://octave.1599824.n4.nabble.com/GSoC-Incomplete-factorization-project-ITSOL-tp4653386p4653649.html

Kai
c.
2013-06-04 21:58:53 UTC
Permalink
On 4 Jun 2013, at 23:45, Kai Torben Ohlhus <***@tuhh.de> wrote:

> Let's say I made a code modification in "libinterp/corefcn/luinc.cc".

As I finally dared to admit in a recent post I am not always completely sure
I understand what should go where in Octave's source tree, but I think your
file would fit better in

libinterp/dldfcn/luinc.cc


> How do I get in a reasonable time (< 5 minutes) a "working Octave" and compiler output that helps me to track errors in my code (that never happens to me, of course ;-) ). What was your typical workflow for this case?

if you touch just one file in that folder the build system does a pretty good
job in making sure only that file is rebuilt, for example

touch ../octave/libinterp/dldfcn/chol.cc
make

takes about 10s on my system

c.
c.
2013-06-05 05:48:41 UTC
Permalink
this message from Wei Jin to the maintainers list
was rejected due to its large attachment so I moved it to the
patch tracker :

https://savannah.gnu.org/patch/index.php?8068

it might be a good starting point for Kai's project but I'd rather
get rid of the mex files and make use of Octave's C++ API all over.

Thanks to Wei Jin for his contribution.

c.
Kai Torben Ohlhus
2013-06-05 07:29:14 UTC
Permalink
On 06/05/2013 07:48 AM, c. wrote:
> https://savannah.gnu.org/patch/index.php?8068

Are the attached files omitted?

Kai.
c.
2013-06-05 07:39:15 UTC
Permalink
On 5 Jun 2013, at 09:29, Kai Torben Ohlhus <***@tuhh.de> wrote:

> On 06/05/2013 07:48 AM, c. wrote:
>> https://savannah.gnu.org/patch/index.php?8068
>
> Are the attached files omitted?

to see the link to the file you need to scroll down to the bottom of the page till the "attached files" section.

> Kai.
c.
Kai Torben Ohlhus
2013-06-05 07:43:14 UTC
Permalink
On 06/05/2013 09:39 AM, c. wrote:
>
> On 5 Jun 2013, at 09:29, Kai Torben Ohlhus <***@tuhh.de> wrote:
>
>> On 06/05/2013 07:48 AM, c. wrote:
>>> https://savannah.gnu.org/patch/index.php?8068
>>
>> Are the attached files omitted?
>
> to see the link to the file you need to scroll down to the bottom of the page till the "attached files" section.
>
>> Kai.
> c.
>

Sorry, I was a little confused. Now I got it.

Kai
John W. Eaton
2013-07-03 01:55:44 UTC
Permalink
On 06/05/2013 03:29 AM, Kai Torben Ohlhus wrote:
> On 06/05/2013 07:48 AM, c. wrote:
>> https://savannah.gnu.org/patch/index.php?8068
>
> Are the attached files omitted?

There is a tar.gz file attached to patch tracker item #8068. Look near
the bottom of the page. Here's a direct link to the tar.gz file:

https://savannah.gnu.org/patch/download.php?file_id=28268

jwe
Kai Torben Ohlhus
2013-07-03 07:53:10 UTC
Permalink
On 3 July 2013 03:55, John W. Eaton <***@octave.org> wrote:

> On 06/05/2013 03:29 AM, Kai Torben Ohlhus wrote:
>
>> On 06/05/2013 07:48 AM, c. wrote:
>>
>>> https://savannah.gnu.org/**patch/index.php?8068<https://savannah.gnu.org/patch/index.php?8068>
>>>
>>
>> Are the attached files omitted?
>>
>
> There is a tar.gz file attached to patch tracker item #8068. Look near
> the bottom of the page. Here's a direct link to the tar.gz file:
>
> https://savannah.gnu.org/**patch/download.php?file_id=**28268<https://savannah.gnu.org/patch/download.php?file_id=28268>
>
> jwe
>
>
jwe: Thanks for the link. But this post is a bit older, so I already got
these files.

Nir: Yes, I will give an update soon. I'm struggeling a bit with ilutp.cc.
I updated the documentation and startet to create test cases.
Anyway I got a question to testing in Octave. There exists the test-markup
"%!" for DLD-functions like in
http://inversethought.com/hg/octave-kai/file/43e8f8031023/libinterp/dldfcn/eigs.cc
from
line 772 on. These can be called via "make check" after compiling AFAIK. Is
there a way to test the function eigs for example when you already run
octave like "test eigs" or from the GNU-build framework like "make check
libinterp/dldfcn/eigs.cc"? The first one seems to work only for m-files,
right? That would be very useful for my development, because I don't like
to check all Octave tests when I make a small change in my code.

Best,
Kai
marco atzeri
2013-07-03 09:13:31 UTC
Permalink
Il 7/3/2013 9:53 AM, Kai Torben Ohlhus ha scritto:
> On 3 July 2013 03:55, John W. Eaton wrote:
>
> On 06/05/2013 03:29 AM, Kai Torben Ohlhus wrote:
>
> On 06/05/2013 07:48 AM, c. wrote:
>
> https://savannah.gnu.org/__patch/index.php?8068
> <https://savannah.gnu.org/patch/index.php?8068>
>
>
> Are the attached files omitted?
>
>
> There is a tar.gz file attached to patch tracker item #8068. Look
> near the bottom of the page. Here's a direct link to the tar.gz file:
>
> https://savannah.gnu.org/__patch/download.php?file_id=__28268
> <https://savannah.gnu.org/patch/download.php?file_id=28268>
>
> jwe
>
>
> jwe: Thanks for the link. But this post is a bit older, so I already got
> these files.
>
> Nir: Yes, I will give an update soon. I'm struggeling a bit with
> ilutp.cc. I updated the documentation and startet to create test cases.
> Anyway I got a question to testing in Octave. There exists the
> test-markup "%!" for DLD-functions like in
> http://inversethought.com/hg/octave-kai/file/43e8f8031023/libinterp/dldfcn/eigs.cc from
> line 772 on. These can be called via "make check" after compiling AFAIK.
> Is there a way to test the function eigs for example when you already
> run octave like "test eigs" or from the GNU-build framework like "make
> check libinterp/dldfcn/eigs.cc"? The first one seems to work only for
> m-files, right? That would be very useful for my development, because I
> don't like to check all Octave tests when I make a small change in my code.
>
> Best,
> Kai


http://www.gnu.org/software/octave/doc/interpreter/Test-Functions.html#Test-Functions

from the interpreter something like

test ("/{fullpath}/libinterp/dldfcn/eigs.cc")

should work.

Regards
Marco
Nir Krakauer
2013-07-03 17:14:46 UTC
Permalink
> I'm struggeling a bit with ilutp.cc.

Can you post more on this to the list? Someone may be able to help you.
Nir Krakauer
2013-07-07 23:30:26 UTC
Permalink
Kai??

On Wed, Jul 3, 2013 at 1:14 PM, Nir Krakauer <***@ccny.cuny.edu> wrote:
>> I'm struggling a bit with ilutp.cc.
>
> Can you post more on this to the list? Someone may be able to help you.
Kai Torben Ohlhus
2013-07-08 12:23:55 UTC
Permalink
Here's a late update of my work on the ITSOL interface last week.

I spent some time on the issue of avoiding format conversions and
transpositions using the Incomplete LU-factorization. The results are not
overwhelming compared to MATLAB, but see and test yourself
http://siko1056-gsoc.blogspot.de/2013/07/the-transposition-problem.html.

This excursion helped me a lot in further understanding ITSOL. Now I will
return to the schedule and update the documentation, write the wrapper file
and complete the more comprehensive test cases. An updated ToDo list you
find here:
http://siko1056-gsoc.blogspot.de/2013/06/the-detailed-plan-of-action.html

Best,
Kai
Nir Krakauer
2013-07-08 14:03:01 UTC
Permalink
Thanks, Kai! Are you going to contact the original developers about ilutp?

Nir
Kai Torben Ohlhus
2013-07-08 16:18:34 UTC
Permalink
On 8 July 2013 16:03, Nir Krakauer <***@ccny.cuny.edu> wrote:

> Thanks, Kai! Are you going to contact the original developers about ilutp?
>
> Nir
>

Yes, I plan to contact the authors about that issue. Did Ruipeng Li or
Yousef Saad answer to this post already?
http://octave.1599824.n4.nabble.com/Addition-of-ITSOL-to-MXE-tp4654945p4655016.html

Kai
c.
2013-07-08 17:40:48 UTC
Permalink
On 8 Jul 2013, at 18:18, Kai Torben Ohlhus <***@gmail.com> wrote:

> On 8 July 2013 16:03, Nir Krakauer <***@ccny.cuny.edu> wrote:
> Thanks, Kai! Are you going to contact the original developers about ilutp?
>
> Nir
>
> Yes, I plan to contact the authors about that issue. Did Ruipeng Li or Yousef Saad answer to this post already?
> http://octave.1599824.n4.nabble.com/Addition-of-ITSOL-to-MXE-tp4654945p4655016.html
>
> Kai

No, not yet.
c.
Nir Krakauer
2013-07-08 17:21:19 UTC
Permalink
Yes, try sending them another message specifically about this.

While you are waiting for them, perhaps try modifying the ilut driver
to call ilutp so that you can check if it works?
Wei Jin
2013-06-05 08:17:37 UTC
Permalink
On Wed, 2013-06-05 at 07:48 +0200, c. wrote:
> this message from Wei Jin to the maintainers list
> was rejected due to its large attachment so I moved it to the
> patch tracker :
>
> https://savannah.gnu.org/patch/index.php?8068
>
> it might be a good starting point for Kai's project but I'd rather
> get rid of the mex files and make use of Octave's C++ API all over.
>

ilut.cc, iluk.cc are implemented by using Octave's C++ API. other mex
style files are easy to transform to original Octave API version.

> Thanks to Wei Jin for his contribution.
>
> c.
Kai Torben Ohlhus
2013-06-05 09:46:30 UTC
Permalink
On 06/05/2013 10:17 AM, Wei Jin wrote:
> On Wed, 2013-06-05 at 07:48 +0200, c. wrote:
>> this message from Wei Jin to the maintainers list
>> was rejected due to its large attachment so I moved it to the
>> patch tracker :
>>
>> https://savannah.gnu.org/patch/index.php?8068
>>
>> it might be a good starting point for Kai's project but I'd rather
>> get rid of the mex files and make use of Octave's C++ API all over.
>>
>
> ilut.cc, iluk.cc are implemented by using Octave's C++ API. other mex
> style files are easy to transform to original Octave API version.
>
>> Thanks to Wei Jin for his contribution.
>>
>> c.
>

Also from my side, thank you very much for your code Wei Jin! I will
make use of your interface. For the moment I'm not sure how far I use
your preconditioned GMRES implementations, that I'll decide later.

On 06/04/2013 11:58 PM, c. wrote:
>
> touch ../octave/libinterp/dldfcn/chol.cc
> make
>
> takes about 10s on my system
>
> c.
>

Pretty nice, this works for me in a minute, too. Haven't expected this!

On 06/05/2013 12:06 AM, c. wrote:
> On 4 Jun 2013, at 18:43, c. <***@gmail.com> wrote:
>
>> 2) There is an advantage in interfacing to ITSOL
>> rather than including the source code in Octave,
>> i.e. it will reduce the burden on Octave developers
>> for maintaining the code at a later time.
>> So I'd rather not dismiss
> this option before discussing it on the list.
>
> c.
>

On my way to the Debian/Ubuntu package of ITSOL
(http://packages.debian.org/source/sid/itsol) I get faced with an older
version (2011-09-11) of Saad's current (2012-10-26) ITSOL package that
is unfortunately connected with interface updates (functions were renamed).

Has anyone experience in updating debian packages? I hesitate to annoy
the maintainer Dominique Belhachemi with a bug report (because it isn't
a bug).

Kai.
Nir Krakauer
2013-06-09 13:14:23 UTC
Permalink
Hi Kai,

How is the preliminary work going? GSoC officially starts in one week,
so please develop some detailed goals and timeline. Let us know if you
get stuck somewhere.

Best,

Nir
Kai Torben Ohlhus
2013-06-09 19:21:52 UTC
Permalink
On 09.06.2013 15:14, Nir Krakauer wrote:
> Hi Kai,
>
> How is the preliminary work going? GSoC officially starts in one week,
> so please develop some detailed goals and timeline. Let us know if you
> get stuck somewhere.
>
> Best,
>
> Nir
>

Hi Nir and c.,

sorry for being very silent the last week, I'm going to catch up with my
reports for last and the upcoming week in my blog tomorrow. A short
excerpt of last week:

1. I worked on the implementation of Wei Jin and prepared it for
integration into the octave-core. There is still much work to do.

2. I ran occasionally successful Wei Jin's implementation (once per
octave runtime), but especially after running a simple test script
twice, I get faced with ugly memory leaks and SegFaults. End of last
week I spend lots of time to track those errors using DDD and gdb, but
wasn't successful so far, really frustrating, as those errors always
are... I think it has to do with the format conversion functions. A
little crash excerpt:

[CRASH START]
octave:2> test

*** Error in `octave': free(): invalid next size (fast):
0x0000000000b97430 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x80a46)[0x7f626e657a46]
/usr/local/lib/octave/3.7.5/liboctave.so.1(_ZN6SparseIdED1Ev+0x4a)[0x7f626dac980a]
/usr/local/lib/octave/3.7.5/liboctinterp.so.1(_ZN20octave_sparse_matrixD0Ev+0x40)[0x7f626f3b0da0]
/usr/local/lib/octave/3.7.5/liboctinterp.so.1(+0x6b855b)[0x7f626f35a55b]
/usr/local/lib/octave/3.7.5/liboctinterp.so.1(_ZN12octave_value6assignENS_9assign_opERKS_+0x3f)[0x7f626f3634cf]
/usr/local/lib/octave/3.7.5/liboctinterp.so.1(_ZN21tree_multi_assignment6rvalueEi+0x443)[0x7f626f3b5b03]
/usr/local/lib/octave/3.7.5/liboctinterp.so.1(_ZN21tree_multi_assignment7rvalue1Ei+0x68)[0x7f626f3b4e78]
/usr/local/lib/octave/3.7.5/liboctinterp.so.1(_ZN14tree_evaluator15visit_statementER14tree_statement+0x13d)[0x7f626f3bdd3d]
/usr/local/lib/octave/3.7.5/liboctinterp.so.1(_ZN14tree_evaluator20visit_statement_listER19tree_statement_list+0x71)[0x7f626f3bd781]
/usr/local/lib/octave/3.7.5/liboctinterp.so.1(_ZN18octave_user_script17do_multi_index_opEiRK17octave_value_list+0x179)[0x7f626f358569]
/usr/local/lib/octave/3.7.5/liboctinterp.so.1(_ZN12octave_value17do_multi_index_opEiRK17octave_value_list+0x11)[0x7f626f35c071]
/usr/local/lib/octave/3.7.5/liboctinterp.so.1(_ZN15tree_identifier6rvalueEiPKSt4listI13octave_lvalueSaIS1_EE+0x271)[0x7f626f3c37e1]
/usr/local/lib/octave/3.7.5/liboctinterp.so.1(_ZN15tree_identifier6rvalueEi+0xf)[0x7f626f3c396f]
/usr/local/lib/octave/3.7.5/liboctinterp.so.1(_ZN15tree_identifier7rvalue1Ei+0x68)[0x7f626f3c32e8]
/usr/local/lib/octave/3.7.5/liboctinterp.so.1(_ZN14tree_evaluator15visit_statementER14tree_statement+0x13d)[0x7f626f3bdd3d]
/usr/local/lib/octave/3.7.5/liboctinterp.so.1(_ZN14tree_evaluator20visit_statement_listER19tree_statement_list+0x71)[0x7f626f3bd781]
/usr/local/lib/octave/3.7.5/liboctinterp.so.1(_Z9main_loopv+0x114)[0x7f626f6b89c4]
/usr/local/lib/octave/3.7.5/liboctinterp.so.1(octave_execute_interpreter+0x5a1)[0x7f626efc42e1]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f626e5f8ea5]
octave[0x4009f1]
[... MUCH MORE...]
[CRASH END]

3. Regarding the debian package "problem" I decided to contact the
maintainer Dominique Belhachemi:

On 06.06.2013 15:59, Kai Torben Ohlhus wrote:
>
> Hello Dominique Belhachemi,
>
> was it possible to update the current debian packet itsol (1.0.0-2) from
> 2011-09-11
>
> http://packages.debian.org/source/wheezy/itsol
>
> to the newest version from 2012-10-26:
>
> http://www-users.cs.umn.edu/~saad/software/ITSOL/
>
> My intention is to interface ITSOL for GNU/Octave and thus I would
> prefer the most up to date version due to some interface changes between
> both versions. If I can help you with the update process, don't hesitate
> to tell me.
>
> Thanking you in anticipation,
>
> Kai Torben Ohlhus

And got very fast a reply, but so far there hasn't been an update, don't
know how long this process takes.

On 06.06.2013 16:05, Dominique Belhachemi wrote:> Hi Kai,
>
> Sure I can give it a try.
>
> -Dominique
>

But as you said c. I use an own compiled version which I integrated into
my Ubuntu, as the new debian package will.

For next week I plan to:
1. Make a good looking, understandable detail plan for the project, to
discuss the details easier with you Nir!
2. Continue my work on the SegFaults
3. If 2. succeeds, working on the integration in octave/libinterp/dldfcn

Kai
Kai Torben Ohlhus
2013-06-10 10:27:18 UTC
Permalink
On 06/09/2013 03:14 PM, Nir Krakauer wrote:
> Hi Kai,
>
> How is the preliminary work going? GSoC officially starts in one week,
> so please develop some detailed goals and timeline. Let us know if you
> get stuck somewhere.
>
> Best,
>
> Nir
>

Hi Nir,

here the promised plan. Deadlines follow soon in the linked google calendar.

http://siko1056-gsoc.blogspot.de/2013/06/the-detailed-plan-of-action.html

As you are living in the US and I in Germany, it might be difficult to
have a direct discussion about the project, what do you suggest for
getting to know each other?

Kai
Nir Krakauer
2013-06-10 11:43:36 UTC
Permalink
Thanks for the update, Kai! Please also add a preliminary timeline and
goals for the midterm and final evaluations (have both minimum goals
and hoped-for or "stretch" goals).

In terms of the segmentation faults, maybe try test cases that only
call the format conversion functions in order to isolate the problem?

Do you want to talk on Skype or another VoIP toward the end of this week?

Nir
c.
2013-06-10 12:07:44 UTC
Permalink
On 10 Jun 2013, at 13:43, Nir Krakauer <***@ccny.cuny.edu> wrote:

> In terms of the segmentation faults, maybe try test cases that only
> call the format conversion functions in order to isolate the problem?

Kai,

If you also want someone to be able to look at your code you should not be
posting it as attachments to the mailing list but rather

1) clone Octave's mercurial repository and put it somewhere where it is publicly accessibly (e.g. bitbucket or sourceforge)
2) create your own branch to work on
3) push changesets to your public repo regularly
4) pull from the default branch in the main Octave repo and merge into your branch very often.

I'm cc-ing our Mercurial guru Jordi to have him check if the proposed procedure looks right ;)

c.
Kai Torben Ohlhus
2013-06-10 15:00:35 UTC
Permalink
On 06/10/2013 04:24 PM, Jordi Gutiérrez Hermoso wrote:
> On 10 June 2013 08:07, c. <***@gmail.com> wrote:
>
>> 1) clone Octave's mercurial repository and put it somewhere where it
>> is publicly accessibly (e.g. bitbucket or sourceforge)
>
> Alternatively, you can give me your ssh public key, and I can setup a
> repo for you.
>
>> 2) create your own branch to work on
>
> You don't need to do anything to create a branch; this is done
> automatically when you start working on a new clone. You may
> optionally give your branch a bookmark so it's easier to refer to it.
> To do this, just do "hg bookmark your-bookmark-name". You can then
> later just tell me to pull that bookmark. This is just a naming
> convention; without the bookmark, you need to give me or someone else
> the hash of the changes that should be pulled.
>
>> 3) push changesets to your public repo regularly
>
>> 4) pull from the default branch in the main Octave repo and merge
>> into your branch very often.
>
> Yes, these two are fine.
>
> The whole process should be "easy", once we setup some hosting for
> your clone, but you can already start doing this without any public
> hosting.
>
> - Jordi G. H.
>

Hi Jordi and c.,

Thank you for your help. I started a new public repo at Google code. But
I can also switch to another one at octave. I generated a public-private
key pair according to this manual:

https://help.github.com/articles/generating-ssh-keys

Here is the content of id_rsa.pub (hope that is what you need Jordi):

ssh-rsa
AAAAB3NzaC1yc2EAAAADAQABAAABAQCnCOC/3CvXynZXf68QwFu47oEWx/1Xpe8PyPRCOfYLmpMWhjoz/2llKNMPgSpmh/68k0Rhpcxs952ATLeB3RnOMjJOncF82V8Q3aK3GiHEJ7JVLkA723DbQqgO5803DeGsODoE001ujiD+6eEPa9sOw1H25zlWndnWVhMxsjPYPYuaqViYjIZBJxi7JjZ+tdoZkfwLKApOP47Jf1ix8PR6stOKRuPXc0jkePQHtyB3NSdUBUmvdfZ8vR+BwiVA8VVbvgdQT7BOqqi3Yck6gChfpndqSgRt6DPDupAVjkNu5sV92fDTywFmF1hUA/dMdFzlx+gHzWmM3w2hLaV42/6L
***@gmail.com

Kai
c.
2013-06-26 08:00:40 UTC
Permalink
On 10 Jun 2013, at 18:14, Jordi Gutiérrez Hermoso <***@gmail.com> wrote:

> On 10 June 2013 11:00, Kai Torben Ohlhus <***@tuhh.de> wrote:
>>
>> Thank you for your help. I started a new public repo at Google code. But I
>> can also switch to another one at octave.
>
> As you wish, it doesn't make a huge difference. If you want to use the
> one I setup, you can clone this:
>
> hg clone ssh://***@inversethought.com/hg/repos/octave-kai
>
> This is its public web interface:
>
> http://inversethought.com/hg/octave-kai/
>
> HTH,
> - Jordi G. H.


Hi,
I'm trying to pull Kai's changes by either

hg pull http://inversethought.com/hg/octave-kai/
or
hg pull ssh://***@inversethought.com/hg/repos/octave-kai

but this doesn't seem to be working, am I doing something wrong or is there some problem with the repo?

c.
c.
2013-06-26 08:09:49 UTC
Permalink
On 26 Jun 2013, at 10:00, c. <***@gmail.com> wrote:

>
> On 10 Jun 2013, at 18:14, Jordi Gutiérrez Hermoso <***@gmail.com> wrote:
>
>> On 10 June 2013 11:00, Kai Torben Ohlhus <***@tuhh.de> wrote:
>>>
>>> Thank you for your help. I started a new public repo at Google code. But I
>>> can also switch to another one at octave.
>>
>> As you wish, it doesn't make a huge difference. If you want to use the
>> one I setup, you can clone this:
>>
>> hg clone ssh://***@inversethought.com/hg/repos/octave-kai
>>
>> This is its public web interface:
>>
>> http://inversethought.com/hg/octave-kai/
>>
>> HTH,
>> - Jordi G. H.
>
>
> Hi,
> I'm trying to pull Kai's changes by either
>
> hg pull http://inversethought.com/hg/octave-kai/
> or
> hg pull ssh://***@inversethought.com/hg/repos/octave-kai
>
> but this doesn't seem to be working, am I doing something wrong or is there some problem with the repo?
>
> c.


OK,
It seems it was neither, but actually a network problem.
I have now been able to pull, "hg heads" gives me:

$ hg heads
changeset: 16860:22df6c48442e
bookmark: kais-work
tag: tip
parent: 16859:04c46208fa46
parent: 16846:e6401864d791
user: Kai T. Ohlhus <***@gmail.com>
date: Tue Jun 25 17:16:14 2013 +0200
summary: Regular merge with Octave Repository.

changeset: 16853:b477c25dc9e0
user: Amod Mulay <***@gmail.com>
date: Sun Mar 24 18:57:06 2013 -0400
summary: doc: minor syntax changes in liboctave.texi to make it compatible with texinfo 5

changeset: 16851:209f0db3c32b
user: Rik <***@octave.org>
date: Tue Jun 25 18:43:58 2013 -0700
summary: mexErrMsgTxt should abort when called with an empty string (bug #39343).

changeset: 16698:13b3b92ea99c
branch: classdef
parent: 16696:665fa0f621cc
user: Michael Goffioul <***@gmail.com>
date: Fri May 24 15:41:52 2013 -0400
summary: Implement property accessors.

changeset: 16600:f2f5dd09e97d
branch: stable
user: Jordi Gutiérrez Hermoso <***@octave.org>
date: Wed May 01 14:41:50 2013 -0400
summary: doc: fix some minor sparse documentation oversights


Isn't that too many heads, what is "16853:b477c25dc9e0"?

c.
Kai Torben Ohlhus
2013-06-26 10:10:16 UTC
Permalink
On 26.06.2013 10:09, c. wrote:
>
> On 26 Jun 2013, at 10:00, c. <***@gmail.com> wrote:
>
>>
>> On 10 Jun 2013, at 18:14, Jordi Gutiérrez Hermoso <***@gmail.com> wrote:
>>
>>> On 10 June 2013 11:00, Kai Torben Ohlhus <***@tuhh.de> wrote:
>>>>
>>>> Thank you for your help. I started a new public repo at Google code. But I
>>>> can also switch to another one at octave.
>>>
>>> As you wish, it doesn't make a huge difference. If you want to use the
>>> one I setup, you can clone this:
>>>
>>> hg clone ssh://***@inversethought.com/hg/repos/octave-kai
>>>
>>> This is its public web interface:
>>>
>>> http://inversethought.com/hg/octave-kai/
>>>
>>> HTH,
>>> - Jordi G. H.
>>
>>
>> Hi,
>> I'm trying to pull Kai's changes by either
>>
>> hg pull http://inversethought.com/hg/octave-kai/
>> or
>> hg pull ssh://***@inversethought.com/hg/repos/octave-kai
>>
>> but this doesn't seem to be working, am I doing something wrong or is there some problem with the repo?
>>
>> c.
>
>
> OK,
> It seems it was neither, but actually a network problem.
> I have now been able to pull, "hg heads" gives me:
>
> $ hg heads
> changeset: 16860:22df6c48442e
> bookmark: kais-work
> tag: tip
> parent: 16859:04c46208fa46
> parent: 16846:e6401864d791
> user: Kai T. Ohlhus <***@gmail.com>
> date: Tue Jun 25 17:16:14 2013 +0200
> summary: Regular merge with Octave Repository.
>
> changeset: 16853:b477c25dc9e0
> user: Amod Mulay <***@gmail.com>
> date: Sun Mar 24 18:57:06 2013 -0400
> summary: doc: minor syntax changes in liboctave.texi to make it compatible with texinfo 5
>
> changeset: 16851:209f0db3c32b
> user: Rik <***@octave.org>
> date: Tue Jun 25 18:43:58 2013 -0700
> summary: mexErrMsgTxt should abort when called with an empty string (bug #39343).
>
> changeset: 16698:13b3b92ea99c
> branch: classdef
> parent: 16696:665fa0f621cc
> user: Michael Goffioul <***@gmail.com>
> date: Fri May 24 15:41:52 2013 -0400
> summary: Implement property accessors.
>
> changeset: 16600:f2f5dd09e97d
> branch: stable
> user: Jordi Gutiérrez Hermoso <***@octave.org>
> date: Wed May 01 14:41:50 2013 -0400
> summary: doc: fix some minor sparse documentation oversights
>
>
> Isn't that too many heads, what is "16853:b477c25dc9e0"?
>
> c.
>

Hi c.

my repository is messed up. I'll fix it in the code sprint and tell you.
Sorry for the inconvenience.

Kai
Kai Torben Ohlhus
2013-06-26 14:56:36 UTC
Permalink
On 26.06.2013 16:31, Jordi Gutiérrez Hermoso wrote:
>
> It got pulled in from Amod's repo. It's harmless. If you want to get
> rid of it, do "hg strip -r 3d8df32791c2". I have done so in the public
> repo.
>
> Kai, don't push this head back into the public repo.
>
> Btw, carlo, you can do "hg incoming
> http://inversethought.com/hg/octave-kai/ -r kais-work", and this
> should only show Kai's changes. If "incoming" looks good, you can
> replace it with "pull" to actually pull in the changes.
>
> - Jordi G. H.
>

Thank you Jordi, I will also publish the commands on my blog so others
can check in advance. I cloned the clean repo again. hg is very powerful -.-

Kai
Jordi Gutiérrez Hermoso
2013-06-26 17:51:44 UTC
Permalink
On 26 June 2013 10:56, Kai Torben Ohlhus <***@tuhh.de> wrote:
> On 26.06.2013 16:31, Jordi Gutiérrez Hermoso wrote:
>>
>>
>> It got pulled in from Amod's repo. It's harmless. If you want to get
>> rid of it, do "hg strip -r 3d8df32791c2". I have done so in the public
>> repo.

The extra head was my fault. I started your repo by copying over
Amod's, but I forgot to strip the copy of his work.

> hg is very powerful -.-

I hope this doesn't make it seem difficult to learn. I find that hg's
documentation is quite good. You should get in the habit of using "hg
help this" and "hg help that".

- Jordi G. H.
Nir Krakauer
2013-07-02 12:39:39 UTC
Permalink
Hi Kai,

Can you please post another progress report this week?

Thanks,

Nir
Jordi Gutiérrez Hermoso
2013-06-26 14:31:26 UTC
Permalink
On 26 June 2013 04:09, c. <***@gmail.com> wrote:

> It seems it was neither, but actually a network problem.
> I have now been able to pull, "hg heads" gives me:
>
> $ hg heads
> changeset: 16860:22df6c48442e
> bookmark: kais-work
> tag: tip
> parent: 16859:04c46208fa46
> parent: 16846:e6401864d791
> user: Kai T. Ohlhus <***@gmail.com>
> date: Tue Jun 25 17:16:14 2013 +0200
> summary: Regular merge with Octave Repository.
>
> changeset: 16853:b477c25dc9e0
> user: Amod Mulay <***@gmail.com>
> date: Sun Mar 24 18:57:06 2013 -0400
> summary: doc: minor syntax changes in liboctave.texi to make it compatible with texinfo 5
>
> changeset: 16851:209f0db3c32b
> user: Rik <***@octave.org>
> date: Tue Jun 25 18:43:58 2013 -0700
> summary: mexErrMsgTxt should abort when called with an empty string (bug #39343).
>
> changeset: 16698:13b3b92ea99c
> branch: classdef
> parent: 16696:665fa0f621cc
> user: Michael Goffioul <***@gmail.com>
> date: Fri May 24 15:41:52 2013 -0400
> summary: Implement property accessors.
>
> changeset: 16600:f2f5dd09e97d
> branch: stable
> user: Jordi Gutiérrez Hermoso <***@octave.org>
> date: Wed May 01 14:41:50 2013 -0400
> summary: doc: fix some minor sparse documentation oversights
>
>
> Isn't that too many heads, what is "16853:b477c25dc9e0"?

It got pulled in from Amod's repo. It's harmless. If you want to get
rid of it, do "hg strip -r 3d8df32791c2". I have done so in the public
repo.

Kai, don't push this head back into the public repo.

Btw, carlo, you can do "hg incoming
http://inversethought.com/hg/octave-kai/ -r kais-work", and this
should only show Kai's changes. If "incoming" looks good, you can
replace it with "pull" to actually pull in the changes.

- Jordi G. H.
Kai Torben Ohlhus
2013-06-10 14:34:10 UTC
Permalink
On 06/10/2013 01:43 PM, Nir Krakauer wrote:
> Thanks for the update, Kai! Please also add a preliminary timeline and
> goals for the midterm and final evaluations (have both minimum goals
> and hoped-for or "stretch" goals).
>
> In terms of the segmentation faults, maybe try test cases that only
> call the format conversion functions in order to isolate the problem?
>
> Do you want to talk on Skype or another VoIP toward the end of this week?
>
> Nir
>

Finally I posted the goals I want to archive:
http://siko1056-gsoc.blogspot.de/2013/06/the-detailed-plan-of-action.html

Skype sounds great. I negotiate a date for this with you off this
mailing list, except anyone is interested to join this talk ;-)

Kai
Jordi Gutiérrez Hermoso
2013-06-10 14:40:08 UTC
Permalink
On 10 June 2013 10:34, Kai Torben Ohlhus <***@tuhh.de> wrote:
> Skype sounds great. I negotiate a date for this with you off this mailing
> list, except anyone is interested to join this talk ;-)

If you want them, there are modern alternatives that don't require
letting the Microsoft, the NSA, and Stasi successors snooping on your
conversation, e.g. Jitsi or Ekiga:

https://jitsi.org/Main/HomePage
http://www.ekiga.org/

- Jordi G. H.
Nir Krakauer
2013-06-10 15:06:56 UTC
Permalink
Hi Kai,

These look good. I see the core of this project as implementing the
equivalent of Matlab's ilu and ichol (including full testing to verify
that they work correctly). Implementing additional sparse matrix
factorization functionality from ITSOL would be desirable but not
essential.

Can anyone test in Matlab whether ilu/ichol support complex sparse matrices?

Also, you'll be presenting on your project at OctConf in a couple
weeks, so you might want to add to your timeline what you'd like to be
able to show by then.

Nir

> Finally I posted the goals I want to archive:
> http://siko1056-gsoc.blogspot.de/2013/06/the-detailed-plan-of-action.html
Kai Torben Ohlhus
2013-06-10 16:38:19 UTC
Permalink
Nir Krakauer wrote:
> Can anyone test in Matlab whether ilu/ichol support complex sparse matrices?
>
> Nir

Just got access to one computer with matlab R2012b installed. Both ilu
and ichol can handle complex sparse input.

[MATLAB]
>> A = sparse([10 0 2+i; 0 2 0; 2+i 0 4]);
>> setup.type='nofill';
>> [L,U,P] = ilu(A,setup)

L =

(1,1) 1.0000
(3,1) 0.2000 + 0.1000i
(2,2) 1.0000
(3,3) 1.0000


U =

(1,1) 10.0000
(2,2) 2.0000
(1,3) 2.0000 + 1.0000i
(3,3) 3.7000 - 0.4000i


P =

(1,1) 1
(2,2) 1
(3,3) 1

>> L2 = ichol(A,setup)

L2 =

(1,1) 3.1623
(3,1) 0.6325 + 0.3162i
(2,2) 1.4142
(3,3) 1.8708

>> whos
Name Size Bytes Class Attributes

A 3x3 152 double sparse, complex
L 3x3 128 double sparse, complex
L2 3x3 152 double sparse, complex
P 3x3 80 double sparse
U 3x3 128 double sparse, complex
setup 1x1 188 struct
[/MATLAB]

So there was also an ZITSOL library for complex input
(http://www-users.cs.umn.edu/~saad/software/ITSOL/), but for the ichol I
think I will have to become creative.

Kai
Nir Krakauer
2013-06-10 17:33:18 UTC
Permalink
I haven't thought through it very carefully, but it seems like there
would be no change in the algorithm, just changing the variable types
should work?

> So there was also an ZITSOL library for complex input
> (http://www-users.cs.umn.edu/~saad/software/ITSOL/), but for the ichol I
> think I will have to become creative.
Nir Krakauer
2013-06-20 15:38:06 UTC
Permalink
Hi Kai--

Can you update your blog? How are things going with ILUT?

Best,

Nir
Kai Torben Ohlhus
2013-06-20 22:17:25 UTC
Permalink
On 06/20/2013 05:38 PM, Nir Krakauer wrote:
> Hi Kai--
>
> Can you update your blog? How are things going with ILUT?
>
> Best,
>
> Nir
>

Hey Nir,

I just updated my blog entry
http://siko1056-gsoc.blogspot.com/2013/06/the-detailed-plan-of-action.html

All interfaces are implemented and can be used if you had the latest
version of ITSOL integrated on your system (I write a little how-to for
this tomorrow. The current debian package is a little outdated, as
mentioned before in this mailing list). ILUTP (the threshold pivot
version) still doesn't like to work properly and makes some trouble at
the moment.
All ILUs need to be tested a lot for reliability and performance (I'm
not satisfied with many data format conversions for each ITSOL-library
call). For now I'm happy for seeing them work, but I can do it better.

Kind regards,

Kai
Nir Krakauer
2013-06-21 14:15:43 UTC
Permalink
Thanks for the update, Kai!

I don't see code for incomplete Cholesky factorization in ITSOL -- it
may be a good idea to ask Ruipeng and Yousef if have ideas on
implementing this, as well as with the other questions that have some
up; also, maybe some of theOctConf attendees will be helpful.

Have a good weekend,

Nir
c.
2013-06-21 16:08:51 UTC
Permalink
On 21 Jun 2013, at 16:15, Nir Krakauer <***@ccny.cuny.edu> wrote:

> Thanks for the update, Kai!
>
> I don't see code for incomplete Cholesky factorization in ITSOL -- it
> may be a good idea to ask Ruipeng and Yousef if have ideas on
> implementing this, as well as with the other questions that have some
> up; also, maybe some of theOctConf attendees will be helpful.
>
> Have a good weekend,
>
> Nir

According to The Book [1] section 10.4.5, ILUS should yield the incomplete Cholesky factor for the symmetric case.

c.

[1] http://www-users.cs.umn.edu/~saad/IterMethBook_2ndEd.pdf
Kai Torben Ohlhus
2013-06-22 15:52:28 UTC
Permalink
On 06/21/2013 06:08 PM, c. wrote:
>
> On 21 Jun 2013, at 16:15, Nir Krakauer <***@ccny.cuny.edu> wrote:
>
>> Thanks for the update, Kai!
>>
>> I don't see code for incomplete Cholesky factorization in ITSOL -- it
>> may be a good idea to ask Ruipeng and Yousef if have ideas on
>> implementing this, as well as with the other questions that have some
>> up; also, maybe some of theOctConf attendees will be helpful.
>>
>> Have a good weekend,
>>
>> Nir
>
> According to The Book [1] section 10.4.5, ILUS should yield the incomplete Cholesky factor for the symmetric case.
>
> c.
>
> [1] http://www-users.cs.umn.edu/~saad/IterMethBook_2ndEd.pdf
>
>

Hi Nir,

On the symmetric case (ichol) I want to work on after the midterm. First
I want to concentrate on the other ILUs included into ITSOL and complex
decomposition versions.

As far as I figured out, there was no implementation of ILUS from Saad's
book in ITSOL. But yes, it's a very good starting point for the ichols
(haven't considered that ILUS is the ichol case, thanks for this idea c.).

I have posted how I use ITSOL on my system and wish to be included to
the debian packages, but I still haven't seen any progress.
http://siko1056-gsoc.blogspot.de/2013/06/getting-itsol-to-work.html

Best wishes,

Kai
Nir Krakauer
2013-06-26 09:16:12 UTC
Permalink
> On the symmetric case (ichol) I want to work on after the midterm. First I
> want to concentrate on the other ILUs included into ITSOL and complex
> decomposition versions.

Makes sense to me.

> As far as I figured out, there was no implementation of ILUS from Saad's book in ITSOL. But yes, it's a very
> good starting point for the ichols (haven't considered that ILUS is the ichol case, thanks for this idea c.).

There seems to be software for this as part of something called
ILUPACK: http://www.icm.tu-bs.de/~bolle/ilupack/
Unfortunately, the license excludes commercial use. Maybe you can
contact the authors and ask if they would be willing to release it
under the GPL?

> I have posted how I use ITSOL on my system and wish to be included to the
> debian packages, but I still haven't seen any progress.
> http://siko1056-gsoc.blogspot.de/2013/06/getting-itsol-to-work.html

That's fine for now. We can figure out how to include the ITSOL
dependency in Octave at a later stage.
Nir Krakauer
2013-07-10 12:42:54 UTC
Permalink
Kai--

It is probably also a good idea to start integrating with the ZITSOL
functions for the complex case.

Best,

Nir
Kai Torben Ohlhus
2013-07-10 13:03:37 UTC
Permalink
On 10 July 2013 14:42, Nir Krakauer <***@ccny.cuny.edu> wrote:

> Kai--
>
> It is probably also a good idea to start integrating with the ZITSOL
> functions for the complex case.
>
> Best,
>
> Nir
>


Hi Nir,

yes I wait for information about ILUTP and in the meanwhile I'm working now
on ilu.m (the MATLAB wrapper) and then the last point on my
list<http://siko1056-gsoc.blogspot.de/2013/06/the-detailed-plan-of-action.html>before
the midterm is like you say ZITSOL (which includes ILUK, ILUT and
ILUTP in complex versions) and the comprehensive test cases.

Kai
c.
2013-07-10 13:41:13 UTC
Permalink
On 10 Jul 2013, at 15:03, Kai Torben Ohlhus <***@gmail.com> wrote:

> On 10 July 2013 14:42, Nir Krakauer <***@ccny.cuny.edu> wrote:
> Kai--
>

> and then the last point on my list before the midterm is like you say ZITSOL (which includes ILUK, ILUT and ILUTP in complex versions) and the comprehensive test cases.
>
> Kai

Hi Kai,

Actually I think it is a good idea to not wait until the very end of the project to start looking at the test cases.
Which makes me think that I had promised you to provide a simple way to generate automatically matrices for testing your preconditioners,
so here is a quick example:

-------------------------------------
pkg load bim

n = 50;

%% set beta = 0 for SPD matrix
beta = 1e4;

msh = msh3m_structured_mesh (n, n, n, 1, 1:6);
inodes = setdiff (1:columns (msh.p), bim3c_unknowns_on_faces (msh, 1:6));
x = msh.p(1,:) .';
A = bim3a_advection_diffusion (msh, 1, 1, 1, beta*x);
b = bim3a_rhs (msh, 1, 1);

%% the matrix to factorize is the one below
A = A(inodes, inodes);

%% solve the system by GE forcomparison
%% n = 80 is already to large to do this on my system;
b = b(inodes);
u = 0*x;
u(inodes) = A \ b;
-------------------------------------

for beta = 0 the matrix will be SPD and its condition number should scale as n^2
otherwise it will be unsymmetric.

n = 80 is already too large to handle via mldivide on my system it'd be very
interesting in to know the maximum size of system you can deal with by ilu+pcg
or ilu+gmres.

Also, what's your plan about ichol?

c.
Kai Torben Ohlhus
2013-07-11 14:54:49 UTC
Permalink
On 10 July 2013 15:41, c. <***@gmail.com> wrote:
>
>
> Hi Kai,
>
> Actually I think it is a good idea to not wait until the very end of the
> project to start looking at the test cases.
> Which makes me think that I had promised you to provide a simple way to
> generate automatically matrices for testing your preconditioners,
> so here is a quick example:
>
> -------------------------------------
> pkg load bim
>
> n = 50;
>
> %% set beta = 0 for SPD matrix
> beta = 1e4;
>
> msh = msh3m_structured_mesh (n, n, n, 1, 1:6);
> inodes = setdiff (1:columns (msh.p), bim3c_unknowns_on_faces (msh, 1:6));
> x = msh.p(1,:) .';
> A = bim3a_advection_diffusion (msh, 1, 1, 1, beta*x);
> b = bim3a_rhs (msh, 1, 1);
>
> %% the matrix to factorize is the one below
> A = A(inodes, inodes);
>
> %% solve the system by GE forcomparison
> %% n = 80 is already to large to do this on my system;
> b = b(inodes);
> u = 0*x;
> u(inodes) = A \ b;
> -------------------------------------
>
> for beta = 0 the matrix will be SPD and its condition number should scale
> as n^2
> otherwise it will be unsymmetric.
>
> n = 80 is already too large to handle via mldivide on my system it'd be
> very
> interesting in to know the maximum size of system you can deal with by
> ilu+pcg
> or ilu+gmres.
>
>
Thank you for the example c., but while I was trying to make use of the
package installer of octave-forge I found there was a little formatting
problem in the description file of "fpl" a dependency of "bim", it should
be fixed fast. I created a bug report with more details:
https://savannah.gnu.org/bugs/index.php?39464


> Also, what's your plan about ichol?
>
> c.


After the midterm I want to implement the function myself... AFAIK there is
no package containing this functionality. Maybe Ruipeng or Saad have a good
implementation, but you told me you had an M-File containing some
implementation, too?

Best,
Kai
Nir Krakauer
2013-07-11 15:30:01 UTC
Permalink
What about ILUPACK, assuming we could convince them to license it
under GPL? http://www.icm.tu-bs.de/~bolle/ilupack/


>> Also, what's your plan about ichol?
>>
>> c.
>
>
> After the midterm I want to implement the function myself... AFAIK there is
> no package containing this functionality. Maybe Ruipeng or Saad have a good
> implementation, but you told me you had an M-File containing some
> implementation, too?
Kai Torben Ohlhus
2013-07-11 15:55:06 UTC
Permalink
On 11 July 2013 17:30, Nir Krakauer <***@ccny.cuny.edu> wrote:

> What about ILUPACK, assuming we could convince them to license it
> under GPL? http://www.icm.tu-bs.de/~bolle/ilupack/
>
>
I had a look at ILUPACK, but I think this library is more concentrating on
solving linear systems with variants of ILUC
http://www.icm.tu-bs.de/~bolle/ilupack/doc/ilupack.shtml#temp2. Did you
find a IC(0) or something like this in it, Nir?
c.
2013-07-11 16:13:28 UTC
Permalink
On 11 Jul 2013, at 17:55, Kai Torben Ohlhus <***@gmail.com> wrote:

> On 11 July 2013 17:30, Nir Krakauer <***@ccny.cuny.edu> wrote:
> What about ILUPACK, assuming we could convince them to license it
> under GPL? http://www.icm.tu-bs.de/~bolle/ilupack/
>
>
> I had a look at ILUPACK, but I think this library is more concentrating on solving linear systems with variants of ILUC http://www.icm.tu-bs.de/~bolle/ilupack/doc/ilupack.shtml#temp2. Did you find a IC(0) or something like this in it, Nir?

And the license is VERY non free …
c.
Nir Krakauer
2013-07-11 16:08:21 UTC
Permalink
Hi Kai,

You may be right; I don't see it there

Nir

On Thu, Jul 11, 2013 at 11:55 AM, Kai Torben Ohlhus <***@gmail.com> wrote:
> I had a look at ILUPACK, but I think this library is more concentrating on
> solving linear systems with variants of ILUC
> http://www.icm.tu-bs.de/~bolle/ilupack/doc/ilupack.shtml#temp2. Did you find
> a IC(0) or something like this in it, Nir?
Nir Krakauer
2013-07-12 13:25:42 UTC
Permalink
Have you tried calling ZITSOL functions yet?
Nir Krakauer
2013-07-12 14:42:44 UTC
Permalink
Yes, would be worth checking if it returns the same result for a real
matrix as the ITSOL version

On Fri, Jul 12, 2013 at 10:34 AM, Kai Torben Ohlhus <***@gmail.com> wrote:
> On 12 July 2013 15:25, Nir Krakauer <***@ccny.cuny.edu> wrote:
>>
>> Have you tried calling ZITSOL functions yet?
>
>
> Not yet. There is also an ILUTP inside, maybe I can use that one.
Nir Krakauer
2013-07-14 22:38:25 UTC
Permalink
Kai, can you please update us on your project with a blog post?

Nir
Kai Torben Ohlhus
2013-07-15 00:11:05 UTC
Permalink
On 15 July 2013 00:38, Nir Krakauer <***@ccny.cuny.edu> wrote:

> Kai, can you please update us on your project with a blog post?
>
> Nir
>

Hello Nir,

here the news about the MATLAB wrapper file
http://siko1056-gsoc.blogspot.de/2013/07/a-matlab-wrapper.html.

Kai
Nir Krakauer
2013-07-15 01:16:38 UTC
Permalink
Thanks, Kai!

I think you should implement the ZITSOL functions this week so that
ILU will work with complex test cases.

Nir
Nir Krakauer
2013-07-21 13:48:10 UTC
Permalink
Hi Kai,

I saw your blog post about interfacing with ZITSOL.

I think that we should leave the ILUTP implementation until after the
midterm, and for the midterm objectives focus on:

1) implementation of ILUK and ILUC for real and complex sparse matrices

2) ILU wrapper to ILUK and ILUC as in Matlab, with a placeholder for
ILUTP (something like warning('implementation with pivoting not
implemented/tested yet') )

3) wrapper should include tests of all implemented ILU capabilities

Let me know if this seems agreeable.

Nir
Kai Torben Ohlhus
2013-07-21 19:07:08 UTC
Permalink
On 21 July 2013 15:48, Nir Krakauer <***@ccny.cuny.edu> wrote:

> Hi Kai,
>
> I saw your blog post about interfacing with ZITSOL.
>
> I think that we should leave the ILUTP implementation until after the
> midterm, and for the midterm objectives focus on:
>
> 1) implementation of ILUK and ILUC for real and complex sparse matrices
>
> 2) ILU wrapper to ILUK and ILUC as in Matlab, with a placeholder for
> ILUTP (something like warning('implementation with pivoting not
> implemented/tested yet') )
>
> 3) wrapper should include tests of all implemented ILU capabilities
>
> Let me know if this seems agreeable.
>
> Nir
>

Hi Nir,

yes, I agree to your plan. ILUK and ILUT work for real and complex input
matrices.

Only the implementation of ILUC for the complex case (part of ZITSOL) has
been removed for unknown reasons. Should I add this method to ZITSOL via an
patch as a workaround for the moment? Basically, the difference between
real and complex versions of the solvers is the data type (double vs.
complex double).

About ILUTP I still have no clue in neither version how to use it
correctly. Thus I spend the last week with completing the documentation,
testing and improving and tiding up the code.

I will announce a stand-alone sample version for the preconditioners in my
blog soon.

Kai
Nir Krakauer
2013-07-21 22:00:33 UTC
Permalink
> Only the implementation of ILUC for the complex case (part of ZITSOL) has
> been removed for unknown reasons. Should I add this method to ZITSOL via an
> patch as a workaround for the moment? Basically, the difference between real
> and complex versions of the solvers is the data type (double vs. complex
> double).

Yes, please try that.

> About ILUTP I still have no clue in neither version how to use it correctly.
> Thus I spend the last week with completing the documentation, testing and
> improving and tiding up the code.

Sounds good, we can worry about ILUTP after the midterm.

> I will announce a stand-alone sample version for the preconditioners in my
> blog soon.

Great!

Nir
Kai Torben Ohlhus
2013-07-22 13:15:55 UTC
Permalink
On 22 July 2013 00:00, Nir Krakauer <***@ccny.cuny.edu> wrote:

> > Only the implementation of ILUC for the complex case (part of ZITSOL) has
> > been removed for unknown reasons. Should I add this method to ZITSOL via
> an
> > patch as a workaround for the moment? Basically, the difference between
> real
> > and complex versions of the solvers is the data type (double vs. complex
> > double).
>
> Yes, please try that.

[...]
>

> Nir
>

I "succeeded" with a complex ILUC (
https://docs.google.com/file/d/0B4V9W1l15-xMRjBXLTFTOVUwZnM/edit?usp=sharing).
The user gets warned at the complex function call, that this is an
experimental function. This naive implementation doesn't last for too long
hopefully. Compared to MATLAB my implementation seems less reliable. When I
execute this code:

[code]
clear all
clc
setup.type = 'crout';
setup.milu = 'off';
setup.droptol = 1e-4;
A = sprand(200,200,0.01);
A = A + speye(200);
A(1,3) = 10 + 1i;
[L,U] = ilu(A, setup);
norm(L*U - A, 1)
[/code]

MATLAB produces absolute errors about 10^-3 to 10^-4 and my implementation
10^-1 to 10^4. For small test cases 5x5 the results differ in about 2
elements. I'm a bit unhappy about this, but I don't want to spend more time
on complex ILUC. I'm sure Prof. Saad has already a better implementation.
Now I continue with my other tasks.

Kai
Nir Krakauer
2013-07-22 14:26:13 UTC
Permalink
Sounds OK for now. What happens if you do the same comparison with the
real ILUC implementation? Is the accuracy similar to Matlab?

> MATLAB produces absolute errors about 10^-3 to 10^-4 and my implementation
> 10^-1 to 10^4. For small test cases 5x5 the results differ in about 2
> elements. I'm a bit unhappy about this, but I don't want to spend more time
> on complex ILUC. I'm sure Prof. Saad has already a better implementation.
> Now I continue with my other tasks.
Kai Torben Ohlhus
2013-07-23 07:59:48 UTC
Permalink
On 22 July 2013 16:26, Nir Krakauer <***@ccny.cuny.edu> wrote:

> Sounds OK for now. What happens if you do the same comparison with the
> real ILUC implementation? Is the accuracy similar to Matlab?
>
> > MATLAB produces absolute errors about 10^-3 to 10^-4 and my
> implementation
> > 10^-1 to 10^4. For small test cases 5x5 the results differ in about 2
> > elements. I'm a bit unhappy about this, but I don't want to spend more
> time
> > on complex ILUC. I'm sure Prof. Saad has already a better implementation.
> > Now I continue with my other tasks.
>

Sorry, yesterday I had no MATLAB available when you asked. For the real
case both implementations have an absolute error about 10^-3 to 10^-4.

Kai
Nir Krakauer
2013-07-23 11:50:52 UTC
Permalink
That's encouraging. You can include at least the real case as one of
the tests for the ILU function.
Nir Krakauer
2013-07-28 13:47:02 UTC
Permalink
Hi Kai,

As you know, the midterm evaluations are this week. Please post a
midterm progress report on your blog by Monday or Tuesday.

Best,

Nir
Nir Krakauer
2013-07-29 16:28:40 UTC
Permalink
Kai--

Thanks for the blog post. Do iluc, iluk, and ilut now pass their
tests? Have you been able to check if the version of ilutp in ZITSOL
works?

Best,

Nir
Kai Torben Ohlhus
2013-07-29 16:43:09 UTC
Permalink
On 29 July 2013 18:28, Nir Krakauer <***@ccny.cuny.edu> wrote:

> Kai--
>
> Thanks for the blog post. Do iluc, iluk, and ilut now pass their
> tests? Have you been able to check if the version of ilutp in ZITSOL
> works?
>
> Best,
>
> Nir
>

Hi Nir,

sorry, that update on Blogspot wasn't the official midterm post (still
polishing the last big example code with MATLAB comparison). When I update
some old blog entries, it is treated as new...

My progress so far (I publish a post this evening on Blogspot as well):
- All relevant ILU are fully interfaced and pass their test except for
ILUTP for real and complex case (it's just the same code with interchanged
data types). I hope to get an example call by Saad or Ruipeng Li some day.
- The modified ILU (MILU) option cannot be implemented because it would
require a changing of ITSOL (that was also a part of my request to Saad and
Ruipeng Li).
- The MATLAB wrapper ensures compatibility except for permutation
(therefore ILUTP would be needed) and the MILU option.
- All functions contain comprehensive test cases and documentation.

Kai
Kai Torben Ohlhus
2013-07-29 22:40:25 UTC
Permalink
Hello Nir,

finally here my more verbose midterm summary:
http://siko1056-gsoc.blogspot.de/2013/07/midterm-summary.html.

Best,

Kai
Nir Krakauer
2013-07-30 11:57:54 UTC
Permalink
Hi Kai,

This looks great! Can you also do a post on goals for the second half
of the project?

Thanks,

Nir
c.
2013-08-02 06:24:02 UTC
Permalink
On 30 Jul 2013, at 13:57, Nir Krakauer <***@ccny.cuny.edu> wrote:

> Hi Kai,
>
> This looks great! Can you also do a post on goals for the second half
> of the project?
>
> Thanks,
>
> Nir

Kai,

I think you should start fixing your commit messages ASAP
to avoid messing up the main repo when your code gets merged in.

I think the sooner you do this, the better, it should probably the first
step in the plan for the rest of the project. And please try to adhere
to the style giudelines for code and commit messages from now on.

c.
c.
2013-07-11 16:12:50 UTC
Permalink
On 11 Jul 2013, at 16:54, Kai Torben Ohlhus <***@gmail.com> wrote:

> Thank you for the example c., but while I was trying to make use of the package installer of octave-forge I found there was a little formatting problem in the description file of "fpl" a dependency of "bim", it should be fixed fast. I created a bug report with more details: https://savannah.gnu.org/bugs/index.php?39464

well, that's actually a regression in Octave as fpl installs correctly on the stable version of Octave:

octave:1> pkg install -forge fpl
For information about changes from previous versions of the fpl package, run 'news ("fpl")'.
octave:2> version
ans = 3.6.2

I don't think pkg.m has been modified recently so probably this is due to the work being done on regexp?

> After the midterm I want to implement the function myself... AFAIK there is no package containing this functionality. Maybe Ruipeng or Saad have a good implementation, but you told me you had an M-File containing some implementation, too?

I can't find the version I mentioned at OctConf but anyway that was just ichol0 so it did approximately just:

A = tril (M);
for k=1:n
A(k,k) = sqrt (A(k,k));
A((k+1:n)(abs (A((k+1:n),k)) >= tol), k) /= A(k,k);
for j = k+1:n
i = (j:n)(abs (A((j:n),j)) >= tol);
A(i,j) -= A(i,k) * A(j,k);
endfor
endfor


> Best,
> Kai

c.
c.
2013-06-09 17:11:21 UTC
Permalink
On 5 Jun 2013, at 11:46, Kai Torben Ohlhus <***@tuhh.de> wrote:

> Has anyone experience in updating debian packages? I hesitate to annoy the maintainer Dominique Belhachemi with a bug report (because it isn't a bug).

It is a feature request, which is OK to ask for, so don't be shy to ask for it.
Telling the package maintainer that this will be a dependence for Octave in the
near future might make him more interested in your request.

On the other hand you do not need to have ITSOL installed as a package to start working on it,
Just download the source, compile it an install it somewhere on your computer, for example in
put headers in

/opt/ITSOL/include/ITSOL

and libraries in

/opt/ITSOL/lib

Then configure Octave with

configure CPPFLAGS=/opt/ITSOL/include LDFALGS=-/opt/ITSOL/lib

so that it can find the headers and libraries.

c.
marco atzeri
2013-06-26 16:22:41 UTC
Permalink
Il 6/9/2013 7:11 PM, c. ha scritto:
>
> On 5 Jun 2013, at 11:46, Kai Torben Ohlhus wrote:
>
>> Has anyone experience in updating debian packages? I hesitate to annoy the maintainer Dominique Belhachemi with a bug report (because it isn't a bug).
>
> It is a feature request, which is OK to ask for, so don't be shy to ask for it.
> Telling the package maintainer that this will be a dependence for Octave in the
> near future might make him more interested in your request.
>

I just looked at the package ITSOL v2.
It has no conf/build system, so debian packager for v1 just added
a cmake conf/build one.

It will be better suggesting Saad to add it directly on its
upstream package adapting the debian one.
It will help a lot in packaging the library for every platform.


Regards
Marco
Jordi Gutiérrez Hermoso
2013-06-05 16:04:16 UTC
Permalink
On 4 June 2013 17:58, c. <***@gmail.com> wrote:
>
> On 4 Jun 2013, at 23:45, Kai Torben Ohlhus <***@tuhh.de> wrote:
>
>> Let's say I made a code modification in "libinterp/corefcn/luinc.cc".
>
> As I finally dared to admit in a recent post I am not always completely sure
> I understand what should go where in Octave's source tree, but I think your
> file would fit better in
>
> libinterp/dldfcn/luinc.cc

libinterp/dldffcn makes sense for ITSOL, since it's an external
library that doesn't need to be loaded every time Octave starts. It
used to be that we had a lot of other functions in there, even for
functions that didn't actually use external libraries. It makes sense
to avoid the dlopen system call or equivalent for functions that
aren't actually loading external libraries.

The other three subdirectories under libinterp already mentioned
should probably be merged somehow into a single one.

- Jordi G. H.
Jordi Gutiérrez Hermoso
2013-06-05 16:01:52 UTC
Permalink
On 4 June 2013 17:45, Kai Torben Ohlhus <***@tuhh.de> wrote:
> I must admit that for Octave-core development I need an advice for the
> workflow.
>
> Up to now I update and build every week the octave sources via
>
> hg pull
> hg update
> make (in my build directory)
> make install
>
> like described in
> http://hg.savannah.gnu.org/hgweb/octave/file/tip/etc/HACKING
>
> But this takes about an hour on my machine. That was my intention to
> initially work in an Octave-forge package.

You don't need to recompile all of Octave each time you're working on
a single function of it. You normally only compile Octave once, and
recompile the necessary parts as you track development ("hg pull" and
"hg update").

Also, what hardware are you using? You probably have more than one
processor core. If so, you can do "make -jN" where N is how many
concurrent compiler jobs you think your hardware can run.

- Jordi G. H.
c.
2013-06-04 22:06:16 UTC
Permalink
oops, I noticed just now I had pushed send before finishing the message ...

On 4 Jun 2013, at 18:43, c. <***@gmail.com> wrote:

> 2) There is an advantage in interfacing to ITSOL
> rather than including the source code in Octave,
> i.e. it will reduce the burden on Octave developers
> for maintaining the code at a later time.
> So I'd rather not dismiss
this option before discussing it on the list.


c.
Kai Torben Ohlhus
2013-06-10 16:49:05 UTC
Permalink
On 06/10/2013 06:14 PM, Jordi Gutiérrez Hermoso wrote:
> On 10 June 2013 11:00, Kai Torben Ohlhus <***@tuhh.de> wrote:
>>
>> Thank you for your help. I started a new public repo at Google code. But I
>> can also switch to another one at octave.
>
> As you wish, it doesn't make a huge difference. If you want to use the
> one I setup, you can clone this:
>
> hg clone ssh://***@inversethought.com/hg/repos/octave-kai
>
> This is its public web interface:
>
> http://inversethought.com/hg/octave-kai/
>
> HTH,
> - Jordi G. H.
>

Thank you very much Jordi!
Loading...