VisIt 3.0Beta To Do

High level tasks

  • Directory Reorder - Mark
    • Status: Complete
  • Purchase GitHub LFS support - Eric
    • Status: In Progress
      • I requested to purchase 1 year of 4 data packs per month submitted. I was told this is cloud storage so IT needs to get involved.
      • Gary Schmerer gave the ok for us purchasing the LFS support.
  • Move VisIt Repo to GitHub - Cyrus
    • Status: In Progress
      • Waiting on directory reorder. (Cyrus needs to filter out some large files still)
      • We probably need some documentation on how to work in this new world.
      • Address any issues with build_visit
  • Move issue tracker to GitHub - Alister
    • Status: In Progress
      • Had discussion Tuesday 11/27 to reach final consensus on what the labels would be.
  • Produce a Linux distribution - Eric
    • Status: In progress
      • Updated the open build and install scripts for building 3.0b on quartz. Went ahead and built and installed it on quartz. It appears to work fine.
      • Still need to do other systems: rz, closed, local open and closed.
  • Produce a Windows distribution - Kathleen
    • Status: In progress
      • Kathleen created a version of 3.0b and Eric tested it on his PC. It worked ok except for creating a cinema database. The script for writing cinema databases was missing.
  • Produce a Mac OSX distribution - Kevin
    • Status:

Discussion items

  • Discus how we want to handle all our docs. We currently have the user manual directly under docs. We need to add Python cli manual. We also need to discuss if the docs get generated from the docs strings or vice versa. We also need to decide when to switch if changing. I also want to move the tutorials to sphinx as well.

High priority VisIt functionality to complete

  • Fix hardware volume rendering issue - Alister
    • Status: In Progress
      • Alister has a fix and needs to check it in.
  • Check out status of OSPRay rendering and make sure test suite passes with OSPRay support. The functionality doesn't all have to work, but easy bugs should be fixed. - Eric
    • Status: In Progress
      • The volume renderer looks like it is in pretty solid shape. I'm not sure what all the nobs do, so it would be nice to figure that out and document it, I found some information on the OSPRay website. The volume renderer appears to resample the data to a regular grid. I'm not sure where that is happening and there doesn't appear to be any way to control it. Right now it is fairly coarse, so making that finer and allowing control would be good.
      • The surface rendering has issues. When you build with OSPRay enabled it effects the rendering even when OSPRay is turned off. I found the two culprits and I'm working on a fix.
  • Check out status of Cinema support -
    • Status: Need to assign to someone
      • Eric was able to create a Cinema database so it must work at a basic level. The Cinema tests are commented out of the test suite, so there must be some issue.
      • Kathleen investigated a bit. The cinema failures occur with Specification 'C' and 'Create composite images' set to true.
      • More information from Kathleen.

The code that is no longer called in VisWinRendering.C relied on special rendering in vtkVisItDataSetMapper.C (and possibly subclasses, or painters), which no longer exists for trunk, due to vtk-8 changes in rendering. I did at one point try to look at the old vtkVisItDataSetMapper code, to see how to make it work with vtk8.

Would probably need to check out trunk at a version just prior to my vtk-8 merge in order to see the files in question. VTK8-port was SVN revision 32871 on April 3, 2018.

  • Find solution to remote GL to Windows -
    • Status: Delayed
      • Investigating how VNC works.
  • Convert VisIt Python CLI to Sphinx - Alister
    • Status: In Progress
      • There is an initial conversion. There was discussion of having Sphinx be the master of the documentation and having the Python docs strings derive from it, rather than the Sphinx documentation deriving from the Python doc strings. Not sure where that is, what the effort involved is and if we want to do that for 3.0 beta.
      • The rationale for this is that writing documentation in the Python doc string style is not natural or ease whereas writing documentation in rst is and we already do it elsewhere in the project. So, IMHO (In Mark's Humble Opinion), the correct action to take here is...
        • Convert all the .C doc-string content to rst content. We have some tools to make this easy. If nothing else, Mark can write Perl script
        • Write a tool that produces doc-string content from rst content so help in Python continues to behave as normal
        • Make the conversion and forevermore work in rst format
  • Fix windows distribution - Kathleen
    • Status: In Progress
      • Viewer currently crashes on startup for installed version on test machine (windows 10). Works fine from development build.
      • 12-10-18, This is only occuring on a VM running windows 10. Other machines I've tested don't have this problem. (stand alone win7 and win10).