bugGNU Octave - Bugs: bug #52425, eigs function regresses

 
 

bug #52425: eigs function regresses

Submitter:  A.R. Burgers <arb>
Submitted:  Fri 17 Nov 2017 08:19:28 AM UTC
   
 
Category:  Octave Function Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 19 Apr 2018 04:53:43 PM UTC, comment #35: 

Posting here because of how closely this seems related to a eigs.m test I have failing on Ubuntu 18.04 (very recent), ARPACK, 64-bit build.

https://savannah.gnu.org/bugs/index.php?53700

Dan Sebald <sebald>
Thu 30 Nov 2017 12:51:18 AM UTC, comment #34: 

E.g.:

>>>>> processing /scratch/buildbot/slaves/jwe-debian-x86_64-0/clang-4_0-debian/src/scripts/sparse/eigs.m

*** testif HAVE_ARPACK
 A = toeplitz ([-2, 1, zeros(1, 8)]);
 A = kron (A, eye (10)) + kron (eye (10), A);
 opts.v0 = (1:100)';
 opts.maxit = 3;
 warning ("off", "Octave:eigs:UnconvergedEigenvalues", "local");
 d = eigs (A, 4, "lm", opts);
 assert (d(2:4), [NaN; NaN; NaN]);
!!!!! test failed
ASSERT errors for:  assert (d (2:4),[NaN; NaN; NaN])

  Location  |  Observed  |  Expected  |  Reason
    (1)         -7.365        NaN        'NaN' mismatch
*** testif HAVE_ARPACK
 A = toeplitz ([-2, 1, zeros(1, 8)]);
 A = kron (A, eye (10)) + kron (eye (10), A);
 Afun = @(x) A * x;
 opts.v0 = (1:100)';
 opts.maxit = 3;
 opts.issym = true;
 warning ("off", "Octave:eigs:UnconvergedEigenvalues", "local");
 d = eigs (Afun, 100, 4, "sm", opts);
 assert (d(2:4), [NaN; NaN; NaN]);
!!!!! test failed
ASSERT errors for:  assert (d (2:4),[NaN; NaN; NaN])

  Location  |  Observed  |  Expected  |  Reason
    (1)        -0.13578       NaN        'NaN' mismatch
*** testif HAVE_ARPACK
 A = magic (100);
 opts.v0 = (1:100)';
 opts.maxit = 1;
 warning ("off", "Octave:eigs:UnconvergedEigenvalues", "local");
 d = eigs (A, 4, "lm", opts);
 assert (d(4), NaN);
!!!!! test failed
ASSERT errors for:  assert (d (4),NaN)

  Location  |  Observed  |  Expected  |  Reason
     ()       3.8548e-11      NaN        'NaN' mismatch
*** testif HAVE_ARPACK
 A = magic (100) / 100 + eye (100);
 opts.v0 = (1:100)';
 opts.maxit = 1;
 warning ("off", "Octave:eigs:UnconvergedEigenvalues", "local");
 d = eigs (A, 4, "sm", opts);
 assert (d(3:4), [NaN+1i*NaN; NaN+1i*NaN]);
!!!!! test failed
eigs: error -14 in dneupd
*** testif HAVE_ARPACK
 A = 1i * magic (100) / 100 + eye (100);
 opts.v0 = (1:100)';
 opts.maxit = 1;
 warning ("off", "Octave:eigs:UnconvergedEigenvalues", "local");
 d = eigs (A, 4, "sm", opts);
 assert (d(2:4), [NaN+1i*NaN; NaN+1i*NaN; NaN+1i*NaN]);
!!!!! test failed
eigs: error -14 in zneupd

Dmitri A. Sergatskov <dasergatskov>
Thu 30 Nov 2017 12:42:20 AM UTC, comment #33: 

I am away from my computer -- but look at the buildbots, all of them are failing...

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Thu 30 Nov 2017 12:17:53 AM UTC, comment #32: 

Works for me.


octave:1> test eigs
PASSES 179 out of 179 tests


This is with 24337:999b167e5b4a.

Rik <rik5>
Group administrator
Wed 29 Nov 2017 11:06:04 PM UTC, comment #31: 

Bunch of eigs tests are failing

See: http://buildbot.octave.org:8010/waterfall

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Wed 29 Nov 2017 09:48:30 PM UTC, comment #30: 

Great!  I pushed the final changeset here http://hg.savannah.gnu.org/hgweb/octave/rev/0771ce2d30ef.


Rik <rik5>
Group administrator
Wed 29 Nov 2017 09:13:37 PM UTC, comment #29: 

@Rik: The patch (file #42524) lets me go on as before.  Thank you for that and please push that one as well!  Most of the FORTRAN checks don't need that save&restore as they do not really compile any FORTRAN source code.

Just for the files: my prior workaround (comment #26) did not work.  Using "-fdefault-integer-8" within the FFLAGS causes  liboctave/external/ranlib (all FORTRAN) to be compiled with INTEGER == uint64_t and messes up all RNGs that rely on 32 bit integers... It really raises some doubts about the reliability of Octave's FORTRAN heritage, but that is for another bug report.


./configure [...] F77_INTEGER_8_FLAG='-fdefault-integer-8' [...] --enable-64 [...] --with-arpack='-larpack_Octave64'

[snip]

checking for dseupd in -larpack_Octave64... yes
checking whether the arpack library works... yes
checking whether the arpack library is free of bugs... yes

[snip]

  64-bit array dims and indexing:       yes
  64-bit BLAS array dims and indexing:  yes

[snip]

Summary:

  PASS                            15943
  FAIL                                0
  XFAIL (expected failure)            5
  XFAIL (reported bug)               32
  SKIPPED (feature)                  37


Yesterday there were unnoticed errors.

Kai Torben Ohlhus <siko1056>
Group Member
Wed 29 Nov 2017 07:19:50 PM UTC, comment #28: 

I checked in the fix that disabled ARPACK, rather than merely warning about it being buggy, here (http://hg.savannah.gnu.org/hgweb/octave/rev/740c6a7db92a).

@Kai: Can you try the attached patch integer8.diff?  In it I simply add F77_INTEGER_8_FLAG to FFLAGS before compiling the Fortran code.  This is the right thing to do, I just didn't think about it because I don't do much with Fortran.  If you report it working then I'll commit that change as well.


patch -p1 < integer8.diff
./bootstrap
./configure


That should be all you need to do to see whether it worked.


(file #42524)

Rik <rik5>
Group administrator
Wed 29 Nov 2017 08:55:50 AM UTC, comment #27: 
A.R. Burgers <arb>
Tue 28 Nov 2017 08:52:30 PM UTC, comment #26: 

@Rik: after some more investigation, I found that the "F77_INTEGER_8_FLAG" is ignored by the new test of comment #20.  But I think that after those many changes on configure and 64-bit indexing, that the original meaning [1] has changed anyway.  The solution for me is to write "-fdefault-integer-8" in both "F77_INTEGER_8_FLAG" and "FFLAGS".  In combination with you patch (file #42507) configure now works for me again, please push you patch.

[1] https://www.gnu.org/software/octave/doc/interpreter/Compiling-Octave-with-64_002dbit-Indexing.html

Kai Torben Ohlhus <siko1056>
Group Member
Tue 28 Nov 2017 05:33:05 PM UTC, comment #25: 

@Kai: We prefer to test for capabilities, rather than version numbers, because version numbers can be unreliable.  What if someone forks the ARPACK-ng codebase starting at version 3.0.0 and calls their library ARPACK-ng2 and starts with revision 1.0.0?

Does the diff I included in comment #23 help with your builds?

Rik <rik5>
Group administrator
Tue 28 Nov 2017 04:47:05 PM UTC, comment #24: 

Dear Rik, the new ARPACK test from changeset from comment #20 works fine for straight forward Octave 4.3.0+ compilation using ARPACK 3.5.0, but it no longer works for my 64-bit index "-fdefault-integer-8" compiled libraries.

A long story in short: Wasn't it possible to simply check for the ARPACK version and reject < 3.3.0?  I do pass all the test-suite of ARPACK itself, but not the new one of Octave:


PASS: dnsimp
PASS: bug_1315_single
PASS: bug_1315_double
PASS: bug_1323
PASS: bug_58_double
==========================================
Testsuite summary for ARPACK-NG 3.5.0
==========================================
# TOTAL: 5
# PASS:  5
# SKIP:  0
# XFAIL: 0
# FAIL:  0
# XPASS: 0
# ERROR: 0
==========================================


Even though you had a lot of work with refactoring the test in FORTRAN for Octave and merging (comment #20), it is a bug of ARPACK, it is tested there, so why should OCTAVE duplicate that test?

Kai Torben Ohlhus <siko1056>
Group Member
Tue 28 Nov 2017 12:21:38 AM UTC, comment #23: 

Try the attached diff.  If it works I'll convert it to a proper changeset.


patch -p1 < 52425.diff
./bootstrap
./configure
make




(file #42507)

Rik <rik5>
Group administrator
Mon 27 Nov 2017 08:27:03 PM UTC, comment #22: 

After the recent configure changes for arpack,with the arpack 3.0.1 I had installed in stdout of configure script:


checking for dseupd in -larpack... yes
checking whether the arpack library works... yes
checking whether the arpack library is free of bugs... no
configure: WARNING: ARPACK library found, but is buggy; upgrade library (>= v3.3.0) for better results


in config.log


octave_cv_lib_arpack=yes
octave_cv_lib_arpack_ok_1=yes
octave_cv_lib_arpack_ok_2=no


So the detection seems to work as intended.
However during make arpack functions are not found:


CXXLD    src/octave-gui
liboctave/.libs/liboctave.so: undefined reference to `znaupd_'
liboctave/.libs/liboctave.so: undefined reference to `dsaupd_'
liboctave/.libs/liboctave.so: undefined reference to `dnaupd_'
liboctave/.libs/liboctave.so: undefined reference to `zneupd_'
liboctave/.libs/liboctave.so: undefined reference to `dneupd_'
liboctave/.libs/liboctave.so: undefined reference to `dseupd_'


the ARPACK related substitutions in the configure script are empty:


S["ARPACK_LIBS"]=""
S["ARPACK_LDFLAGS"]=""
S["ARPACK_CPPFLAGS"]=""


A.R. Burgers <arb>
Wed 22 Nov 2017 07:12:40 AM UTC, comment #21: 

@Rik: thanks. I put here the link to the original arpack bug

https://github.com/opencollab/arpack-ng/pull/19

as a reference.

Marco Caliari <caliari>
Group Member
Wed 22 Nov 2017 02:47:59 AM UTC, comment #20: 

I put in testing for a bugy ARPACK library here http://hg.savannah.gnu.org/hgweb/octave/rev/f52d91f6ef80.

The merge of stable to default did not go well.  I think I got it right in the end, but it was painful.  We should encourage everyone that makes changes on stable to do the merge on to default immediately so someone who understands the code changes can correct any merge issues.  In this case there were problems merging in Qt GUI code from Torsten that I had to work through without a real understanding.

Rik <rik5>
Group administrator
Wed 22 Nov 2017 01:19:50 AM UTC, comment #19: 

@jwe: The ARPACK version required is >= 3.3.0.  In MXE build we use 3.5.0 so no problems there.

I think I can make the two checks in to one macro.  I'll try anyways.

Rik <rik5>
Group administrator
Tue 21 Nov 2017 10:29:09 PM UTC, comment #18: 

Seems OK to me to test for this.

Is the version of ARPACK we use in mxe-octave OK?

Both OCTAVE_CHECK_LIB_ARPACK_OK and OCTAVE_CHECK_LIB_ARPACK_BUGGY both check for bugs, correct?  Maybe these should be OCTAVE_CHECK_LIB_ARPACK_OK_1 and ..._OK_2 and OCTAVE_CHECK_LIB_ARPACK_OK could use these sub-macros?  It's not critical, but it might make it easier to understand.  If you don't have time, make a note of that in a comment for the original _OK function?

John W. Eaton <jwe>
Group administrator
Tue 21 Nov 2017 10:17:30 PM UTC, comment #17: 

Adding jwe to the CC list.

@jwe: There is already a macro in m4/acinclude.m4 (OCTAVE_CHECK_LIB_ARPACK_OK) which compiles and runs a C++ piece of code to determine if the ARPACK library is okay.  I added a new macro OCTAVE_CHECK_LIB_ARPACK_BUGGY which compiles and runs a piece of Fortran code from Marco to determine if the ARPACK library works, but is buggy.  Should this be committed before the 4.2.2 release?

The patch is attached.

(file #42454)

Rik <rik5>
Group administrator
Tue 21 Nov 2017 07:56:21 PM UTC, comment #16: 

The attached file bug_52425.f should do the job.

Another possibility is to use bug_1315_double.c from arpack

https://github.com/opencollab/arpack-ng/blob/master/TESTS/bug_1315_double.c

(file #42453)

Marco Caliari <caliari>
Group Member
Tue 21 Nov 2017 05:59:26 PM UTC, comment #15: 

The preference is to test for features, rather than version numbers, in configure scripts.

It seems like the existing Fortran test code from Marco almost does that.  If it could be converted into returning a 1 or 0 as an exit code, rather than printing results to stdout, then it could be wrapped in a configure test.

Rik <rik5>
Group administrator
Tue 21 Nov 2017 09:27:23 AM UTC, comment #14: 

This is a clear sign of the bug in arpack I mentioned: different eigenvalues when eigenvectors are required. So, please upgrade your arpack lib. The mistery now is why previous versions of octave did work. Maybe octave should warn during installation if arpack < 3.3.0 is found.

Marco Caliari <caliari>
Group Member
Tue 21 Nov 2017 08:40:17 AM UTC, comment #13: 

Here the results for rvec true/false, that does have an impact:


rvec:  T
 Ritz values and relative residuals
 ----------------------------------
               Col   1       Col   2
  Row   1:    2.08101D+00   1.27846D-15
  Row   2:    2.08101D+00   8.84108D-16
  Row   3:    5.91899D+00   3.82569D-16
  Row   4:    5.91899D+00   2.57183D-16



rvec:  F
 Ritz values and relative residuals
 ----------------------------------
               Col   1       Col   2
  Row   1:    5.68251D+00   7.33653D-02
  Row   2:    5.68251D+00   3.56290D-01
  Row   3:    5.91899D+00   4.08130D-01
  Row   4:    5.91899D+00   4.13451D-01


A.R. Burgers <arb>
Tue 21 Nov 2017 07:26:08 AM UTC, comment #12: 

@arb: can you please set rvec = .false. in the fortran file and rerun it?

Marco Caliari <caliari>
Group Member
Mon 20 Nov 2017 07:42:15 PM UTC, comment #11: 

@Marco: Perhaps no surprise since I have arpack-3.3.0, but running the Fortran program produced:


 Ritz values and relative residuals
 ----------------------------------
               Col   1       Col   2
  Row   1:    2.08101D+00   1.22973D-15
  Row   2:    2.08101D+00   8.72666D-16
  Row   3:    5.91899D+00   3.52910D-16
  Row   4:    5.91899D+00   2.00270D-16


  _SDRV1
  ======

  Size of the matrix is           20
  The number of Ritz values requested is            4
  The number of Arnoldi vectors generated (NCV) is           20
  What portion of the spectrum: BE
  The number of converged Ritz values is            4
  The number of Implicit Arnoldi update iterations taken is            1
  The number of OP*x is           20
  The convergence criterion is    1.1102230246251565E-016


@A.R.: Really no idea why the dev version of Octave should be failing.  Can you try upgrading libarpack?


Rik <rik5>
Group administrator
Mon 20 Nov 2017 12:16:37 PM UTC, comment #10: 

This is the output I get:


 Ritz values and relative residuals
 ----------------------------------
               Col   1       Col   2
  Row   1:    2.08101D+00   1.27846D-15
  Row   2:    2.08101D+00   8.84108D-16
  Row   3:    5.91899D+00   3.82569D-16
  Row   4:    5.91899D+00   2.57183D-16

  _SDRV1
  ======
  Size of the matrix is           20
  The number of Ritz values requested is            4
  The number of Arnoldi vectors generated (NCV) is           20
  What portion of the spectrum: BE
  The number of converged Ritz values is            4
  The number of Implicit Arnoldi update iterations taken is            1
  The number of OP*x is           20
  The convergence criterion is    1.1102230246251565E-016


A.R. Burgers <arb>
Mon 20 Nov 2017 11:30:01 AM UTC, comment #9: 

This is very strange. Can you please try the attached fortran file? It reproduces the example. In order to compile and run it, I do


gfortran dsdrv1.f -lblas -llapack -larpack
./a.out


I get the eigenvalues 2.0810 with both arpack 3.3.0 and 3.0.

(file #42443)

Marco Caliari <caliari>
Group Member
Mon 20 Nov 2017 10:02:22 AM UTC, comment #8: 

Setting:


opts.v0 = ones(20,1)


gives


d1 =
   5.6825
   5.6825
   5.9190
   5.9190


with octave-4.2.1 I obtain:


d1 =
   2.0810
   2.0810
   5.9190
   5.9190


A.R. Burgers <arb>
Mon 20 Nov 2017 07:25:42 AM UTC, comment #7: 

@A.R. Burgers: first, I strongly suggest you to upgrade to arpack 3.3.0, at least. Before 3.2.0 arpack can compute wrong eigenvectors. Second, can you find an explicit initial vector for eigs for which the first two values of


n = 20;
A = sparse ([3:n,1:n,1:(n-2)],[1:(n-2),1:n,3:n],...
[ones(1,n-2),4*ones(1,n),ones(1,n-2)]);
k = 4;
opts.v0 = something 20x1
d1 = eigs (A, k, "be", opts)


are 5.6825? This would make the example exactly reproducible.

Marco Caliari <caliari>
Group Member
Sun 19 Nov 2017 06:34:52 PM UTC, comment #6: 

Adding Marco Caliari to the CC list.  It appears that this cset


changeset:   24228:1310d8b50ec2
user:        Marco Caliari <marco.caliari@univr.it>
date:        Fri Mar 24 14:41:08 2017 +0100
summary:     Fix eigs returning an incorrect number or order of eigenvalues (bug #45153, bug #47236).


which fixed other bugs in eigs, may have introduced one as well.

All of this works for me, but my arpack version is 3.3.0 while the reporter's is 3.0.1.  That may also be critical.

Rik <rik5>
Group administrator
Sun 19 Nov 2017 10:16:29 AM UTC, comment #5: 

These are my lib versions:


rpm -qa | grep arpack
arpack-3.0.1-1.el6.x86_64
arpack-devel-3.0.1-1.el6.x86_64

rpm -qa | grep lapack
lapack-3.2.1-5.el6.x86_64
lapack-devel-3.2.1-5.el6.x86_64

rpm -qa | grep blas
blas-3.2.1-5.el6.x86_64
blas-devel-3.2.1-5.el6.x86_64


A.R. Burgers <arb>
Sun 19 Nov 2017 10:08:15 AM UTC, comment #4: 

It goes wrong for me in r24228, r24227 is still OK


24227
version = 4.3.0+
hg_hd = 0da1bdfbfacb+
PASSES 162 out of 162 tests

24228
version = 4.3.0+
hg_hd = 1310d8b50ec2+
***** testif HAVE_ARPACK
 d1 = eigs (A, k, "be");
 assert (d1, d2([1:floor(k/2), (end - ceil(k/2) + 1):end]), 1e-11);
!!!!! test failed
ASSERT errors for:  assert (d1,d2 ([1:floor(k / 2), (end - ceil(k / 2) + 1):end]),1e-11)

  Location  |  Observed  |  Expected  |  Reason
    (1)         5.6825       2.081       Abs err 3.6015 exceeds tol 1e-11 by 4
    (2)         5.6825       2.081       Abs err 3.6015 exceeds tol 1e-11 by 4


A.R. Burgers <arb>
Fri 17 Nov 2017 07:14:58 PM UTC, comment #3: 

Works for me.  This is with hg id 24266:c372b091f622.

The changes below were checked in Nov. 11th and corrected some longstanding problems with eigs.  You might want to see if the tests started to fail after one of these particular changesets.


changeset:   24231:6bd7d2eb6434
user:        Marco Caliari <marco.caliari@univr.it>
date:        Thu Apr 06 13:30:47 2017 +0200
summary:     Display the right number/order of Ritz estimates in eigs when OPTS.disp = 2.

changeset:   24230:0350da83c049
user:        Marco Caliari <marco.caliari@univr.it>
date:        Mon Apr 03 11:17:07 2017 +0200
summary:     Use [L,U,P,Q,R] (sparse) and [L,U,P] (full) factorizations in eigs-base.cc.

changeset:   24229:97e628756971
user:        Rik <rik@octave.org>
date:        Mon Nov 13 20:48:06 2017 -0800
summary:     Adjust coding code in cset 1310d8b50ec2 for Octave coding conventions.

changeset:   24228:1310d8b50ec2
user:        Marco Caliari <marco.caliari@univr.it>
date:        Fri Mar 24 14:41:08 2017 +0100
summary:     Fix eigs returning an incorrect number or order of eigenvalues (bug #45153, bug #47236).



Rik <rik5>
Group administrator
Fri 17 Nov 2017 05:23:50 PM UTC, comment #2: 

No I did not change the blas/lapack/arpack libraries. test eigs still passes in octave-4.2.1 with the same set of blas/lapack/arpack .so.

For dev the eigs test did still pass when I reported the colormap FAIL in https://savannah.gnu.org/bugs/?52358

A.R. Burgers <arb>
Fri 17 Nov 2017 01:40:58 PM UTC, comment #1: 

Works for me:

c372b091f622+ tip @

test eigs verbose
...
** testif HAVE_ARPACK
 d1 = eigs (A, k, "be");
 assert (d1, d2([1:floor(k/2), (end - ceil(k/2) + 1):end]), 1e-11);
...
PASSES 167 out of 167 tests
Also buildbots seem to be happy:

http://buildbot.octave.org:8010/waterfall

Did you update blas/lapack/arpack recently?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Fri 17 Nov 2017 08:19:28 AM UTC, original submission:  

calling test eigs results in 4 FAIL's since recently:


version = 4.3.0+
hg_id = c372b091f622+

***** testif HAVE_ARPACK
 d1 = eigs (A, k, "be");
 assert (d1, d2([1:floor(k/2), (end - ceil(k/2) + 1):end]), 1e-11);
!!!!! test failed
ASSERT errors for:  assert (d1,d2 ([1:floor(k / 2), (end - ceil(k / 2) + 1):end]),1e-11)

  Location  |  Observed  |  Expected  |  Reason
    (1)         5.6825       2.081       Abs err 3.6015 exceeds tol 1e-11 by 4
    (2)         5.6825       2.081       Abs err 3.6015 exceeds tol 1e-11 by 4


A.R. Burgers <arb>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #42524:  integer8.diff added by rik5 (758B - text/x-patch)
file #42507:  52425.diff added by rik5 (621B - text/x-patch)
file #42454:  bug52425.diff added by rik5 (4KiB - text/x-patch)
file #42453:  bug_52425.f added by caliari (12KiB - text/x-fortran)
file #42443:  dsdrv1.f added by caliari (13KiB - text/x-fortran)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by siko1056 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by caliari (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by arb (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-11-29 rik5 Attached File- Added integer8.diff, #42524
    2017-11-28 rik5 Attached File- Added 52425.diff, #42507
    2017-11-22 rik5 StatusWorks For Me Fixed
        Open/ClosedOpen Closed
    2017-11-21 rik5 Attached File- Added bug52425.diff, #42454
        Carbon-Copy- Added jwe
    2017-11-21 caliari Attached File- Added bug_52425.f, #42453
    2017-11-20 caliari Attached File- Added dsdrv1.f, #42443
    2017-11-19 rik5 Carbon-Copy- Added caliari
    2017-11-17 rik5 StatusNone Works For Me

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code