[Paraview] Paraview 3.6.x connection definition files
Moreland, Kenneth
kmorel at sandia.gov
Mon Nov 9 10:45:26 EST 2009
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" <angel at 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" <angel at 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:angel at 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 <angel at arl.army.mil>
> > > > *Date: *Fri, 23 Oct 2009 10:55:10 -0600
> > > > *To: *<ParaView at 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: kmorel at 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: kmorel at sandia.gov
** *** ** phone: (505) 844-8919
*** web: http://www.cs.unm.edu/~kmorel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20091109/5d0a9000/attachment-0001.htm>
More information about the ParaView
mailing list