Organize Packages Drop-down menu best understandability and usability

[maherou]

The Packages drop-down menu was recently re-organized to provide the reader with some guidance as to:

• The primary functionality of the package (only indicated in the MPI+X package list for now).
• The package execution model (MPI-only, MPI+X). Only those packages that are truly production quality.
• Indicate the present and future value of a package.

While the current names and groupings are an improvement of the previous single list of package names, there may be a better way to organize and classify the packages.

This issue is intended for capturing ideas and defining a how to improve the organization.

[bartlettroscoe]

@maherou, some feedback

I just noticed that the "Packages" drop-down at the top of:

• https://trilinos.github.io/

Now shows them partitioned into several different categories:

• MPI+X Packages
• MPI-Only Packages
• Research Packages
• Archive Packages

I am not sure who came up with the selection of packages in those lists but they are not consistent. Here are some examples of consistencies:

• Panzer is listed under "MPI+X Packages" build Phalanx is listed under "Research Packages". But Panzer has a required dependence on Phalanx so would Panzer not need to be listed as a "Research" package?
• Belos and Anasazi are listed under "MPI+X Packages" but Thyra, Stratimikos, NOX, LOCA, etc. are listed under "MPI-Only Packages". That makes zero sense. These are all just Abstract Numerical Algorithms (ANAs) that case use any underlying threaded or accelerated implementation. If Thyra is listed under "MPI-Only Packages" then Belos and Anasazi should be as well.
• ROL is listed under "MPI+X Packages" yet still can't fully run on a GPU. If Thyra is listed as "MPI-Only" then so should ROL.
• RTOp (not RTOP) is listed under "Archive Packages" but Thyra has a required dependence on RTOp so it can't be consider an archive package if Thyra is not considered an Archive package. Yet "TriUtils" is not listed under "Archive Packages". That is not consistent.
• Why is ForTrilinos even listed? It is not even in Trilinos. And how is that not a research package?

[jhux2]

A few comments:

1. In the drop down, I see this: "The MPI+X collection of packages is sometime referred to as the Tpetra stack." In fact, I always refer to the Epetra stack or the Tpetra stack, never MPI+X. How would a user approach this?

2. What are the definition of research packages? Stokhos and Teko are integral components of ATDM apps, so I would argue they could be production ....

I appreciate that you're trying to instill some order for someone new to Trilinos. I just suspect Trilinos might not be amenable to such simple categorizations.

[maherou]

@bartlettroscoe , @jhux2: Thanks for your comments.

While there are obvious mistakes with the initial placement of packages, what I am trying to accomplish is:

• Make it clear what functionality and what kind of platforms Trilinos supports.
• Use language that does not immediately require the website visitor to be an insider who knows what Epetra vs Tpetra stack means.
• Clearly distinguish between the software packages that are used in production, those that can be used in a non-production environment and still have someone on the development team who cares about the package, and packages that never met the threshold of broad usability and never will.

Once we determine a way to describe useful categories, we can work out the details of where a package belongs. I thought about our categories of production-growth, production-maintenance, etc., but these are also not as descriptive. If you have suggestions for categories and names, I would like to see them. Perhaps we could also consider non-exclusive categories (so some packages could appear in more than one category).

[bartlettroscoe]

@maherou, I am with @jhux2; Trilinos packages are going to be hard to classify in strict separate lists like this.

I think I see what you are trying to do with "Archive Packages". With the exception of RTOp, those are all packages that you can disable (or replace with some other Trilinos package like replacing Rythmos with Tempus) and you would not impact any current important customers of Trilinos.

The problem with this is that RTOp is a required dependency of Thyra. Until a refactoring is done to replace this with a more modern C++11/14 version based on Kokkos, it will still be getting used in production applications through Thyra. That is not true of any of the other packages listed under "Archive Packages".

Again, ForTrilinos is not strictly a Trilinos package because it is not in the Trilinos repo, but it is an add-on package (using the TriBITS add-on repo/package mechanism). But I see it is hosted under the github.com/trilinos/ organization. Therefore, would you not need to list every add-on package listed there including Sundance, CTrilinos, and xSDKTrilinos (the former two as "Archive Packages" and the last as "Research Packages")? What about other add-on packages like DataTransferKit? That is not maintained under the Trilinos organization. What is the criteria for what is considered a "Trilinos package" and what is not?

[jhux2]

Clearly distinguish between the software packages that are used in production, those that can be used in a non-production environment and still have someone on the development team who cares about the package, and packages that never met the threshold of broad usability and never will.

By "can be used in a non-production environment", does this mean packages that are not production ready but are still supported/developed?

If you have suggestions for categories and names, I would like to see them. Perhaps we could also consider non-exclusive categories (so some packages could appear in more than one category).

I like the idea of non-exclusive categories. Depending on what the categories are, a Venn diagram might be helpful.

[mperego]

@maherou, What if we only have two categories. The packages currently-developed/essential, and the "obsolete" packages (i.e. Epetra stack etc.). We could also color code the packages to indicate their level of maturity (I think @kddevin proposed this).

[maherou]

I think there is value to identifying packages like the core Epetra stack that are production quality vs those that never made it to broad use. We still hear of Trilinos users who want the parallel environment that the Epetra stack provides.

[jhux2]

I think there is value to identifying packages like the core Epetra stack that are production quality vs those that never made it to broad use. We still hear of Trilinos users who want the parallel environment that the Epetra stack provides.

I agree. But I think @mperego might be pointing out that the Epetra stack is no longer developed.

[maherou]

Agreed. However, I think we want at least three categories. I don't think we want to combine Epetra with packages like Optika, which never made it out of the gate.

[mperego]

That's fine. We could also decide to list in that drop-down menu only the "most relevant" packages, and have the others (e.g. optika, but possibly also shards,RTOp, that are mainly support packages) listed in the respective products pages. Just an idea.