ProgressHandler -Exodus Reader is broken
This issue was created automatically from an original Mantis Issue. Further discussion may take place here.
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(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.