[Paraview] Paraview 3.6.x connection definition files
Moreland, Kenneth
kmorel at sandia.gov
Mon Jan 11 15:51:37 EST 2010
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