Open rusu24edward opened 4 years ago
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.
Problematic VisIt areas:
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 atvtkDataSet
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).