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