Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
ParaView
ParaView
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,660
    • Issues 1,660
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 61
    • Merge Requests 61
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar

Updates will be applied April 15th at 12pm EDT (UTC-0400). GitLab could be a little slow between 12 - 12:45pm EDT.

  • ParaView
  • ParaViewParaView
  • Issues
  • #13831

Closed
Open
Created Jan 28, 2013 by Kitware Robot@kwrobotOwner

Master bug - Progress Handler is a mess

This issue was created automatically from an original Mantis Issue. Further discussion may take place here.


This is a master bug that I will hang sub bugs off of. Basically, the current Progress Handler is a mess. This bug relates to file vtkPVProgressHandler.cxx, plus imbedded code in all of the filters that calls it. I am seeing the following:

  • No parameter checking for bad input variables. (progress should generally be 0.0 to 1.0 within the code)
  • No print statements in the Progress Handler that can be turned on that shows that progress actually increments.
  • Intermixing progress of a range of 0.0 to 1.0 and 0.0 to 100.0 within the same object/functions. This is undocumented, and very confusing.
  • Progress coming into the Progress Handler from filters (expected progress of 0.0-1.0) with a range up to 10's or 100's (1000% to 10000% done).
  • Some conditions (such as a status of 0.0, or any number out of the 0-1 range) that is flooding MPI with messages.
  • Some filters, such as the CTH reader, that runs absolutely crazy progress. For instance, with the CTH reader, status is 0.0 to 0.2, then backs up and runs 0.04 to 0.38, then 0.64 to 1.0.
  • Running multiple server sometimes provides crazy results (see ranges outside of 0.0-1.0 above).

That's probably a good start. I will post additional bug reports with specifics.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None