Re: [petsc-dev] test harness with alternative output files
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
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
> 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
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
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
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