Albany TODOs

This page itemizes the current Albany TODOs, based largely on the moderated discussion session at the 2017 Albany User Meeting. This list will likely be moved to the Albany github page at a later date.

##Project Management

• Come up with systematic way to "tax" current Albany projects to cover Dan Ibanez' time as Albany "shepherd".
• Move Albany to a different space on github than gahansen, after figuring out logistics for how to do this.
• Invite relevant POCs to weekly Monday concall. Designate secretary to take meeting notes/post on wiki?
• Create Teams and Projects within the Repository to help organize work efforts within Albany.

##Code Maintenance/Documentation

• Give Dan Ibanez access to machines where current CDash testing happens.
• Clean up the Dashboards. Currently most dashboards have some long-standing failures, which undermines the whole purpose of such Dashboards. Many easy fixes are available.
• Create "master" CDash tests with everything possible enabled.
• Prune build options; document what compilers are/are not supported for Albany.
• Put in place develop/master branch workflow - creates incentives for developers to fix broken tests (e.g., cannot push to master until failing tests are fixed).
• Create separate issue for longer tests?
• Use github issues for bug fixes, feature requests, other communication, etc.
• Remove Albany sub-projects identified as being discontinued, starting with those which have the most impact on core Albany infrastructure. Currently those include:
  • Aeras
  • Epetra-based Embedded UQ systems (?)
  • Stochastic Galerkin systems
  • Hydride
  • CTM
• Fix the deprecation warnings on most evaluators caused by non-constant dependent field types

##Tpetra/Thyra Porting

• Convert the following physics/capabilities in Albany to Tpetra/Thyra:
  • ATO (in progress by Irina Tezaur)
    • 1/28/17 status: code is converted to Tpetra/Thyra and tests pass, except those involving distributed responses. Could use help debugging.
  • QCAD (conversion needs to be completed)
  • MOR
  • Embedded UQ? Porting of embedded ensembles in in progress by Jeff Fike
  • Complete Tpetra transition for PDE-constrained optimization
  • Distributed parameters - convert to Tpetra and clean up ifdef guards. It is unclear right now if distributed parameters work correctly in no-Epetra build.
• Remove Epetra from Albany? Prerequisites include:
  • Certain physics/capabilities are still based on Epetra. Those will have to be converted.
  • Tpetra linear solvers not as performant as Epetra ones (affects FELIX in particular). Trilinos is moving forward with Tpetra, so we need to put pressure on Tpetra Trilinos developers to improve performance. Collecting Epetra benchmarks prior to conversion will be useful.
  • Ensure Trilinos can be built Epetra-free. Work by @gahansen to be continued by @ibaned.

##Kokkos Porting

• Complete porting of finite element assembly to Kokkos
  • Replace std::vector with Kokkos::vector so tests run with CUDA.
  • Increase default workset size, at least when CUDA is on, so tests run faster and do not time out.
• Try linear solve in Albany on next-gen architectures (e.g., GPUs) - should be possible using simple preconditioners (POC: Siva Rajamanickam).
• Optimize code to obtain good performance on GPUs, Intel Xeon Phis, etc.
  • Document "recipe" for porting code to Kokkos for non-experts to refer to.
• Remove non-Kokkos code for physics that has been ported to Kokkos? - hold off on this until we have one physics working well with Kokkos on all platforms.
• Do something about Epetra tests with CUDA - turn off or put Kokkos_initialize/finalize in Main_Solve.cpp? Are these tests meant to run on GPU?

##Generalization of physics-specific capabilities to all Albany projects

• Ensure that boundary conditions and certain material properties can be specified in the input file as analytic mathematical formulas (spatially-varying).
• Generalize the top-level Albany design to allow multiple Problems (Schwarz coupling)
• Allow the use of Physics-based block preconditioning (some of this seems to have been started).
• Spectral elements?

##Adaptivity/SCOREC/PUMI

• Create CUBIT workflow for adaptivity
• Get distributed paramters to work with PUMI discretization method?
• Convert LCM tests to work with PUMI/SCOREC?
• Create a GitHub wiki page describing how to compile with PUMI and Omega_h.
• Move towards running Albany STK-free. The following features need to be added to the PUMI Discretization:
  • Ability to read Exodus files
  • provide DistParams functionality
• Continue development and V&V efforts of LCM with adaptivity
  • Compare with/without RCU
  • V&V for the stabilized mixed pressure formulation
  • V&V for an adaptive simulation
  • Explore other element formulations if above runs into trouble
• Implement a general size field framework