[Paraview] Paraview 3.6.x connection definition files
Scott, W Alan
wascott at sandia.gov
Tue Jan 12 11:53:58 EST 2010
Excellent.
Alan
> -----Original Message-----
> From: Utkarsh Ayachit [mailto:utkarsh.ayachit at kitware.com]
> Sent: Tuesday, January 12, 2010 7:37 AM
> To: Scott, W Alan
> Cc: Moreland, Kenneth; Rick Angelini; ParaView
> Subject: Re: [Paraview] Paraview 3.6.x connection definition files
>
> I've ensured that when "random" is specified as the default
> value for any option, which is the case with --connect-id,
> then the value is always regenerated, so this will be a
> non-issue. Also you can always add save="false" attribute, if
> needed -- but not necessary in this case.
>
> Utkarsh
>
> On Mon, Jan 11, 2010 at 8:38 PM, Scott, W Alan
> <wascott at sandia.gov> wrote:
> > 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