[Paraview] Paraview 3.6.x connection definition files
Utkarsh Ayachit
utkarsh.ayachit at kitware.com
Mon Jan 11 16:28:45 EST 2010
Works for me. I'll make "save" on by default.
On Mon, Jan 11, 2010 at 3:51 PM, Moreland, Kenneth <kmorel at sandia.gov> wrote:
> 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