Re: [Paraview] Input Editor - Cramped Input Port Selection
Oh isn't it already? Looks like there's a bug with multiple input connections. I'll fix it. On Fri, Mar 19, 2010 at 4:36 AM, Jérôme wrote: > Thanks Utkarsh > > I like it ! However - let me know if I am boring ;) -, for multiple inputs > on > one port (such as AppendGeometry), it would be nice if the current inputs > are already selected when choosing "Change Input" in the pipeline > browser. Lazy men (yes, I am) don't want to reselect them... > > Anyway, that's good ! > Jerome > > 2010/3/17 Utkarsh Ayachit >> >> Folks, >> >> I've committed some changes. A slight change from the mockup is the >> placement of the radio buttons, since the buttons on the top seemed >> disconnected from the pipeline view when more than 1 input ports were >> present. Also, if there's only 1 input port, the radio buttons are now >> hidden. >> >> >> Jeremy, >> >> I think I understood what you meant, and I've tried to address that >> issue as well. Feel free to give that a try. >> >> Utkarsh >> >> On Tue, Mar 16, 2010 at 12:08 PM, Jérôme wrote: >> > Then I was right : I was not clear enough! >> > >> > First, I talked about the current panel, not your mockup. I agree with >> > those who enthousiastic. >> > Second, the problem I noted on the multiple-input-port panel is that >> > the input are not ordered by index, but by name. Changing "Source" >> > to "ArbirtraySource" in the filters.xml for streamer with custom source >> > will change the order the inputs appear. Well, I know, if the name are >> > well-chosen, it is not a problem. >> > >> > Now, let's take this pipeline: >> > >> > builtin >> > | >> > |---Wavelet >> > | | >> > | Gradient >> > | >> > | --- PointSource >> > >> > If you want to initialize a stream tracer in the Gradient at each point >> > of PointSource, you have to select Gradient, then choose filter -> >> > Stream tracer with custom source. The inputs panel is shown, with >> > the Input field being already set to the selected 'Gradient'. What you >> > have to do is to set the Source to PointSource from the pipeline. >> > Well... >> > Attached is a screenshot of this procedure, but Source is named >> > ArbitrarySource. The Gradient is set as ArbitrarySource, and Input field >> > is not set. >> > >> > I hope I am clearer now! >> > >> > Jerome >> > >> > >> > >> > >> > 2010/3/16 Utkarsh Ayachit >> >> >> >> I am not sure why there's a problem. In your case, your filters have 2 >> >> input ports. e.g. in the stream tracer case, referring to the mockup, >> >> INPUT1 will be called "Input" while INPUT2 will be called >> >> "ArbitrarySource" or "Source" as the case may be. Both of which >> >> allowing the user to only add 1 item in the input box next to them. >> >> >> >> Utkarsh >> >> >> >> On Tue, Mar 16, 2010 at 4:23 AM, Jérôme wrote: >> >> > My 2 cents on this : >> >> > It seems to me that the input list is provided in alphabetical order. >> >> > In >> >> > my >> >> > case I have a lot of custom plugins that take 2 inputs, one being >> >> > vtkImageData >> >> > and the other a vtkPolyData (such a stream tracer with custom >> >> > source). >> >> > Depending on wich is the 'principal' input, the default input setting >> >> > of >> >> > this >> >> > panel have non-corresponding type. For instance, the Image input is >> >> > set >> >> > to an existing PointSet. >> >> > >> >> > I don't know if I am clear enough, but maybe you can try with the >> >> > stream >> >> > tracer >> >> > with custom source: in the current configuration, there is no >> >> > problem. >> >> > But I >> >> > am >> >> > quite sure that if you rename the 2nd input "Source" to >> >> > "ArbitrarySource" in >> >> > the >> >> > filters.xml, you will understand this tiny problem. >> >> > >> >> > Jerome >> >> > >> >> > 2010/3/16 Christian Werner >> >> >> >> >> >> I vote yes for the mockup! >> >> >> >> >> >> Utkarsh Ayachit wrote: >> >> >>> >> >> >>> I agree, the pipeline preview is confusing and for the most part >> >> >>> useless. Unless people object, I'd vote for removing it as well. >> >> >>> >> >> >>> Attached is a sample mockup. In case of filters like Append which >> >> >>> have >> >> >>> single input port, but multiple input connections, the use can type >> >> >>> in >> >> >>> a comma separated list of the inputs in the input field or select >> >> >>> multiple items using the pipeline browser in the dialog. >> >> >>> >> >> >>> Utkarsh >> >> >>> >> >> >>> On Mon, Mar 15, 2010 at 11:22 AM, Christian Werner >> >> >>> wrote: >> >> >>> >> >> >> >> As a user, may I present three suggestions, two of which should be >> >> very >> >> easy >> >> and still yield an improvement. >> >> >> >> 1) remove the Pipeline Preview: This may be rude because it's >> >> somehow >> >> nice. >> >> But then again, you cannot change what happens to the pipeline >> >> anyway. >> >> Also, >> >> I don't think one would change his mind about the selection of the >> >> inputs >> >>
Re: [Paraview] Plugin Installation Location
FYI, I've committed this change:
/cvsroot/ParaView3/ParaView3/CMake/ParaViewPlugins.cmake,v <--
CMake/ParaViewPlugins.cmake
new revision: 1.70; previous revision: 1.69
On Thu, Mar 18, 2010 at 2:41 PM, Mike Jackson
wrote:
> Cool thanks.
> _
> Mike Jackson mike.jack...@bluequartz.net
>
> On Thu, Mar 18, 2010 at 2:28 PM, Dave Partyka
> wrote:
>> Yeah, it should be fine to remove ${name}. In 3.6 it was done for
>> organizational purposes for the most part.
>>
>> On Thu, Mar 18, 2010 at 2:23 PM, Utkarsh Ayachit
>> wrote:
>>>
>>> Ah..yes...well it's not a bug per say. We did that in past to make it
>>> easier for people to locate plugins that are packaged with ParaView,
>>> but we don't need that anymore since distributed plugins are
>>> automatically listed by the plugin manager dialog. I think we should
>>> remove the ${name}. Dave, any concerns with doing so?
>>>
>>> Utkarsh
>>>
>>> On Thu, Mar 18, 2010 at 10:58 AM, Michael Jackson
>>> wrote:
>>> > I was running the "install" target from a Visual Studio instance and
>>> > noticed
>>> > that my custom client side plugins were NOT being loaded. When I looked
>>> > at
>>> > the install tree I noticed the following:
>>> >
>>> > ParaView/bin/plugins/AngReaderClientPlugin/AngReaderClientPlugin.dll
>>> > which
>>> > obviously is not correct. I think I have tracked it down to the
>>> > following
>>> > bit of CMake code in ParaView/CMake/ParaViewPlugins.cmake:
>>> >
>>> > MACRO(internal_paraview_install_plugin name)
>>> > IF (PV_INSTALL_LIB_DIR)
>>> > INSTALL(TARGETS ${name}
>>> > ==> DESTINATION "${PV_INSTALL_PLUGIN_DIR}/${name}"
>>> > COMPONENT Runtime)
>>> > ENDIF (PV_INSTALL_LIB_DIR)
>>> > ENDMACRO(internal_paraview_install_plugin)
>>> >
>>> > I think that should be DESTINATION "${PV_INSTALL_PLUGIN_DIR}/" instead.
>>> > Is
>>> > this a bug? Something similar to this error is also present in the
>>> > ParaView
>>> > 3.6.2 sources (where I originally found the issue).
>>> >
>>> > Thanks for any info/feedback.
>>> > ___
>>> > Mike Jackson www.bluequartz.net
>>> > Principal Software Engineer mike.jack...@bluequartz.net
>>> > BlueQuartz Software Dayton, Ohio
>>> >
>>> >
>>> > ___
>>> > 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
Re: [Paraview] Paraview: python script from the command line
No, you won't get the paraview gui with pvpython or vtkpython. On Fri, Mar 19, 2010 at 3:50 PM, Rick Angelini wrote: > Do I still get the GUI if I us pvpython or vtkpython? I'm looking to > jumpstart the Paraview GUI using a python script. > > Andy Bauer wrote: > >> You're probably looking for pypython but vtkpython may also work. >> >> >> On Fri, Mar 19, 2010 at 3:42 PM, Rick Angelini > blockedmailto:rick.angel...@us.army.mil>> >> wrote: >> >>Is there a way to startup paraview and have it run a python script >>from the command line? I know that I can load a state with the >>"--state" flag.And, I can run a python script from within >>ParaView by going to the python tool and running the script.As >> far as I can tell, I'm limited to running the python script >>after ParaView GUI starts up.It would be nice to be able to >>load that same script from the command line. >>___ >>Powered by www.kitware.com http://www.kitware.com> >> >> >>Visit other Kitware open-source projects at >>http://www.kitware.com/opensource/opensource.html >>http://www.kitware.com/opensource/opensource.html> >> >> >>Please keep messages on-topic and check the ParaView Wiki at: >>http://paraview.org/Wiki/ParaView >>http://paraview.org/Wiki/ParaView> >> >> >>Follow this link to subscribe/unsubscribe: >>http://www.paraview.org/mailman/listinfo/paraview >>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
Re: [Paraview] Paraview: python script from the command line
You're probably looking for pypython but vtkpython may also work. On Fri, Mar 19, 2010 at 3:42 PM, Rick Angelini wrote: > Is there a way to startup paraview and have it run a python script from the > command line? I know that I can load a state with the "--state" flag. > And, I can run a python script from within ParaView by going to the python > tool and running the script. As far as I can tell, I'm limited to > running the python script after ParaView GUI starts up.It would be nice > to be able to load that same script from the command line. > ___ > 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
Re: [Paraview] Dashdoard Breakage
I'll fix it. I missed a few places with yesterday's fixes. Thanks, Clint On Friday 19 March 2010 08:55:35 am Utkarsh Ayachit wrote: > Clint, > > Can you take a look at this please? It may have been a side effect of > your commit on March 17. > http://cmake.org/gitweb?p=cmake.git;a=commit;h=108090fde96916ba666f035d1e26 > 0f036af5b31e > > Utkarsh > > On Fri, Mar 19, 2010 at 10:33 AM, Kevin H. Hobbs wrote: > > Since March 17 all of my dashboard submissions that use CTest from CVS > > show many build errors. > > > > The submissions that use CTest 2.6 are relatively fine. > > > > These are my submissions : > > > > http://www.cdash.org/CDash/index.php?project=ParaView3&filtercount=2&show > >filters=1&filtercombine=or&field1=site/string&compare1=63&value1=hooperlab > >&field2=site/string&compare2=63&value2=hobbs-hancock > > > > > > ___ > > 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
Re: [Paraview] Paraview: python script from the command line
Do I still get the GUI if I us pvpython or vtkpython? I'm looking to jumpstart the Paraview GUI using a python script. Andy Bauer wrote: You're probably looking for pypython but vtkpython may also work. On Fri, Mar 19, 2010 at 3:42 PM, Rick Angelini mailto:rick.angel...@us.army.mil>> wrote: Is there a way to startup paraview and have it run a python script from the command line? I know that I can load a state with the "--state" flag.And, I can run a python script from within ParaView by going to the python tool and running the script. As far as I can tell, I'm limited to running the python script after ParaView GUI starts up.It would be nice to be able to load that same script from the command line. ___ Powered by www.kitware.com http://www.kitware.com> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html http://www.kitware.com/opensource/opensource.html> Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView http://paraview.org/Wiki/ParaView> Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview 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
Re: [Paraview] Paraview: python script from the command line
That's a reasonable request. We don't have such an option currently. Let me see if I can add it before 3.8. Utkarsh On Fri, Mar 19, 2010 at 3:42 PM, Rick Angelini wrote: > Is there a way to startup paraview and have it run a python script from the > command line? I know that I can load a state with the "--state" flag. > And, I can run a python script from within ParaView by going to the python > tool and running the script. As far as I can tell, I'm limited to > running the python script after ParaView GUI starts up. It would be nice > to be able to load that same script from the command line. > ___ > 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
[Paraview] Paraview: python script from the command line
Is there a way to startup paraview and have it run a python script from the command line? I know that I can load a state with the "--state" flag.And, I can run a python script from within ParaView by going to the python tool and running the script. As far as I can tell, I'm limited to running the python script after ParaView GUI starts up.It would be nice to be able to load that same script from the command line. ___ 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
Re: [Paraview] Paraview 3.6.x connection definition files
Great - thank you. Utkarsh Ayachit wrote: Rick, I've committed a fix for this. Feel free to give it a try. Utkarsh On Fri, Mar 19, 2010 at 11:57 AM, Utkarsh Ayachit wrote: Ah...interesting thought. I'll take a look. On Fri, Mar 19, 2010 at 11:41 AM, Rick Angelini wrote: I've run into a situation where things are not yet being handled correctly with this issue. I'm currently testing with 3.7.x assuming that's the where the work is going on for the next release. The original issue can be found here: http://www.paraview.org/Bug/view.php?id=9866#c18827 As stated in the issue resolution, the saved values are now being stored in the users .ini file, but they are not unique for each server. That is, it appears to be creating "global variables" rather than saving off variables per server. So, I have something that looks like this in my .ini file: [SERVER_STARUP] SSHLOC=/usr/local/bin/ssh LOGINNODE=login-node1 USERNAME=user PROJECTNUM=ABC123Project PV_CONNECT_ID=13829 NODES=2 QUEUE=debug SERVER_PORT=55876 WALLTIME=60 VERSION=3.7.0 If I now load up a different server which happens to use the same variable names, these automatically get dumped into the connection definition file, which is OK assuming that you have the same USERNAME, PROJECTNUM, etc across all systems, which is not the case.So, I have multiple connection definition files pointing to multiple machines with different usernames and ProjectIDs, and by default I'm getting the values from the previous session rather than the values from the previous session for that particular server. I'm wondering if the best way to save these variables is something more like this: hostname1.USERNAME=jimuser hostname1.PROJECTNUM=ABC123Project hostname2.USERNAME=joeuser hostname2.PROJECTNUM=XYZ789Project Where "hostname" is the Server name from the .pvsc file. Utkarsh Ayachit wrote: I've ensured that when "random" is specified as the default value for any option, which is the case with --connect-id, then the value is always regenerated, so this will be a non-issue. Also you can always add save="false" attribute, if needed -- but not necessary in this case. Utkarsh On Mon, Jan 11, 2010 at 8:38 PM, Scott, W Alan wrote: Am I missing something, or would we also save the --connect-id flag between sessions? This needs to be new, and random, each and every time we run. This was the reason that the save option was put into Paraview - so we wouldn't save the --connect-id variable. Alan -Original Message- From: Moreland, Kenneth Sent: Monday, January 11, 2010 1:52 PM To: Scott, W Alan; Utkarsh Ayachit Cc: Rick Angelini; ParaView Subject: Re: [Paraview] Paraview 3.6.x connection definition files Utkarsh, Is there a reason why we should not save all options as opposed to just those with the "save" attribute? I cannot think of a good use case to not save an option, and even if there is a good use case wouldn't it be rare enough to justify saving by default and having an attribute to turn off saving? Furthermore, until you made that change the behavior has been to save all of the options, and to my knowledge no one has complained about that. -Ken On 1/11/10 12:11 PM, "Scott, W Alan" wrote: Thanks, you're the greatest! I think that the save attribute is necessary, since we need to --connect-id flag to not be saved between sessions - and to truly be random. This is mandatory for some of our systems. Alan -Original Message- From: Utkarsh Ayachit [mailto:utkarsh.ayac...@kitware.com] Sent: Monday, January 11, 2010 12:05 PM To: Moreland, Kenneth Cc: Rick Angelini; Scott, W Alan; ParaView Subject: Re: [Paraview] Paraview 3.6.x connection definition files Folks, I've committed a fix for this. The updating of the user's servers.pvsc file was totally unnecessary (there was code elsewhere that handled BUG #5487). However the user selections for only those elements that have the "save" attribute set to true are preserved across sessions. Refer to http://www.paraview.org/Wiki/ParaView:Server_Configuration#Cas e_Eight:_Starting_server_using_ssh for details on the "save" attribute. I am wondering if that's even needed and we can always save all options i.e. assume "save" is true by default. What do you think? Utkarsh On Mon, Nov 9, 2009 at 10:45 AM, Moreland, Kenneth wrote: I've submitted a bug on this issue: http://www.paraview.org/Bug/view.php?id=9866 Please take a look at it and see if it and the suggested solution addresses the problem. -Ken On 11/5/09 12:25 PM, "Rick Angelini" wrote: Alan - I think that you do want to allow the user to create their own connection definitions files, so you need to maintain the functionality of item #2 & item #4. Maybe there's a
Re: [Paraview] Paraview 3.6.x connection definition files
Rick, I've committed a fix for this. Feel free to give it a try. Utkarsh On Fri, Mar 19, 2010 at 11:57 AM, Utkarsh Ayachit wrote: > Ah...interesting thought. I'll take a look. > > On Fri, Mar 19, 2010 at 11:41 AM, Rick Angelini > wrote: >> I've run into a situation where things are not yet being handled correctly >> with this issue. I'm currently testing with 3.7.x assuming that's the >> where the work is going on for the next release. The original issue can be >> found here: >> >> http://www.paraview.org/Bug/view.php?id=9866#c18827 >> >> >> As stated in the issue resolution, the saved values are now being stored in >> the users .ini file, but they are not unique for each server. That is, >> it appears to be creating "global variables" rather than saving off >> variables per server. So, I have something that looks like this in my >> .ini file: >> >> [SERVER_STARUP] >> SSHLOC=/usr/local/bin/ssh >> LOGINNODE=login-node1 >> USERNAME=user >> PROJECTNUM=ABC123Project >> PV_CONNECT_ID=13829 >> NODES=2 >> QUEUE=debug >> SERVER_PORT=55876 >> WALLTIME=60 >> VERSION=3.7.0 >> >> If I now load up a different server which happens to use the same variable >> names, these automatically get dumped into the connection definition file, >> which is OK assuming that you have the same USERNAME, PROJECTNUM, etc across >> all systems, which is not the case. So, I have multiple connection >> definition files pointing to multiple machines with different usernames and >> ProjectIDs, and by default I'm getting the values from the previous session >> rather than the values from the previous session for that particular server. >> I'm wondering if the best way to save these variables is something more >> like this: >> >> hostname1.USERNAME=jimuser >> hostname1.PROJECTNUM=ABC123Project >> hostname2.USERNAME=joeuser >> hostname2.PROJECTNUM=XYZ789Project >> >> Where "hostname" is the Server name from the .pvsc file. >> >> >> Utkarsh Ayachit wrote: >>> >>> I've ensured that when "random" is specified as the default value for >>> any option, which is the case with --connect-id, then the value is >>> always regenerated, so this will be a non-issue. Also you can always >>> add save="false" attribute, if needed -- but not necessary in this >>> case. >>> >>> Utkarsh >>> >>> On Mon, Jan 11, 2010 at 8:38 PM, Scott, W Alan wrote: >>> > Am I missing something, or would we also save the --connect-id flag >>> > between sessions? This needs to be new, and random, each and every time >>> > we >>> > run. >>> > >>> > This was the reason that the save option was put into Paraview - so we >>> > wouldn't save the --connect-id variable. >>> > >>> > Alan >>> > >>> >> -Original Message- >>> >> From: Moreland, Kenneth >>> >> Sent: Monday, January 11, 2010 1:52 PM >>> >> To: Scott, W Alan; Utkarsh Ayachit >>> >> Cc: Rick Angelini; ParaView >>> >> Subject: Re: [Paraview] Paraview 3.6.x connection definition files >>> >> >>> >> Utkarsh, >>> >> >>> >> Is there a reason why we should not save all options as >>> >> opposed to just those with the "save" attribute? I cannot >>> >> think of a good use case to not save an option, and even if >>> >> there is a good use case wouldn't it be rare enough to >>> >> justify saving by default and having an attribute to turn off >>> >> saving? Furthermore, until you made that change the behavior >>> >> has been to save all of the options, and to my knowledge no >>> >> one has complained about that. >>> >> >>> >> -Ken >>> >> >>> >> >>> >> On 1/11/10 12:11 PM, "Scott, W Alan" wrote: >>> >> >>> >> > Thanks, you're the greatest! >>> >> > >>> >> > I think that the save attribute is necessary, since we need to >>> >> > --connect-id flag to not be saved between sessions - and to >>> >> truly be >>> >> > random. This is mandatory for some of our systems. >>> >> > >>> >> > Alan >>> >> > >>> >> >> -Original Message- >>> >> >> From: Utkarsh Ayachit [mailto:utkarsh.ayac...@kitware.com] >>> >> >> Sent: Monday, January 11, 2010 12:05 PM >>> >> >> To: Moreland, Kenneth >>> >> >> Cc: Rick Angelini; Scott, W Alan; ParaView >>> >> >> Subject: Re: [Paraview] Paraview 3.6.x connection definition files >>> >> >> >>> >> >> Folks, >>> >> >> >>> >> >> I've committed a fix for this. The updating of the user's >>> >> >> servers.pvsc file was totally unnecessary (there was code >>> >> elsewhere >>> >> >> that handled BUG #5487). However the user selections for >>> >> only those >>> >> >> elements that have the "save" attribute set to true are >>> >> >> preserved across sessions. >>> >> >> >>> >> >> Refer to >>> >> >> http://www.paraview.org/Wiki/ParaView:Server_Configuration#Cas >>> >> >> e_Eight:_Starting_server_using_ssh >>> >> >> >>> >> >> for details on the "save" attribute. I am wondering if that's even >>> >> >> needed and we can always save all options i.e. assume >>> >> "save" is true >>> >> >> by default. What do you think? >>> >> >> >>> >> >> Utkarsh >>> >> >> >>> >> >> On Mon, Nov 9, 2009 at 10:4
[Paraview] Parameter Studies / Comparative Visualization
Folks, ParaView introduced Comparative Views for parameter studies a while ago. They have undergone some usability cleanups for the upcoming 3.8 release. Feel free to give them a try. Additional information on the Wiki: http://www.paraview.org/Wiki/Parameter_Study#Creating_Parameter_Studies Utkarsh ___ 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
Re: [Paraview] Lighting adjustments not available
How ironic. I wrote a filter to create really pretty colors and now I have to throw those away in order to get a nice "shiny" surface. I will just assume that this is area that needs some more work? -- Mike Jackson On Mar 19, 2010, at 2:50 PM, Utkarsh Ayachit wrote: Just choose to color by "Solid Color" and those options should be enabled. Utkarsh On Fri, Mar 19, 2010 at 2:48 PM, Michael Jackson wrote: Um.. So how do I get the adjustments back? Do I need a certain type of Array data or to remove a certain type of array data? -- Mike Jackson On Mar 19, 2010, at 2:46 PM, Utkarsh Ayachit wrote: The specular options are disabled when coloring with an array by design to avoid any interference with the scalar colors which can result in misinterpretation of the data. Utkarsh On Fri, Mar 19, 2010 at 2:32 PM, Eric E. Monson wrote: Hey Mike, For me, though, even the Sphere Source doesn't have those options if I'm coloring by a scalar or vector -- only if I've chosen "Solid Color". I don't know if this is how it's supposed to be or not. -Eric -- Eric E Monson Duke Visualization Technology Group On Mar 19, 2010, at 2:09 PM, Michael Jackson wrote: I have a polygonal mesh that I am rendering. I would like to adjust the specular intensity and focus of the rendered mesh BUT that section of the "Display" tab is disabled. If I create a simple Sphere source then the section is enabled. I tried generating point normals for my mesh but that did not seem to help. I am sure it is something simple. This is with OS X 10.5.8/ Qt 4.6.2 Cocoa/ intel/ with PV CVS Head. ___ Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio ___ 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
Re: [Paraview] Lighting adjustments not available
Just choose to color by "Solid Color" and those options should be enabled. Utkarsh On Fri, Mar 19, 2010 at 2:48 PM, Michael Jackson wrote: > Um.. So how do I get the adjustments back? Do I need a certain type of Array > data or to remove a certain type of array data? > -- > Mike Jackson > > On Mar 19, 2010, at 2:46 PM, Utkarsh Ayachit wrote: > >> The specular options are disabled when coloring with an array by >> design to avoid any interference with the scalar colors which can >> result in misinterpretation of the data. >> >> Utkarsh >> >> On Fri, Mar 19, 2010 at 2:32 PM, Eric E. Monson >> wrote: >>> >>> Hey Mike, >>> >>> For me, though, even the Sphere Source doesn't have those options if I'm >>> coloring by a scalar or vector -- only if I've chosen "Solid Color". I don't >>> know if this is how it's supposed to be or not. >>> >>> -Eric >>> >>> -- >>> Eric E Monson >>> Duke Visualization Technology Group >>> >>> >>> On Mar 19, 2010, at 2:09 PM, Michael Jackson wrote: >>> I have a polygonal mesh that I am rendering. I would like to adjust the specular intensity and focus of the rendered mesh BUT that section of the "Display" tab is disabled. If I create a simple Sphere source then the section is enabled. I tried generating point normals for my mesh but that did not seem to help. I am sure it is something simple. This is with OS X 10.5.8/ Qt 4.6.2 Cocoa/ intel/ with PV CVS Head. ___ Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio > > ___ 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
Re: [Paraview] Lighting adjustments not available
Um.. So how do I get the adjustments back? Do I need a certain type of Array data or to remove a certain type of array data? -- Mike Jackson On Mar 19, 2010, at 2:46 PM, Utkarsh Ayachit wrote: The specular options are disabled when coloring with an array by design to avoid any interference with the scalar colors which can result in misinterpretation of the data. Utkarsh On Fri, Mar 19, 2010 at 2:32 PM, Eric E. Monson wrote: Hey Mike, For me, though, even the Sphere Source doesn't have those options if I'm coloring by a scalar or vector -- only if I've chosen "Solid Color". I don't know if this is how it's supposed to be or not. -Eric -- Eric E Monson Duke Visualization Technology Group On Mar 19, 2010, at 2:09 PM, Michael Jackson wrote: I have a polygonal mesh that I am rendering. I would like to adjust the specular intensity and focus of the rendered mesh BUT that section of the "Display" tab is disabled. If I create a simple Sphere source then the section is enabled. I tried generating point normals for my mesh but that did not seem to help. I am sure it is something simple. This is with OS X 10.5.8/ Qt 4.6.2 Cocoa/ intel/ with PV CVS Head. ___ Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio ___ 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
Re: [Paraview] Lighting adjustments not available
The specular options are disabled when coloring with an array by design to avoid any interference with the scalar colors which can result in misinterpretation of the data. Utkarsh On Fri, Mar 19, 2010 at 2:32 PM, Eric E. Monson wrote: > Hey Mike, > > For me, though, even the Sphere Source doesn't have those options if I'm > coloring by a scalar or vector -- only if I've chosen "Solid Color". I don't > know if this is how it's supposed to be or not. > > -Eric > > -- > Eric E Monson > Duke Visualization Technology Group > > > On Mar 19, 2010, at 2:09 PM, Michael Jackson wrote: > >> I have a polygonal mesh that I am rendering. I would like to adjust the >> specular intensity and focus of the rendered mesh BUT that section of the >> "Display" tab is disabled. If I create a simple Sphere source then the >> section is enabled. I tried generating point normals for my mesh but that >> did not seem to help. I am sure it is something simple. This is with OS X >> 10.5.8/ Qt 4.6.2 Cocoa/ intel/ with PV CVS Head. >> >> ___ >> Mike Jackson www.bluequartz.net >> Principal Software Engineer mike.jack...@bluequartz.net >> BlueQuartz Software Dayton, Ohio >> >> >> ___ >> 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 > ___ 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
Re: [Paraview] Debug Qt Libraries NOT being installed on MSVC Builds
Here is what I came up with:
# Function to install qt libraries. qtliblist is a list of libraries
to install
# of the form "QTCORE QTGUI QTNETWORK QTXML QTTEST QTSQL" etc.
FUNCTION(install_qt_libs qtliblist componentname)
IF (NOT APPLE)
FOREACH(qtlib ${qtliblist})
IF (NOT WIN32)
IF (QT_${qtlib}_LIBRARY_RELEASE)
GET_FILENAME_COMPONENT(QT_LIB_DIR_tmp ${QT_$
{qtlib}_LIBRARY_RELEASE} PATH)
GET_FILENAME_COMPONENT(QT_LIB_NAME_tmp ${QT_$
{qtlib}_LIBRARY_RELEASE} NAME)
FILE(GLOB QT_LIB_LIST RELATIVE "${QT_LIB_DIR_tmp}" "${QT_$
{qtlib}_LIBRARY_RELEASE}*")
INSTALL(CODE "
MESSAGE(STATUS \"Installing \${CMAKE_INSTALL_PREFIX}/$
{PV_INSTALL_LIB_DIR}/${QT_LIB_NAME_tmp}\")
EXECUTE_PROCESS (WORKING_DIRECTORY ${QT_LIB_DIR_tmp}
COMMAND tar c ${QT_LIB_LIST}
COMMAND tar -xC \${CMAKE_INSTALL_PREFIX}/$
{PV_INSTALL_LIB_DIR})
" COMPONENT ${componentname})
ENDIF (QT_${qtlib}_LIBRARY_RELEASE)
ELSE (NOT WIN32)
#GET_FILENAME_COMPONENT(QT_DLL_PATH_tmp ${QT_QMAKE_EXECUTABLE}
PATH)
# INSTALL(FILES ${QT_DLL_PATH_tmp}/${qtlib}4.dll
# DESTINATION ${PV_INSTALL_BIN_DIR}
# COMPONENT ${componentname})
set (BUILD_TYPES "Debug;Release" )
foreach (btype ${BUILD_TYPES})
string(TOUPPER ${btype} BTYPE)
file(MAKE_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/$
{btype})
string(TOUPPER ${qtlib} QTLIB)
if (NOT ${QT_${QTLIB}_LIBRARY_${BTYPE}} STREQUAL QT_$
{QTLIB}_LIBRARY_${BTYPE}-NOTFOUND)
GET_FILENAME_COMPONENT(DLL_NAME ${QT_${QTLIB}_LIBRARY_
${BTYPE}} NAME_WE)
GET_FILENAME_COMPONENT(QT_BIN_PATH $
{QT_QMAKE_EXECUTABLE} PATH)
#message(STATUS "**Generating Install Rule for $
{btype} Version of ${DLL_NAME} DLL")
INSTALL(FILES ${QT_BIN_PATH}/${DLL_NAME}.dll
DESTINATION ${PV_INSTALL_BIN_DIR}
CONFIGURATIONS ${btype}
COMPONENT ${componentname} )
# this code is here to copy the qt libraries into the
actual build folder
# on windows in case the qt/bin directory is NOT on
the users PATH anywhere
# which can happen if there are multiple Qt versions
installed or multiple
# arch types (32 or 64 bit) installed. This is turned
OFF for now but I
# usually enable this.
if (0)
add_custom_target(Z_${qtlib}-${BTYPE}-Copy ALL
COMMAND ${CMAKE_COMMAND} -E
copy_if_different ${QT_BIN_PATH}/${DLL_NAME}.dll
${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/${btype}/
COMMENT "Copying ${QT_BIN_PATH}/$
{DLL_NAME}.dll to ${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/${btype}/")
endif()
endif()
endforeach( btype ${BUILD_TYPES} )
ENDIF (NOT WIN32)
ENDFOREACH(qtlib)
ENDIF (NOT APPLE)
ENDFUNCTION(install_qt_libs)
And you call it like this: From ${ParaView_SOURCE}/Applications/
ParaView/CMakeLists.txt
SET (qtliblist QtCore QtGui QtNetwork QtXml QtSql QtHelp QtWebKit
QtCLucene Phonon QtXmlPatterns)
That seems to work fine for both Debug and Release modes. This was
tested on Windows 7 x64 running Visual Studio 2008 RTM and CMake 2.6.4
Hope it helps. I git cloned to "git clone git://
echo1.bluequartz.net/ParaView.git" and have my changes there.
___
Mike Jackson www.bluequartz.net
On Mar 18, 2010, at 3:06 PM, Dave Partyka wrote:
Its at the bottom of ParaView\CMake\ParaViewBrandingCPack.cmake.
On Thu, Mar 18, 2010 at 3:01 PM, Michael Jackson > wrote:
Ok. I'm trying to peruse through the ParaView CMake files but am not
really coming up where those install rules are set? Care to give a
hint. I may have a patch for you...
__
Mike Jackson www.bluequartz.net
On Mar 18, 2010, at 2:52 PM, Dave Partyka wrote:
It's a bug, the install rule doesn't respect configuration type.
On Thu, Mar 18, 2010 at 2:46 PM, Mike Jackson > wrote:
This is with ParaView CVS HEAD and VS 2008 running on Windows 7. When
I build a "Debug" version then run the "INSTALL" project in the
Paraview.sln file I get the NON-Debug versions of the Qt libraries. I
have to go back and manually copy the libraries from the Qt
Installation location into the "bin" directory of the installation. Is
this intended behavior or a bug? I have a possible patch if needed
that would help clear this up.
_
Mike Jackson mike.jack...@bluequartz.net
BlueQuartz Softwarewww.bluequartz.net
Principal Software Engineer Day
Re: [Paraview] Lighting adjustments not available
Hey Mike, For me, though, even the Sphere Source doesn't have those options if I'm coloring by a scalar or vector -- only if I've chosen "Solid Color". I don't know if this is how it's supposed to be or not. -Eric -- Eric E Monson Duke Visualization Technology Group On Mar 19, 2010, at 2:09 PM, Michael Jackson wrote: > I have a polygonal mesh that I am rendering. I would like to adjust the > specular intensity and focus of the rendered mesh BUT that section of the > "Display" tab is disabled. If I create a simple Sphere source then the > section is enabled. I tried generating point normals for my mesh but that did > not seem to help. I am sure it is something simple. This is with OS X 10.5.8/ > Qt 4.6.2 Cocoa/ intel/ with PV CVS Head. > > ___ > Mike Jackson www.bluequartz.net > Principal Software Engineer mike.jack...@bluequartz.net > BlueQuartz Software Dayton, Ohio > > > ___ > 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
[Paraview] Lighting adjustments not available
I have a polygonal mesh that I am rendering. I would like to adjust the specular intensity and focus of the rendered mesh BUT that section of the "Display" tab is disabled. If I create a simple Sphere source then the section is enabled. I tried generating point normals for my mesh but that did not seem to help. I am sure it is something simple. This is with OS X 10.5.8/ Qt 4.6.2 Cocoa/ intel/ with PV CVS Head. ___ Mike Jackson www.bluequartz.net Principal Software Engineer mike.jack...@bluequartz.net BlueQuartz Software Dayton, Ohio ___ 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
Re: [Paraview] Dashdoard Breakage
On Friday 19 March 2010 10:37:33 am Kevin H. Hobbs wrote: > On 03/19/2010 12:05 PM, Clinton Stimpson wrote: > > I'll fix it. I missed a few places with yesterday's fixes. > > > > Thanks, > > Clint > > If you send me a note when you're done, then I'll happily submit a test > build. > Its fixed now. Thanks, Clint ___ 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
Re: [Paraview] Dashdoard Breakage
On 03/19/2010 12:05 PM, Clinton Stimpson wrote: > > I'll fix it. I missed a few places with yesterday's fixes. > > Thanks, > Clint > If you send me a note when you're done, then I'll happily submit a test build. signature.asc Description: OpenPGP digital signature ___ 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
Re: [Paraview] Paraview 3.6.x connection definition files
Ah...interesting thought. I'll take a look. On Fri, Mar 19, 2010 at 11:41 AM, Rick Angelini wrote: > I've run into a situation where things are not yet being handled correctly > with this issue. I'm currently testing with 3.7.x assuming that's the > where the work is going on for the next release. The original issue can be > found here: > > http://www.paraview.org/Bug/view.php?id=9866#c18827 > > > As stated in the issue resolution, the saved values are now being stored in > the users .ini file, but they are not unique for each server. That is, > it appears to be creating "global variables" rather than saving off > variables per server. So, I have something that looks like this in my > .ini file: > > [SERVER_STARUP] > SSHLOC=/usr/local/bin/ssh > LOGINNODE=login-node1 > USERNAME=user > PROJECTNUM=ABC123Project > PV_CONNECT_ID=13829 > NODES=2 > QUEUE=debug > SERVER_PORT=55876 > WALLTIME=60 > VERSION=3.7.0 > > If I now load up a different server which happens to use the same variable > names, these automatically get dumped into the connection definition file, > which is OK assuming that you have the same USERNAME, PROJECTNUM, etc across > all systems, which is not the case. So, I have multiple connection > definition files pointing to multiple machines with different usernames and > ProjectIDs, and by default I'm getting the values from the previous session > rather than the values from the previous session for that particular server. > I'm wondering if the best way to save these variables is something more > like this: > > hostname1.USERNAME=jimuser > hostname1.PROJECTNUM=ABC123Project > hostname2.USERNAME=joeuser > hostname2.PROJECTNUM=XYZ789Project > > Where "hostname" is the Server name from the .pvsc file. > > > Utkarsh Ayachit wrote: >> >> I've ensured that when "random" is specified as the default value for >> any option, which is the case with --connect-id, then the value is >> always regenerated, so this will be a non-issue. Also you can always >> add save="false" attribute, if needed -- but not necessary in this >> case. >> >> Utkarsh >> >> On Mon, Jan 11, 2010 at 8:38 PM, Scott, W Alan wrote: >> > Am I missing something, or would we also save the --connect-id flag >> > between sessions? This needs to be new, and random, each and every time we >> > run. >> > >> > This was the reason that the save option was put into Paraview - so we >> > wouldn't save the --connect-id variable. >> > >> > Alan >> > >> >> -Original Message- >> >> From: Moreland, Kenneth >> >> Sent: Monday, January 11, 2010 1:52 PM >> >> To: Scott, W Alan; Utkarsh Ayachit >> >> Cc: Rick Angelini; ParaView >> >> Subject: Re: [Paraview] Paraview 3.6.x connection definition files >> >> >> >> Utkarsh, >> >> >> >> Is there a reason why we should not save all options as >> >> opposed to just those with the "save" attribute? I cannot >> >> think of a good use case to not save an option, and even if >> >> there is a good use case wouldn't it be rare enough to >> >> justify saving by default and having an attribute to turn off >> >> saving? Furthermore, until you made that change the behavior >> >> has been to save all of the options, and to my knowledge no >> >> one has complained about that. >> >> >> >> -Ken >> >> >> >> >> >> On 1/11/10 12:11 PM, "Scott, W Alan" wrote: >> >> >> >> > Thanks, you're the greatest! >> >> > >> >> > I think that the save attribute is necessary, since we need to >> >> > --connect-id flag to not be saved between sessions - and to >> >> truly be >> >> > random. This is mandatory for some of our systems. >> >> > >> >> > Alan >> >> > >> >> >> -Original Message- >> >> >> From: Utkarsh Ayachit [mailto:utkarsh.ayac...@kitware.com] >> >> >> Sent: Monday, January 11, 2010 12:05 PM >> >> >> To: Moreland, Kenneth >> >> >> Cc: Rick Angelini; Scott, W Alan; ParaView >> >> >> Subject: Re: [Paraview] Paraview 3.6.x connection definition files >> >> >> >> >> >> Folks, >> >> >> >> >> >> I've committed a fix for this. The updating of the user's >> >> >> servers.pvsc file was totally unnecessary (there was code >> >> elsewhere >> >> >> that handled BUG #5487). However the user selections for >> >> only those >> >> >> elements that have the "save" attribute set to true are >> >> >> preserved across sessions. >> >> >> >> >> >> Refer to >> >> >> http://www.paraview.org/Wiki/ParaView:Server_Configuration#Cas >> >> >> e_Eight:_Starting_server_using_ssh >> >> >> >> >> >> for details on the "save" attribute. I am wondering if that's even >> >> >> needed and we can always save all options i.e. assume >> >> "save" is true >> >> >> by default. What do you think? >> >> >> >> >> >> Utkarsh >> >> >> >> >> >> On Mon, Nov 9, 2009 at 10:45 AM, Moreland, Kenneth >> >> >> wrote: >> >> >>> I've submitted a bug on this issue: >> >> >>> >> >> >>> http://www.paraview.org/Bug/view.php?id=9866 >> >> >>> >> >> >>> Please take a look at it and see if it and the suggested solution >> >> >>> addresses the problem. >>
Re: [Paraview] Paraview 3.6.x connection definition files
I've run into a situation where things are not yet being handled correctly with this issue. I'm currently testing with 3.7.x assuming that's the where the work is going on for the next release. The original issue can be found here: http://www.paraview.org/Bug/view.php?id=9866#c18827 As stated in the issue resolution, the saved values are now being stored in the users .ini file, but they are not unique for each server. That is, it appears to be creating "global variables" rather than saving off variables per server. So, I have something that looks like this in my .ini file: [SERVER_STARUP] SSHLOC=/usr/local/bin/ssh LOGINNODE=login-node1 USERNAME=user PROJECTNUM=ABC123Project PV_CONNECT_ID=13829 NODES=2 QUEUE=debug SERVER_PORT=55876 WALLTIME=60 VERSION=3.7.0 If I now load up a different server which happens to use the same variable names, these automatically get dumped into the connection definition file, which is OK assuming that you have the same USERNAME, PROJECTNUM, etc across all systems, which is not the case.So, I have multiple connection definition files pointing to multiple machines with different usernames and ProjectIDs, and by default I'm getting the values from the previous session rather than the values from the previous session for that particular server. I'm wondering if the best way to save these variables is something more like this: hostname1.USERNAME=jimuser hostname1.PROJECTNUM=ABC123Project hostname2.USERNAME=joeuser hostname2.PROJECTNUM=XYZ789Project Where "hostname" is the Server name from the .pvsc file. Utkarsh Ayachit wrote: I've ensured that when "random" is specified as the default value for any option, which is the case with --connect-id, then the value is always regenerated, so this will be a non-issue. Also you can always add save="false" attribute, if needed -- but not necessary in this case. Utkarsh On Mon, Jan 11, 2010 at 8:38 PM, Scott, W Alan wrote: > Am I missing something, or would we also save the --connect-id flag between sessions? This needs to be new, and random, each and every time we run. > > This was the reason that the save option was put into Paraview - so we wouldn't save the --connect-id variable. > > Alan > >> -Original Message- >> From: Moreland, Kenneth >> Sent: Monday, January 11, 2010 1:52 PM >> To: Scott, W Alan; Utkarsh Ayachit >> Cc: Rick Angelini; ParaView >> Subject: Re: [Paraview] Paraview 3.6.x connection definition files >> >> Utkarsh, >> >> Is there a reason why we should not save all options as >> opposed to just those with the "save" attribute? I cannot >> think of a good use case to not save an option, and even if >> there is a good use case wouldn't it be rare enough to >> justify saving by default and having an attribute to turn off >> saving? Furthermore, until you made that change the behavior >> has been to save all of the options, and to my knowledge no >> one has complained about that. >> >> -Ken >> >> >> On 1/11/10 12:11 PM, "Scott, W Alan" wrote: >> >> > Thanks, you're the greatest! >> > >> > I think that the save attribute is necessary, since we need to >> > --connect-id flag to not be saved between sessions - and to >> truly be >> > random. This is mandatory for some of our systems. >> > >> > Alan >> > >> >> -Original Message- >> >> From: Utkarsh Ayachit [mailto:utkarsh.ayac...@kitware.com] >> >> Sent: Monday, January 11, 2010 12:05 PM >> >> To: Moreland, Kenneth >> >> Cc: Rick Angelini; Scott, W Alan; ParaView >> >> Subject: Re: [Paraview] Paraview 3.6.x connection definition files >> >> >> >> Folks, >> >> >> >> I've committed a fix for this. The updating of the user's >> >> servers.pvsc file was totally unnecessary (there was code >> elsewhere >> >> that handled BUG #5487). However the user selections for >> only those >> >> elements that have the "save" attribute set to true are >> >> preserved across sessions. >> >> >> >> Refer to >> >> http://www.paraview.org/Wiki/ParaView:Server_Configuration#Cas >> >> e_Eight:_Starting_server_using_ssh >> >> >> >> for details on the "save" attribute. I am wondering if that's even >> >> needed and we can always save all options i.e. assume >> "save" is true >> >> by default. What do you think? >> >> >> >> Utkarsh >> >> >> >> On Mon, Nov 9, 2009 at 10:45 AM, Moreland, Kenneth >> >> wrote: >> >>> I've submitted a bug on this issue: >> >>> >> >>> http://www.paraview.org/Bug/view.php?id=9866 >> >>> >> >>> Please take a look at it and see if it and the suggested solution >> >>> addresses the problem. >> >>> >> >>> -Ken >> >>> >> >>> >> >>> On 11/5/09 12:25 PM, "Rick Angelini" wrote: >> >>> >> >>> Alan - I think that you do want to allow the user to create >> >> their own >> >>> connection definitions files, so you need to maintain the >> >>> functionality of item #2 & item #4. Maybe there's a check >> >> to make sure >> >>> that the user-defined connection is not the same name as >> >>> system-defined connection (thu
Re: [Paraview] Dashdoard Breakage
Clint, Can you take a look at this please? It may have been a side effect of your commit on March 17. http://cmake.org/gitweb?p=cmake.git;a=commit;h=108090fde96916ba666f035d1e260f036af5b31e Utkarsh On Fri, Mar 19, 2010 at 10:33 AM, Kevin H. Hobbs wrote: > Since March 17 all of my dashboard submissions that use CTest from CVS > show many build errors. > > The submissions that use CTest 2.6 are relatively fine. > > These are my submissions : > > http://www.cdash.org/CDash/index.php?project=ParaView3&filtercount=2&showfilters=1&filtercombine=or&field1=site/string&compare1=63&value1=hooperlab&field2=site/string&compare2=63&value2=hobbs-hancock > > > ___ > 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
[Paraview] Dashdoard Breakage
Since March 17 all of my dashboard submissions that use CTest from CVS show many build errors. The submissions that use CTest 2.6 are relatively fine. These are my submissions : http://www.cdash.org/CDash/index.php?project=ParaView3&filtercount=2&showfilters=1&filtercombine=or&field1=site/string&compare1=63&value1=hooperlab&field2=site/string&compare2=63&value2=hobbs-hancock signature.asc Description: OpenPGP digital signature ___ 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
[Paraview] Python scripting: Updating PVDReader source when pvd file has changed and rendering latest time step
Hi, I'm trying to get ParaView to work in an interactive context for numerical simulations. The first goal is to have ParaView visualize time steps as they are output by the solver (vtu for individual steps, pvd as collection). I searched the wiki, mailing lists etc. and it seems this cannot be done easily. My current approach uses the python scripting interface. I open a socket in python and wait for messages from the solver that a time step was finished and a new file written out. When this happens for the first time I initialize the visualization, i.e. load the pvd file and set some basic properties. For every subsequent event I set ViewTime to the latest sample and re-render the view. Is there a more elegant way to do that? This works as long as the pvd file contains all the expected time steps from the beginning. But the solver updates the pvd file for every vtu file written out and appends it to the collection. Hence, when I initially load the pvd, I only have the first time step. I tried all methods PVDReader provides but there seems to be no way to re-read the file of a PVDReader source. Did I miss something? I wonder if it might be a better option to try to realize this as a plugin, since in the end is should also be possible to send messages back to the solver to trigger a parameter change for the next time step while the simulation is running. As I'm not so familiar with the VTK / ParaView source and have no experience writing ParaView plugins I'd be happy to get some input or estimate if that is achievable in a reasonable amount of time. Best regards, Florian ___ 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
Re: [Paraview] Input Editor - Cramped Input Port Selection
Thanks Utkarsh I like it ! However - let me know if I am boring ;) -, for multiple inputs on one port (such as AppendGeometry), it would be nice if the current inputs are already selected when choosing "Change Input" in the pipeline browser. Lazy men (yes, I am) don't want to reselect them... Anyway, that's good ! Jerome 2010/3/17 Utkarsh Ayachit > Folks, > > I've committed some changes. A slight change from the mockup is the > placement of the radio buttons, since the buttons on the top seemed > disconnected from the pipeline view when more than 1 input ports were > present. Also, if there's only 1 input port, the radio buttons are now > hidden. > > > Jeremy, > > I think I understood what you meant, and I've tried to address that > issue as well. Feel free to give that a try. > > Utkarsh > > On Tue, Mar 16, 2010 at 12:08 PM, Jérôme wrote: > > Then I was right : I was not clear enough! > > > > First, I talked about the current panel, not your mockup. I agree with > > those who enthousiastic. > > Second, the problem I noted on the multiple-input-port panel is that > > the input are not ordered by index, but by name. Changing "Source" > > to "ArbirtraySource" in the filters.xml for streamer with custom source > > will change the order the inputs appear. Well, I know, if the name are > > well-chosen, it is not a problem. > > > > Now, let's take this pipeline: > > > > builtin > >| > >|---Wavelet > >|| > >|Gradient > >| > >| --- PointSource > > > > If you want to initialize a stream tracer in the Gradient at each point > > of PointSource, you have to select Gradient, then choose filter -> > > Stream tracer with custom source. The inputs panel is shown, with > > the Input field being already set to the selected 'Gradient'. What you > > have to do is to set the Source to PointSource from the pipeline. Well... > > Attached is a screenshot of this procedure, but Source is named > > ArbitrarySource. The Gradient is set as ArbitrarySource, and Input field > > is not set. > > > > I hope I am clearer now! > > > > Jerome > > > > > > > > > > 2010/3/16 Utkarsh Ayachit > >> > >> I am not sure why there's a problem. In your case, your filters have 2 > >> input ports. e.g. in the stream tracer case, referring to the mockup, > >> INPUT1 will be called "Input" while INPUT2 will be called > >> "ArbitrarySource" or "Source" as the case may be. Both of which > >> allowing the user to only add 1 item in the input box next to them. > >> > >> Utkarsh > >> > >> On Tue, Mar 16, 2010 at 4:23 AM, Jérôme wrote: > >> > My 2 cents on this : > >> > It seems to me that the input list is provided in alphabetical order. > In > >> > my > >> > case I have a lot of custom plugins that take 2 inputs, one being > >> > vtkImageData > >> > and the other a vtkPolyData (such a stream tracer with custom source). > >> > Depending on wich is the 'principal' input, the default input setting > of > >> > this > >> > panel have non-corresponding type. For instance, the Image input is > set > >> > to an existing PointSet. > >> > > >> > I don't know if I am clear enough, but maybe you can try with the > stream > >> > tracer > >> > with custom source: in the current configuration, there is no problem. > >> > But I > >> > am > >> > quite sure that if you rename the 2nd input "Source" to > >> > "ArbitrarySource" in > >> > the > >> > filters.xml, you will understand this tiny problem. > >> > > >> > Jerome > >> > > >> > 2010/3/16 Christian Werner > >> >> > >> >> I vote yes for the mockup! > >> >> > >> >> Utkarsh Ayachit wrote: > >> >>> > >> >>> I agree, the pipeline preview is confusing and for the most part > >> >>> useless. Unless people object, I'd vote for removing it as well. > >> >>> > >> >>> Attached is a sample mockup. In case of filters like Append which > have > >> >>> single input port, but multiple input connections, the use can type > in > >> >>> a comma separated list of the inputs in the input field or select > >> >>> multiple items using the pipeline browser in the dialog. > >> >>> > >> >>> Utkarsh > >> >>> > >> >>> On Mon, Mar 15, 2010 at 11:22 AM, Christian Werner > >> >>> wrote: > >> >>> > >> > >> As a user, may I present three suggestions, two of which should be > >> very > >> easy > >> and still yield an improvement. > >> > >> 1) remove the Pipeline Preview: This may be rude because it's > somehow > >> nice. > >> But then again, you cannot change what happens to the pipeline > >> anyway. > >> Also, > >> I don't think one would change his mind about the selection of the > >> inputs > >> just because the Pipeline Preview shows something unsuspected. Most > >> of > >> the > >> time the user knows what he is doing and wants to quickly and > easily > >> select > >> his inputs. The actual layout works against this intend. The > Pipeline > >> Preview can be included again once a nice layout is found. > >> >
[Paraview] reader plugin
Hello everybody, I am trying to create a reader plugin which could launch multiple .pvd files at once. Let say that I have an input file with a list of 2 pvd files. I want my plugin to read through this list and launch a PVDReader for the 2 files. I am not sure this could be made. How should I call the PVDReader command in my vtk classes? Any help will be appreciated. Cheers Tristan ___ 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
Re: [Paraview] Input Editor - Cramped Input Port Selection
Now I miss an edit box or alike that shows your selection for every input! I think this is important, at least I scrolled around to see what the edit boxes say with the actual form in the first place! :) Utkarsh Ayachit wrote: Folks, I've committed some changes. A slight change from the mockup is the placement of the radio buttons, since the buttons on the top seemed disconnected from the pipeline view when more than 1 input ports were present. Also, if there's only 1 input port, the radio buttons are now hidden. Jeremy, I think I understood what you meant, and I've tried to address that issue as well. Feel free to give that a try. Utkarsh On Tue, Mar 16, 2010 at 12:08 PM, Jérôme wrote: Then I was right : I was not clear enough! First, I talked about the current panel, not your mockup. I agree with those who enthousiastic. Second, the problem I noted on the multiple-input-port panel is that the input are not ordered by index, but by name. Changing "Source" to "ArbirtraySource" in the filters.xml for streamer with custom source will change the order the inputs appear. Well, I know, if the name are well-chosen, it is not a problem. Now, let's take this pipeline: builtin | |---Wavelet || |Gradient | | --- PointSource If you want to initialize a stream tracer in the Gradient at each point of PointSource, you have to select Gradient, then choose filter -> Stream tracer with custom source. The inputs panel is shown, with the Input field being already set to the selected 'Gradient'. What you have to do is to set the Source to PointSource from the pipeline. Well... Attached is a screenshot of this procedure, but Source is named ArbitrarySource. The Gradient is set as ArbitrarySource, and Input field is not set. I hope I am clearer now! Jerome 2010/3/16 Utkarsh Ayachit I am not sure why there's a problem. In your case, your filters have 2 input ports. e.g. in the stream tracer case, referring to the mockup, INPUT1 will be called "Input" while INPUT2 will be called "ArbitrarySource" or "Source" as the case may be. Both of which allowing the user to only add 1 item in the input box next to them. Utkarsh On Tue, Mar 16, 2010 at 4:23 AM, Jérôme wrote: My 2 cents on this : It seems to me that the input list is provided in alphabetical order. In my case I have a lot of custom plugins that take 2 inputs, one being vtkImageData and the other a vtkPolyData (such a stream tracer with custom source). Depending on wich is the 'principal' input, the default input setting of this panel have non-corresponding type. For instance, the Image input is set to an existing PointSet. I don't know if I am clear enough, but maybe you can try with the stream tracer with custom source: in the current configuration, there is no problem. But I am quite sure that if you rename the 2nd input "Source" to "ArbitrarySource" in the filters.xml, you will understand this tiny problem. Jerome 2010/3/16 Christian Werner I vote yes for the mockup! Utkarsh Ayachit wrote: I agree, the pipeline preview is confusing and for the most part useless. Unless people object, I'd vote for removing it as well. Attached is a sample mockup. In case of filters like Append which have single input port, but multiple input connections, the use can type in a comma separated list of the inputs in the input field or select multiple items using the pipeline browser in the dialog. Utkarsh On Mon, Mar 15, 2010 at 11:22 AM, Christian Werner wrote: As a user, may I present three suggestions, two of which should be very easy and still yield an improvement. 1) remove the Pipeline Preview: This may be rude because it's somehow nice. But then again, you cannot change what happens to the pipeline anyway. Also, I don't think one would change his mind about the selection of the inputs just because the Pipeline Preview shows something unsuspected. Most of the time the user knows what he is doing and wants to quickly and easily select his inputs. The actual layout works against this intend. The Pipeline Preview can be included again once a nice layout is found. 2) hide the Pipeline Preview and make it visible if the user wants to 3) change the layout such that the inputs are shown on top and let QT manage the form's height. You normally don't use so many inputs, so this most probably would never lead to problems. Best regards, Christian Paul Edwards wrote: One simple fix would be to make sure that the preview window isn't selectable. A lot of my users get confused thinking one box is for the input and the other as the source. Regards, Paul On 12 March 2010 19:10, Utkarsh Ayachit wrote: I cannot agree more. I am going to take a stab and fixing this before 3.8. We've just had too many complaints about this dialog to keep on delaying this. Utkarsh On Fri, Mar 12, 2010 at 2:00 PM, Christian Werner wrote:
