[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