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.gallag...@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.ba...@kitware.com> > *To: *"tim gallagher" <tim.gallag...@gatech.edu> > *Cc: *"ParaView list" <paraview@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.gallag...@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.ba...@kitware.com> >> *To: *"tim gallagher" <tim.gallag...@gatech.edu> >> *Cc: *"ParaView list" <paraview@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.gallag...@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.ba...@kitware.com> >>> *To: *"tim gallagher" <tim.gallag...@gatech.edu> >>> *Cc: *"ParaView list" <paraview@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.gallag...@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 >>>> >>> >>> >>> >> >> > >
_______________________________________________ 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