Scott,
Thanks. Might be enough as is.
Satish,
Could you see if this support is enough to fix he pesky example in master
nightly that produces two different possible output.
Barry
> On Oct 26, 2017, at 10:48 PM, Scott Kruger wrote:
>
>
>
> On 10/25/17 10:04 AM, Smith, Bar
On 10/25/17 10:04 AM, Smith, Barry F. wrote:
Scott,
It looks like you started to put in support for the test harness to
compare output against multiple files.
$ git grep altfile
config/gmakegentest.py:if len(altlist)>1: subst['altfiles']=altlist
config/gmakegentest.py: if
> El 26 oct 2017, a las 18:36, Franck Houssen
> escribió:
>
> Here is a stack I end up with when trying to solve an eigen problem (real,
> sym, generalized) with SLEPc. My understanding is that, during the Gram
> Schmidt orthogonalisation, the projection of one basis vector turns out to be
>
Just to let you know, that in https://github.com/opencollab/arpack-ng, I've
just committed support for:
1. iso_c_binding: this helps usability and portability (with c/c++ examples
in test suites).
2. finding package (cmake users): find_package works now.
This is only for arpack, not
Here is a stack I end up with when trying to solve an eigen problem (real, sym,
generalized) with SLEPc. My understanding is that, during the Gram Schmidt
orthogonalisation, the projection of one basis vector turns out to be null.
First, is this correct ? Second, in such cases, are there some re
Which compilers don't work?
"Smith, Barry F." writes:
>Jed,
>
> Unfortunately multiple fortran compilers we use do not support type(*) so
> we either configure check this stuff (annoying) or stop supporting lots of
> Fortran compilers.
>
>Satish,
>
>I guess you need to chec
