[Paraview] Paraview 3.6.x connection definition files
Scott, W Alan
wascott at sandia.gov
Mon Jan 11 20:38:24 EST 2010
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" <wascott at sandia.gov> 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.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
> >>>
> >>>
> >>
> >>
>
>
> **** Kenneth Moreland
> *** Sandia National Laboratories
> ***********
> *** *** *** email: kmorel at sandia.gov
> ** *** ** phone: (505) 844-8919
> *** web: http://www.cs.unm.edu/~kmorel
>
>
>
More information about the ParaView
mailing list