Brainstorm meeting 11/05/19

[rusu24edward]

Problematic VisIt areas:

• Numerical expressions. Getting good analysis suite including analytic problems which we know correct answers via means other than through VisIt.
• Good test problems and datasets that include many interesting data features.
• Workflows that we can make rock solid / circumvent to make users lives a little easier.
• Scratchpad database to auto export/import to circumvent challenges with ugly workflow.
• Lots of optimization done to avoid querying metadata, but this complicates our lives a lot. Might be better to remove the optimization.
• Devilray: ray tracing infrastructure from Matt using RAJA and Umpire. GPUs work very well with simple data structures/design.
• How does complexity of VisIt code base feel? Often requires 1-2 weeks of reading through code before a certain part of the code (e.g. Expressions) is fully understood. Documenting that part of the code once understood would probably take another week.
• We need good developer docs and architecture/design diagrams.
• Tutorials and good docs between Sphinx and Wiki; these should be merged to one-stop-shopping
• Reducing barriers to entry for new users of VisIt with better documentation, tutorials, maybe animiated Gifs or YouTube videos -- how easily can that stuff fall out of date?
• How do we have more flexible user interfaces for complicated things?
• AVS Express?
• Fix the build script so that default works (e.g. include -ssl). How to extend the testing to catch these cases.
  • Currently, web site sends people to build_visit with no documentation for how to use and what to do if fail

Topology agnostic software engineering.

We kinda already do some of this with vtkDataSet genericity. But, we do have a lot of code that tests real type of dataset and specializes too. The question is; is this for performance reasons for features not available at vtkDataSet level reasons? If its because of performance, its hard to argue against it. Though, perhaps these performance questions should be re-visited more frequently in development cycle than current (which I think is never).

VTKm API strengths and weakensses

A lot of functionality to support templating, virtual functions, etc. Works great when a single data model is in use within a consumer (or producer) but in general vis. tool that needs to support all data models, there is added complexity in supporting all the data types, interface configurations, etc.

FFTs are a rabbit hole

For some reason we talked quite a bit about VisIt's FFT. It has a large number of limitations. We aren't even sure why we continue to maintain it. There is probably a lot of interest in doing something like a power spectrum plot/operator for tubulent flow (which perhaps can be postulated on both structured and unstructured grids).

[rusu24edward]

There is probably a lot of interest in doing something like a power spectrum plot/operator for tubulent flow

How do we gauge users' interests? Is it just by word of mouth as we interact with users who say, "You know, I would really like this feature"? Maybe we can formalize a way to document users' interest? I believe we have also talked about holding a users-developers meeting to discuss these points. I wonder if this would be a good way to prioritize some of these ideas and to introduce new ones.

There is probably a lot of interest in doing something like a power spectrum plot/operator for tubulent flow (which perhaps can be postulated on both structured and unstructured grids).

Created #4056 for this.

* Numerical expressions. Getting good analysis suite including _analytic_ problems which we know correct answers via means _other than_ through VisIt.

I've been currently working under the model that we can utilize some of the codes in WSC for validation as the "true" answer for expressions.

* Good test problems and datasets that include _many_ interesting data _features_.

A tiered testing approach might be useful here. Created #4057 for further discussion.

• How does complexity of VisIt code base feel? Often requires 1-2 weeks of reading through code before a certain part of the code (e.g. Expressions) is fully understood. Documenting that part of the code once understood would probably take another week.

• We need good developer docs and architecture/design diagrams.

• Tutorials and good docs between Sphinx and Wiki; these should be merged to one-stop-shopping

• Reducing barriers to entry for new users of VisIt with better documentation, tutorials, maybe animiated Gifs or YouTube videos -- how easily can that stuff fall out of date?

I think this is definitely worth the time and effort. I don't particularly like documentation, but I think developing the ability to explain how something works (both to users and developers) is very valuable. I vaguely remember going to a talk that discussed the potential for external funding specifically for documentation. That might be something that we can tap into.