<HTML>
<HEAD>
<TITLE>Re: [Paraview] Paraview 3.6.x connection definition files</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>I’ve submitted a bug on this issue:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><a href="http://www.paraview.org/Bug/view.php?id=9866">http://www.paraview.org/Bug/view.php?id=9866</a><BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
Please take a look at it and see if it and the suggested solution addresses the problem.<BR>
<BR>
-Ken<BR>
<BR>
<BR>
On 11/5/09 12:25 PM, "Rick Angelini" <<a href="angel@arl.army.mil">angel@arl.army.mil</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Alan - I think that you do want to allow the user to create their own<BR>
connection definitions files, so you need to maintain the functionality<BR>
of item #2 & item #4. Maybe there's a check to make sure that the<BR>
user-defined connection is not the same name as system-defined<BR>
connection (thus won't overwrite?). Or, better yet, differentiate the<BR>
connections with something like "User:BigRedCluster" and<BR>
"Global:BigRedCluster" depending on where the definition was read from?<BR>
<BR>
Scott, W Alan wrote:<BR>
> Seems to me that we really want ParaView to do the following:<BR>
> * Read server connection information from a system level file.<BR>
> * Read server connection information from a user level file. This<BR>
> information shall not override anything read in from the system level<BR>
> file. (Do we even need this file?)<BR>
> * Read in the user's default connection information from a user level<BR>
> file.<BR>
> * Allow the user to edit the server information. (Do we even need this<BR>
> step?)<BR>
> * When ParaView finishes, write out the current server information<BR>
> (from the system level and the user level) into a user level file. (Do<BR>
> we even need this?)<BR>
> * Write preferences into a preferences file.<BR>
> Thoughts?<BR>
> Alan<BR>
><BR>
> ------------------------------------------------------------------------<BR>
> *From:* Moreland, Kenneth<BR>
> *Sent:* Thursday, November 05, 2009 8:02 AM<BR>
> *To:* Rick Angelini; Scott, W Alan<BR>
> *Cc:* ParaView<BR>
> *Subject:* Re: [Paraview] Paraview 3.6.x connection definition files<BR>
><BR>
> It sounds like the major problem is that ParaView is taking the<BR>
> server connection configurations from the system files and writing<BR>
> them in the servers.pvsc configuration file the first time it<BR>
> encounters them, where they forever override any changes to the<BR>
> system files. I believe this behavior was introduced to save the<BR>
> user’s last entries for the parameters as the default for the next<BR>
> invocation (bug #5487).<BR>
><BR>
> This is an important feature, but perhaps this is not the best way<BR>
> to implement it. Perhaps ParaView should be saving the server<BR>
> connection argument parameters in the regular settings key/value<BR>
> file. That way you could leave the system server settings in the<BR>
> system files and nothing would override them. Does that sound like<BR>
> the right thing?<BR>
><BR>
> -Ken<BR>
><BR>
><BR>
> On 11/5/09 6:00 AM, "Rick Angelini" <<a href="angel@arl.army.mil">angel@arl.army.mil</a>> wrote:<BR>
><BR>
> Alan, yes, you've demonstrated the problem I found with the pvsc<BR>
> files. It's a difficult problem:<BR>
><BR>
> Ideally, we want to provide<BR>
> 1. Global server connection definitions<BR>
> 2. User-defined server connection definitions<BR>
> 3. the ability save persistent information (username, remote shell<BR>
> executable, ProjectID, etc, etc) as defined by the pvsc definition<BR>
> 4. Update the global connection definition and have it<BR>
> override any<BR>
> previous definition<BR>
><BR>
> I think that it's a slightly larger issue than just managing<BR>
> variables<BR>
> that may exist between the user copy of the definition and the<BR>
> global<BR>
> copy - we need to provide the capability to drop in a totally<BR>
> new global<BR>
> pvsc file and have it override anything that may have been saved<BR>
> locally. For instance, we just switched our queuing system<BR>
> from LSF to<BR>
> PBS and the entire pvsc file changed. Ideally, when the new global<BR>
> server definition was dropped into the place, the user copy<BR>
> for that<BR>
> server would be totally replaced by the new definition.<BR>
><BR>
> Scott, W Alan wrote:<BR>
> ><BR>
> > Rick,<BR>
> > It sure looks wrong to me. I did as you said -<BR>
> > * Deleted my local .config/ParaView/servers.pvsc file.<BR>
> > * Ran ParaView, connected to a remote server, then closed<BR>
> ParaView.<BR>
> > - This read in my default_servers.pvsc file<BR>
> > - Wrote out a new local .config/ParaView/servers.pvsc file.<BR>
> > * I then changed one of the options to be wrong in the users<BR>
> > servers.pvsc file. (I used max NODES, which should obviously<BR>
> be from<BR>
> > the system default_servers.pvsc). This information was still<BR>
> correct<BR>
> > in the default_server.pvsc file.<BR>
> > * Upon rerunning ParaView, the wrong information was picked<BR>
> up from<BR>
> > the servers.pvsc file.<BR>
> ><BR>
> ><BR>
> > What would be the correct behavior? We want to always use the<BR>
> default<BR>
> > value from the user's servers.pvsc file, but we want to use<BR>
> all of the<BR>
> > other variables from the default_servers.pvsc file. Right?<BR>
> ><BR>
> > Alan<BR>
> ><BR>
> > > -----Original Message-----<BR>
> > > From: Rick Angelini [<a href="mailto:angel@arl.army.mil">mailto:angel@arl.army.mil</a>]<BR>
> > > Sent: Monday, November 02, 2009 8:36 AM<BR>
> > > To: Scott, W Alan<BR>
> > > Cc: ParaView; Moreland, Kenneth<BR>
> > > Subject: Re: [Paraview] Paraview 3.6.x connection<BR>
> definition files<BR>
> > ><BR>
> > > You're correct, the FIRST place it looks is for the system<BR>
> default.<BR>
> > > However, the SECOND place it looks is the user's area, which<BR>
> > > OVERRIDES<BR>
> > > the systems default, as best as I can tell. If HostA is<BR>
> defined in<BR>
> > > the default_servers.pvsc, the first time it gets loaded it<BR>
> is then<BR>
> > > saved into the user's local servers.pvsc file. I need to do<BR>
> more<BR>
> > > testing, but it looks like even if the default.pvsc file is<BR>
> > > updated, the original definition that was saved off in the<BR>
> > > users area is used.<BR>
> > ><BR>
> > ><BR>
> > > Scott, W Alan wrote:<BR>
> > > > Rick,<BR>
> > > > To be honest, I didn't even realize that there was a<BR>
> > > servers.pvsc in<BR>
> > > > the home directory. The first place that ParaView looks<BR>
> for GUI<BR>
> > > > connection information is in your Paraview install area.<BR>
> > > On our LANS,<BR>
> > > > this is .../3.6.2/Linux-x86_64/lib/paraview-3.6 (which is<BR>
> really<BR>
> > > > wherever_paraviews_root_is/lib/paraview-3.6) I have a<BR>
> > > > default_servers.pvsc in there.<BR>
> > > ><BR>
> > > > For standalone Linux installs, I put this<BR>
> > > default_servers.pvsc in the<BR>
> > > > same place .../local_paraview_base/lib/paraview-3.6.<BR>
> > > ><BR>
> > > > In XP it goes in the ParaView install directory - c:/Program<BR>
> > > > Files/ParaView 3.6.2/bin.<BR>
> > > ><BR>
> > > > Give me a call if you want to discuss.<BR>
> > > ><BR>
> > > > Alan<BR>
> > > ><BR>
> > > ><BR>
> > > ><BR>
> > > ><BR>
> > > > ------ Forwarded Message<BR>
> > > > *From: *Rick Angelini <<a href="angel@arl.army.mil">angel@arl.army.mil</a>><BR>
> > > > *Date: *Fri, 23 Oct 2009 10:55:10 -0600<BR>
> > > > *To: *<<a href="ParaView@paraview.org">ParaView@paraview.org</a>><BR>
> > > > *Subject: *[Paraview] Paraview 3.6.x connection<BR>
> definition files<BR>
> > > ><BR>
> > > > I have questions regarding the use of connection<BR>
> > > definition files.<BR>
> > > ><BR>
> > > > I have created numerous connection definition files for<BR>
> various<BR>
> > > > clusters<BR>
> > > > and compute systems that we have here. Up until<BR>
> > > now, I've been<BR>
> > > > distributing those pvsc files through a common<BR>
> > > directory that all<BR>
> > > > of my<BR>
> > > > users have access to. They manually load the pvsc<BR>
> > > files into their<BR>
> > > > session, and those server definitions get automatically<BR>
> > > saved into<BR>
> > > > $HOME/.config/ParaView/servers.pvsc. The<BR>
> > > connection definition<BR>
> > > > files work great and are a huge time saver for Paraview<BR>
> users -<BR>
> > > > particularly in an environment where we need to<BR>
> > > establish SSH tunnels,<BR>
> > > > modify ports and connection IDs, etc.<BR>
> > > ><BR>
> > > > The problem lies in what happens when I want to change<BR>
> > > one or more of<BR>
> > > > those pvsc files (presumably to incorporate a change<BR>
> > > that will improve<BR>
> > > > functionality, performance, etc 8-) I update the<BR>
> > > pvsc file in the<BR>
> > > > common directory, and then I need to notify all of my<BR>
> > > Paraview users<BR>
> > > > that there's an update to the PVSC files and that they<BR>
> need to<BR>
> > > > delete/replace their existing definition with a new one. This<BR>
> > > > scenario<BR>
> > > > is awkward and requires some effort on the users' part<BR>
> > > - it would be<BR>
> > > > nice if there were a more automatic solution.<BR>
> > > ><BR>
> > > > So, I've been looking at using a default_servers.pvsc<BR>
> > > file which in<BR>
> > > > theory is a great idea. All users would have access<BR>
> > > to a common pvsc<BR>
> > > > file that I can control and update as necessary, with no<BR>
> updates<BR>
> > > > required by the user. Well, unfortunately, it doesn't<BR>
> > > seem to really<BR>
> > > > work that way. The default_servers.pvsc file is read<BR>
> > > in the first<BR>
> > > > time ParaView is loaded, and then those server<BR>
> > > definitions are saved<BR>
> > > > back to the $HOME/.config/ParaView directory. The servers are<BR>
> > > > presumably saved off to preserve some of the<BR>
> > > information as defined in<BR>
> > > > the PVSC file - I have numerous fields (UserID,<BR>
> ProjectID, SSH<BR>
> > > > executable labeled with "save=true" so that that<BR>
> information is<BR>
> > > > carried<BR>
> > > > over between sessions.<BR>
> > > ><BR>
> > > > This is where we start to run into problems.<BR>
> > > According to the<BR>
> > > > WIKI,<BR>
> > > > the last server definition loaded take precedence, so if<BR>
> I make<BR>
> > > > changes<BR>
> > > > to the "default_servers.pvsc" file, it gets loaded prior to<BR>
> > > > "$HOME/.config/ParaView/servers.pvsc". Unless I'm missing<BR>
> > > > something,<BR>
> > > > once the server definitions are initialized the first<BR>
> > > time they are<BR>
> > > > recognized and saved off to the user's .config<BR>
> > > directory, the default<BR>
> > > > servers will never have precedence, even if I<BR>
> change/update the<BR>
> > > > contents. Unless the ServerName is changed for each<BR>
> > > subsequent update<BR>
> > > > of a particular server, any updated server in the<BR>
> > > default servers file<BR>
> > > > won't be loaded. Am I on the right track here - have<BR>
> > > I missed or<BR>
> > > > assumed something that I shouldn't have? It looks<BR>
> > > like all of the<BR>
> > > > hooks are *almost* there to manage the server definitions<BR>
> .....<BR>
> > > ><BR>
> > > > Also, using 3.6.1, I went through the process of created a<BR>
> > > > default_servers.pvsc, having those servers<BR>
> > > automatically loaded in my<BR>
> > > > ParaView session, and then have them saved off into a local<BR>
> > > > servers.pvsc<BR>
> > > > file. However, during the next Paraview session, the<BR>
> > > definitions<BR>
> > > > don't<BR>
> > > > work properly - it seems as those the only the last item<BR>
> in an<BR>
> > > > enumerated list are available through the GUI, and in<BR>
> > > general it just<BR>
> > > > doesn't work correctly. If those same server<BR>
> > > definitions are loaded<BR>
> > > > manually by the user and saved locally, they work<BR>
> > > fine. So, there's<BR>
> > > > apparently an issue related to the use of the<BR>
> > > default_servers.pvsc and<BR>
> > > > how those definitions are saved out to the user's<BR>
> > > server.pvsc file.<BR>
> > > ><BR>
> > > ><BR>
> > > ><BR>
> > > > _______________________________________________<BR>
> > > > Powered by www.kitware.com<BR>
> > > ><BR>
> > > > Visit other Kitware open-source projects at<BR>
> > > > <a href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a><BR>
> > > ><BR>
> > > > Please keep messages on-topic and check the ParaView Wiki at:<BR>
> > > > <a href="http://paraview.org/Wiki/ParaView">http://paraview.org/Wiki/ParaView</a><BR>
> > > ><BR>
> > > > Follow this link to subscribe/unsubscribe:<BR>
> > > > <a href="http://www.paraview.org/mailman/listinfo/paraview">http://www.paraview.org/mailman/listinfo/paraview</a><BR>
> > > ><BR>
> > > ><BR>
> > > ><BR>
> > > > ------ End of Forwarded Message<BR>
> > > ><BR>
> > ><BR>
> > ><BR>
> ><BR>
><BR>
><BR>
><BR>
><BR>
> **** Kenneth Moreland<BR>
> *** Sandia National Laboratories<BR>
> ***********<BR>
> *** *** *** email: <a href="kmorel@sandia.gov">kmorel@sandia.gov</a><BR>
> ** *** ** phone: (505) 844-8919<BR>
> *** web: <a href="http://www.cs.unm.edu/~kmorel">http://www.cs.unm.edu/~kmorel</a><BR>
> <<a href="http://www.cs.unm.edu/%7Ekmorel">http://www.cs.unm.edu/%7Ekmorel</a>><BR>
><BR>
<BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
</SPAN></FONT><FONT SIZE="2"><FONT FACE="Consolas, Courier New, Courier"><SPAN STYLE='font-size:10pt'><BR>
**** Kenneth Moreland<BR>
*** Sandia National Laboratories<BR>
*********** <BR>
*** *** *** email: <a href="kmorel@sandia.gov">kmorel@sandia.gov</a><BR>
** *** ** phone: (505) 844-8919<BR>
*** web: <a href="http://www.cs.unm.edu/~kmorel">http://www.cs.unm.edu/~kmorel</a><BR>
</SPAN></FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
</SPAN></FONT>
</BODY>
</HTML>