more quick tests

[davydden]

I think we could expand the set of quick tests a bit, at least add a small problem for trilinos (PR incoming) and something with opencascade (step-54?). Also maybe something with metis (stripped-down step-18?). Something else?

UPDATE:

here are the current library-features and the quick test status:

• DEAL_II_WITH_ADOLC
• DEAL_II_WITH_ASSIMP
• DEAL_II_WITH_ARPACK
• DEAL_II_WITH_BOOST
• DEAL_II_WITH_CUDA
• DEAL_II_WITH_GMSH
• DEAL_II_WITH_GSL
• DEAL_II_WITH_HDF5
• DEAL_II_WITH_LAPACK
• DEAL_II_WITH_METIS
• DEAL_II_WITH_MPI
• DEAL_II_WITH_MUPARSER
• DEAL_II_WITH_NANOFLANN
  - [ ] DEAL_II_WITH_NETCDF
• DEAL_II_WITH_OPENCASCADE
• DEAL_II_WITH_P4EST
• DEAL_II_WITH_PETSC
• DEAL_II_WITH_SLEPC
• DEAL_II_WITH_SUNDIALS
• DEAL_II_WITH_THREADS
• DEAL_II_WITH_TRILINOS
• DEAL_II_WITH_UMFPACK
• DEAL_II_WITH_ZLIB

[davydden]

maybe arpack/parpack.

Not sure where and how NETCDF and HDF5 are used...

[drwells]

I think that this is reasonable (namely one quick test per feature).

[tamiko]

While we're at it - what are your opinions on putting all quick tests into one big executable?

Because quicktests are meant to ensure basic functionality (and do not have to test our API compatibility...) losing the compile and link stages of a test doesn't matter. Further, we do not run into this annoying scalability issue that adding another quick test adds another 8-10 seconds of linking.

(And we could in fact test ~30 - 100 basic properties within 30 seconds).

[davydden]

what are your opinions on putting all quick tests into one big executable

i would keep it separate for things like petsc-trilinos-slepc just to ease the maintenance. One could group a few small tests into a single executable though.

[davydden]

I think that this is reasonable (namely one quick test per feature).

yes, exactly my point.

[davydden]

what are your opinions on putting all quick tests into one big executable

probably it is also move important/convenient for a user to see exactly which feature failed the test (mpi, p4est, petsc,...).

[tjhei]

what are your opinions on putting all quick tests into one big executable

probably it is also move important/convenient for a user to see exactly which feature failed the test

Agreed, I think it is crucial to see what failed and why. Although, most failures are probably due to linker errors of incomplete detected features so they would come up for every single test anyways.

We also need to keep the parallel test separate.

[tamiko]

probably it is also move important/convenient for a user to see exactly which feature failed the test

It would still be one test run per feature. Just one common executable to reduce total link time to a fraction.

Although, most failures are probably due to linker errors of incomplete detected features

With an incomplete link interface we would very likely not be able to link any given executable.
So we already have that issue.

Further, my bet is that we already hit almost all compilation issues while we compile the library - after all we compile and instantiate the majority of our code base.

[tjhei]

With an incomplete link interface we would very likely not be able to link any given executable.
So we already have that issue.

Yes, that was my point: it is fine to have a single executable if we are mainly concerned about link failure.

[tamiko]

Yes, that was my point: it is fine to have a single executable if we are mainly concerned about link failure.

Ah, sorry. I need a few extra courses in reading comprehension...

[davydden]

I move the list of features and their quick-test status to OP, there is not much left now. Opencascade would probably be the next most important feature to have a quick test for, but I have no experience with it.

[davydden]

@jppelteret @luca-heltai since you recently added adolc, sundials and nanoflan as external interfaces, could you please add one quick tests for each in make tests?

[jppelteret]

Will do.

…

On 19 Aug 2017, at 16:00, Denis Davydov ***@***.***> wrote: @jppelteret <https://github.com/jppelteret> @luca-heltai <https://github.com/luca-heltai> since you recently added adolc, sundials and nanoflan as external interfaces, could you please add one quick tests for each in make tests? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3230 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ-dwlJRMI90fSYHEAYuaoy2sSiR5_83ks5sZup2gaJpZM4KVQLZ>.

[luca-heltai]

#4852 Adds also a quick test for sundials.

[masterleinad]

I guess we are already testing for BOOST during configuration extensively.

[davydden]

I guess we are already testing for BOOST during configuration extensively.

yeah, i guess that's ok. It's just we don't have any quick tests for make test after installation.

[masterleinad]

No high priority. Postponing.

[kronbichler]

There has been no activity for the past 5 years. We moved a lot of infrastructure to the CI, so I think we can close this issue now. If we feel, we can always add additional quick tests.