MantisBT - ParaView

View Issue Details

Project

Category

View Status

Date Submitted

Last Update

0013835

ParaView

(No Category)

public

2013-01-29 21:20

2016-08-12 09:59

Reporter

Alan Scott

Assigned To

Kitware Robot

Priority

normal

Severity

minor

Reproducibility

have not tried

Status

closed

Resolution

moved

Platform

OS Version

Product Version

git-master

Target Version

Fixed in Version

Project

Sandia

Topic Name

Type

incorrect functionality

Summary

0013835: ProgressHandler -Exodus Reader is broken

Description

I have been digging in the Progress Handler, with regards to the Exodus reader, and am totally over my head. There are numerous issues here, none of which I understand. Here are some of the symptoms.

To replicate, I am using Windows, Visual Studio, Master, local server. Run ParaView.
Place a breakpoint in file vtkPVProgressHandler.cxx, line:
this->Internals->ProgressStore.AddLocalProgress(id, text, progress);

Open z_pinch1.exo.8.[0-7]. (I turn all variables on, but not necessary.) Apply. Hit the Play button three times.

Notice what progress is (I believe it should be 0.125). You will want to notice what id is here.

Search for, and put a break at
this->SetLocalProgress(static_cast<int>(progress*100.0), text.c_str());

Hit the Play button.

Progress is 0.0. This is a bug. This is also at least one of the reasons that the Exodus reader never shows a status.

Where to look:
AddLocalProgress (listed above) has a call (Find) that tries to figure out which row of a table we want to use. For some crazy reason, there is a table here with two rows. It looks like this:
Some_number (2114 for me), text=vtkExodusFileSeriesReader
Another_number (2125 for me), text=vtkPExodusIIReader

My objectId coming in is 2125, the second line in the table. And as you would hope, I am being called by vtkPExodusIIReader::RequestData (up the stack a ways). We want, and do use the second row of the table.

Back to the last place we stopped on a breakpoint. GetProgress (the call one line up) never looks for the correct row of the table, but just uses the first one (which is of course not objectId 2125, and text vtkPExodusIIReader. This row holds old data, where we want the second row.

Sorry for such a confusing bug report, but I really don't understand what the writer was trying to do, thus can't debug the code. Comments would have helped.

Steps To Reproduce

Additional Information