[Paraview] Paraview 3.6.x connection definition files
Scott, W Alan
wascott at sandia.gov
Mon Jan 11 14:11:17 EST 2010
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.ayachit at 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 <Option /> 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
> <kmorel at sandia.gov> 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" <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
> >
> >
> > _______________________________________________
> > 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
> >
> >
>
>
More information about the ParaView
mailing list