[Paraview] CoProcessing needed fields
Andy Bauer
andy.bauer at kitware.com
Tue Nov 13 12:28:09 EST 2012
Hi Tim,
Sorry for the slow reply. I'm away at a conference.
It shouldn't matter how the data object was created in the adaptor.
For the life of me, I can't figure out why you're getting this behavior.
You can probably just take out the IsFieldNeeded() check in
coprocessingwrap.cxx. You should be making sure that if flag is set to 0 in
your checktime_() method that the grid and fields aren't reconstructed
anyways and you can skip the call to coprocess_().
Andy
On Fri, Nov 9, 2012 at 3:45 PM, Tim Gallagher <tim.gallagher at gatech.edu>wrote:
> Andy,
>
> Attached are the outputs. wavelet.tar.gz is from your script,
> cpModif.tar.gz are the images from my modified version and cpOrig.tar.gz is
> the output from the original script exported from PV.
>
> Clearly the wavelet works. Does it have something to do with using a VTK
> generator (pvsimple.Wavelet()) vs generating a CP script from a loaded data
> file?
>
> In other words, this wavelet example and the example online use a VTK data
> generator so the pipeline knows what fields are generated and thus what are
> needed. But, in my case, I set up my CP script by loading an Xdmf file.
> There must be some magic that goes on inside the XdmfReader that sets the
> fields available, just like the wavelet generator does? And since CP isn't
> using the Xdmf reader but I am building the VTK dataset myself, I need to
> do the same field-setting magic?
>
> If that's the case, then it should be true for a CP script generated from
> *any* data file reader. I know when I open my data file I get to choose
> which fields to load. Maybe this should be added to the export state script
> (which is what I did by hand) automatically? Like it is in the python trace
> file?
>
> Tim
>
> ------------------------------
> *From: *"Andy Bauer" <andy.bauer at kitware.com>
> *To: *"tim gallagher" <tim.gallagher at gatech.edu>
> *Cc: *"ParaView list" <paraview at paraview.org>
> *Sent: *Friday, November 9, 2012 4:21:48 PM
>
> *Subject: *Re: [Paraview] CoProcessing needed fields
>
> I can't tell for sure but what are you using as inputName in
> ParaViewCoProcessor.cxx? It should be 'input'. Also, how many time steps
> have you run? It should output information only every 10th time step.
>
> Can you try running the attached files as "<exe path>/pvbatch
> waveletdriver.py cpwaveletrender.py 5" and send me the output? This should
> generate 5 images. You should probably update your paraview source too
> before doing this as a couple of bugs got fixed that may be required to run
> this example.
>
> Andy
>
> On Thu, Nov 8, 2012 at 8:02 PM, Tim Gallagher <tim.gallagher at gatech.edu>wrote:
>
>> That was also a bug that resulted in errors I fixed, it wasn't what is
>> causing this other issue.
>>
>> Attached is a tar file with a few files:
>>
>> cpScript_orig.py is what comes out of Python, but after I changed the
>> write_frequencies thing to get rid of the quotes. That generates an image
>> where the slice is gray.
>>
>> cpScript.py is the one I modified to add the needed fields. This
>> generates an image where the slice is colored by the colormap. This is the
>> PNG file in the tar file.
>>
>> coprocessingwrap.cxx is the interface for Fortran.
>>
>> ParaviewCoProcessor.hxx/cxx is the class to handle the CP handles.
>>
>> This is called from a Fortran code where each time step it calls a
>> function that does:
>>
>> CALL ClearData(...)
>> CALL CheckTime(...)
>>
>> DO blk = 1, numBlocks
>> <set a bunch of pointers to Fortran data arrays>
>> CALL AddData(...)
>> END DO
>>
>> CALL CoProcess(...)
>>
>> All those functions are in the wrapper C++ code.
>>
>> I may be doing something horribly wrong... But it works when I modified
>> the script as you see in cpScript.py.
>>
>> Thanks,
>>
>> Tim
>>
>> ------------------------------
>> *From: *"Andy Bauer" <andy.bauer at kitware.com>
>> *To: *"tim gallagher" <tim.gallagher at gatech.edu>
>> *Cc: *"ParaView list" <paraview at paraview.org>
>> *Sent: *Thursday, November 8, 2012 7:47:50 PM
>>
>> *Subject: *Re: [Paraview] CoProcessing needed fields
>>
>> Ah, I think I see what's going on now. I think it was a bug in the
>> generated scripts that was causing problems. Were you getting something
>> like the following in your script:
>> write_frequencies = {'input': ['1']}
>>
>> The bug was that the 1 shouldn't be in quotes. If you take that out do
>> you start getting the results you expect? If not, can you share your
>> generated Python script?
>>
>> Andy
>>
>>
>> On Thu, Nov 8, 2012 at 6:41 PM, Tim Gallagher <tim.gallagher at gatech.edu>wrote:
>>
>>> Andy,
>>>
>>> Thanks for the answer.
>>>
>>> What I'm doing doesn't use any writers -- I just want the CoProcessor to
>>> output images only. So I don't attach a writer, I just export the state and
>>> tell it to "Output Rendering Components". My pipeline looks like:
>>>
>>> Load file -> CellDataToPointData -> Slice
>>>
>>> This results in a RequestDataDescription:
>>>
>>> def RequestDataDescription(datadescription):
>>> "Callback to populate the request for current timestep"
>>> if datadescription.GetForceOutput() == True:
>>> for i in range(datadescription.GetNumberOfInputDescriptions()):
>>> datadescription.GetInputDescription(i).AllFieldsOn()
>>> datadescription.GetInputDescription(i).GenerateMeshOn()
>>> return
>>>
>>> for input_name in simulation_input_map.values():
>>> LoadRequestedData(datadescription, input_name)
>>>
>>> This means in my case, there are no fields defined inside the
>>> datadescription. So when I try to do the IsFieldNeeded() call in my
>>> adaptor, it's always false. If I print the number of fields from
>>> GetNumberOfFields(), I get 0.
>>>
>>> So my images when they pop out have no data -- the fields don't exist
>>> for them to plot. It's just the slice using the default color for the
>>> surface.
>>>
>>> I got it to work by making a new variable just under
>>> simulation_input_map:
>>>
>>> simulation_cell_fields_needed = {simulation_input_map['rest_00000.xmf']:
>>> ["Temperature [K]", "Density [kg/m^3]"]}
>>> simulation_point_fields_needed =
>>> {simulation_input_map['rest_00000.xmf']: []}
>>>
>>> and putting in RequestDataDescription before the loop that calls
>>> LoadRequestedData:
>>>
>>> for input_name in simulation_input_map.values():
>>> idd = datadescription.GetInputDescriptionByName(input_name)
>>> for cell_fields in simulation_cell_fields_needed[input_name]:
>>> idd.AddCellField(cell_fields)
>>> for point_fields in simulation_point_fields_needed[input_name]:
>>> idd.AddPointField(point_fields)
>>>
>>> When I do that, it all works.
>>>
>>> Now, I guess my question is this... Where in the exported state script
>>> does it say what fields there are in the data? If I do a trace, when I load
>>> a file, I get something like:
>>>
>>> REST_00207_xmf.CellArrays = ['APD_mass_fraction', 'APD_reaction_rate',
>>> 'AP_mass_fraction', 'AP_reaction_rate', 'BND_mass_fraction', 'BND\
>>> _reaction_rate', 'Density [kg/m^3]', 'HybridSwitch', 'N2_mass_fraction',
>>> 'PRD_mass_fraction', 'PRD_reaction_rate', 'Pressure [Pa]', 'Subgrid\
>>> kinetic energy [m^2/s^2]', 'Temperature [K]', 'Velocity [m/s]',
>>> 'iblanks']
>>>
>>> and I expected something similar in the exported state script. But I
>>> don't see anything like that.
>>>
>>> Following the Fortran API, I call the ClearFieldDataFromGrid which may
>>> get rid of the fields that Paraview told it the pipeline needs.
>>>
>>> I could be misunderstanding something, I've never used VTK before this
>>> little project attempt. I can certainly send my adaptor code and python
>>> script if it helps clarify.
>>>
>>> Thanks again,
>>>
>>> Tim
>>>
>>> ------------------------------
>>> *From: *"Andy Bauer" <andy.bauer at kitware.com>
>>> *To: *"tim gallagher" <tim.gallagher at gatech.edu>
>>> *Cc: *"ParaView list" <paraview at paraview.org>
>>> *Sent: *Thursday, November 8, 2012 6:20:01 PM
>>> *Subject: *Re: [Paraview] CoProcessing needed fields
>>>
>>>
>>> Hi Tim,
>>>
>>> This should get set in the RequestDataDescription method in the
>>> generated Python script. When I first did it I thought we'd easily be able
>>> to figure out which fields were needed in order to update all of the
>>> required pipelines and/or views. Unfortunately this isn't trivial in VTK so
>>> basically what happens is that if a writer or view should output it
>>> specifies that all fields should be made available. This is the
>>> "datadescription.GetInputDescription(i).AllFieldsOn()" part of the
>>> generated python script.
>>>
>>> Answering your final question, this is something that is done
>>> automatically in the generated script.
>>>
>>> Andy
>>>
>>> On Wed, Nov 7, 2012 at 2:57 PM, Tim Gallagher <tim.gallagher at gatech.edu>wrote:
>>>
>>>> Hi,
>>>>
>>>> I see in the example code for
>>>> ParaView/CoProcessing/Adaptors/FortranAdaptors/PhastaAdaptor/PhastaAdaptor.cxx
>>>> calls like:
>>>>
>>>> vtkCPInputDataDescription* idd =
>>>>
>>>> ParaViewCoProcessing::GetCoProcessorData()->GetInputDescriptionByName("input");
>>>>
>>>> ...
>>>>
>>>> if(idd->IsFieldNeeded("velocity"))
>>>> {
>>>> ...
>>>>
>>>> The only way IsFieldNeeded returns true is if that name field was added
>>>> with AddCellField or AddPointField.
>>>>
>>>> Where does that happen? My intuition says that the python or C++
>>>> processing script (generated by exporting state) would have those calls in
>>>> it for the datasets that are actually used. In other words, if I set up my
>>>> view in the GUI and I load my data and put a Slice through it and color by
>>>> "Velocity", I expected the script from Export State to contain a call to
>>>> AddCellField("Velocity"). At the very least I expected to see calls to add
>>>> the fields I chose to load when I loaded my sample file to set up the view.
>>>>
>>>> So is that something that I need to put in the script on my own after
>>>> it's exported or did I miss something? If I have to put it there myself, is
>>>> RequestDataDescription the correct place to put that?
>>>>
>>>> Thanks,
>>>>
>>>> Tim
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>>
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Please keep messages on-topic and check the ParaView Wiki at:
>>>> http://paraview.org/Wiki/ParaView
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://www.paraview.org/mailman/listinfo/paraview
>>>>
>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20121113/c58c69c3/attachment-0001.htm>
More information about the ParaView
mailing list