Re: [petsc-dev] test harness with alternative output files

[Smith, Barry F.]

  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, 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 'altfiles' not in subst:
>> config/gmakegentest.py:for i in range(len(subst['altfiles'])):
>> config/gmakegentest.py:  af=subst['altfiles'][i]
>> config/gmakegentest.py:  if i!=len(subst['altfiles'])-1:
>> but that there is not yet support for this?
> 
> There is support but:
> 1. It requires the multiple files to be of the form ex*_[1-3]_alt.out
>   in the output directory
> 2. It is piping all of the diffs simultaneously to create a single
>   diff test rather than multple.
> 
> You can look at a $PETSC_ARCH/tests/src/sys/examples/tests/runex2.sh to see 
> how this works.
> 
> I assuming that you would rather:
> 1. Have an altfiles (or similar) keyword (*)
> 2. Have separate difftests for each.
> 
> Scott
> 
> (*) see documentation or the top of config/testparse.py for accepted keywords 
> currently
>> We have a bunch of tests that require this so we will need it in the test 
>> harness. How difficult do you think this would be to add?
>>Thanks
>>Barry
> 
> -- 
> Tech-X Corporation   kru...@txcorp.com
> 5621 Arapahoe Ave, Suite A   Phone: (720) 974-1841
> Boulder, CO 80303Fax:   (303) 448-7756

Re: [petsc-dev] test harness with alternative output files

[Scott Kruger]

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 'altfiles' not in subst:
config/gmakegentest.py:for i in range(len(subst['altfiles'])):
config/gmakegentest.py:  af=subst['altfiles'][i]
config/gmakegentest.py:  if i!=len(subst['altfiles'])-1:

but that there is not yet support for this?


There is support but:
1. It requires the multiple files to be of the form ex*_[1-3]_alt.out
   in the output directory
2. It is piping all of the diffs simultaneously to create a single
   diff test rather than multple.

You can look at a $PETSC_ARCH/tests/src/sys/examples/tests/runex2.sh to 
see how this works.


I assuming that you would rather:
1. Have an altfiles (or similar) keyword (*)
2. Have separate difftests for each.

Scott

(*) see documentation or the top of config/testparse.py for accepted 
keywords currently


We have a bunch of tests that require this so we will need it in the test 
harness. How difficult do you think this would be to add?

Thanks

Barry



--
Tech-X Corporation   kru...@txcorp.com
5621 Arapahoe Ave, Suite A   Phone: (720) 974-1841
Boulder, CO 80303Fax:   (303) 448-7756

Re: [petsc-dev] SLEPc failure

[Jose E. Roman]

> 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 
> null.
> First, is this correct ? Second, in such cases, are there some recommended 
> "recipe" to test/try (options) to get a clue on the problem ? (I would 
> unfortunately perfectly understand the answer could be no !... As this 
> totally depends on A/B).
> 
> With arpack, the eigen problem is solved (so the matrix A and B I use seems 
> to be relevant). But, when I change from arpack to krylovschur/ciss/arnoldi, 
> I get the stack below.
> 
> Franck
> 
> [0]PETSC ERROR: #1 BV_SafeSqrt() 
> [0]PETSC ERROR: #2 BVNorm_Private() 
> [0]PETSC ERROR: #3 BVNormColumn() 
> [0]PETSC ERROR: #4 BV_NormVecOrColumn() 
> [0]PETSC ERROR: #5 BVOrthogonalizeCGS1() 
> [0]PETSC ERROR: #6 BVOrthogonalizeGS() 
> [0]PETSC ERROR: #7 BVOrthonormalizeColumn()
> [0]PETSC ERROR: #8 EPSFullLanczos() 
> [0]PETSC ERROR: #9 EPSSolve_KrylovSchur_Symm() 
> [0]PETSC ERROR: #10 EPSSolve() 

Is this with SLEPc 3.8? In SLEPc 3.8 we relaxed this check so I would suggest 
trying with it.
Jose

[petsc-dev] arpack-ng

[Franck Houssen]

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 parpack (I didn't need parpack and had no extra 
time for that). 

Hope this may help !... 

Franck 

[petsc-dev] SLEPc failure

[Franck Houssen]

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 recommended 
"recipe" to test/try (options) to get a clue on the problem ? (I would 
unfortunately perfectly understand the answer could be no !... As this totally 
depends on A/B). 

With arpack, the eigen problem is solved (so the matrix A and B I use seems to 
be relevant). But, when I change from arpack to krylovschur/ciss/arnoldi, I get 
the stack below. 

Franck 

[0]PETSC ERROR: #1 BV_SafeSqrt() 
[0]PETSC ERROR: #2 BVNorm _Private() 
[0]PETSC ERROR: #3 BVNormColumn() 
[0]PETSC ERROR: #4 BV_NormVecOrColumn() 
[0]PETSC ERROR: #5 BVOrthogonalizeCGS1() 
[0]PETSC ERROR: #6 BVOrthogonalizeGS () 
[0]PETSC ERROR: #7 BVOrthonormalizeColumn() 
[0]PETSC ERROR: #8 EPSFullLanczos() 
[0]PETSC ERROR: #9 EPSSolve_KrylovSchur_Symm() 
[0]PETSC ERROR: #10 EPSSolve() 

Re: [petsc-dev] type(*) not supported by multiple test fortran compilers we use

[Jed Brown]

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 check all the failed Fortran compilers and see if 
> they have versions that work that uses can also access easily. For example 
> what if the absoft compiler product does not support it?
>
>
>Barry