[Paraview] Paraview 3.6.x connection definition files

Utkarsh Ayachit utkarsh.ayachit at kitware.com
Tue Jan 12 09:37:17 EST 2010


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